FYI the auto-update should now prompt to v0.18.1.0

.merges

Will there be any post-mortem of the hardfork issues? IIRC there was one problem with transactions flushing from the mempool.

Sech1 libera.monerologs.net/monero-dev/20220813#c134478

so 50 tx dropped, and old format transactions could only relay if they had higher than lowest priority fee

but they could be mined

what could couse no incoming connection in a stagenet node. firewall ok, permissions seem to be ok. I have two almost identical config file for 2 nodes. 1 can receive incoming connections just fine, the other one doesn't.

it's likely a local issue unrelated to Monero, but i cannot find it

Very few stagenet nodes around ?

if i take down the node that receives connections the other one has still 0 incoming

now that i added each others as peers, the second instance is starting to pick up incoming connections. i guess it was because of the few nodes

Is there a change that was made that guys need to know when batching up transactions?

Cause its failing multiple times.

Error with transfer RPC request to wallet daemon {"code":-4,"message":"transaction was rejected by daemon"}

What error does the daemon report ?

DRSBcvRJDMPcoNzOTPaQXQvwZy2ttXDIwK6h1

indeed

I too like to paste my web passwords into IRC windows from time to time

spices life up a little

exactly

moneromooo not showing any error.. Maybe will need to adjust log level

ll1

Have already sent the transactions individually though

<ofrnxmr[m]> "Sech1 libera.monerologs..." <- Curious, what are the consequence beyond dropping those 50k transactions? Have they been released from mempool & back to users wallet or will lurk around in txpool until timeout?

50 transactions, not 50k

they should be shown as "failed" in the wallet

sech1: Ah, crap, misread it. Then I guess its not a big deal 😁

could be a big deal, imagine a single one of those tx was sending 18 millions xmr o.o

And btw, what's the timeout of mempool like (hours or days?), should a transaction not go through or having too low fee at a time of network load?

I meant transaction goes through, bt waiting on 0/10 confirmations. Waiting to get into a block..

24hrs

#define CRYPTONOTE_MEMPOOL_TX_LIVETIME (86400*3) //seconds, three days

#define CRYPTONOTE_MEMPOOL_TX_FROM_ALT_BLOCK_LIVETIME 604800 //seconds, one week

3 days for new transaction, 1 week for transactions pushed back to mempool after a reorg

moneromooo: Here is another one with error paste.debian.net/1250462

Well, spend your outputs only once then :P

You may need to run "rescan_spent" once if it went out of sync.

Ok. doing that now..

hyc: is it ok, performance wise, to have *very* long lived read txns ?

Like, hours.

In this case, there won't be any writes to the db, but lots of reads.

sure. the only issue is if a read prevents a write from reusing old pages. if there's no writes, no problem

ty

can mount a DB from a CDROM or some other read-only filesystem, then you can use a single read txn forever

thanks moneromooo that worked, have not clue how the wallet went out of sync its always online

<sech1> "3 days for new transaction, 1..." <- Good information. Thanks.

Any idea why I don't see "mining_status" in CLI v0.18.1.0? I reckon it used to be there before..

We have had 1/4th txs in last 24hrs , popular wallets pushed update only last minute, plenty of normal users didn’t even know about this fork/upgrade

Maybe next cycle we have fork announce and code freeze alteast a few months (4-5) before so the user wallets/nodes are ready in time ? Anyways we are now not in the old 6 month fork schedule, and fork/update like once in 2-3yrs

We can’t have serious adoption it majority of the payment ecosystem is down for days & users confused why monero is broken for them 😅

Are you sure you're looking in the daemon ?

Localmonero stats are wrong ?

nikg83[m]: Many services also disable withdrawals / deposits around the fork date, so part of the drop can be explained by that

It would be nice if people could try 8503. The resulting DB works for me, at least.

Something I should have fixed long ago.

hyc: when pruning the chain, the process reads about 900 GB, from a ~140 GB file. Is this hiding some bug somewhere, or can it be explained by page interleaving if the SSD read quantum is > 4 kB (I have no idea what mine is) ?

Hey, is the RPC method flush_txpool deprecated? I tried to use it on my node with a list of transaction ids as shown on the website, but it failed with `method not found`

This is the command I tried:  `curl /monero.kevinthomas.dev:18089/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"flush_txpool","params":{"txids":["6fa3cfa75ef51d194dfbceac9714fd67c89eded4ce7711fe36b2b7ee7d74647c"]}}' -H 'Content-Type: application/json'`

No.

Make sure your node is not running in restricted mode.

Well, I don't know if that person's node is in restricted mode. I sent a transaction to his node, which looks to be bricked. Its block height is over a day old (2688894). I think his node is pre-0.18 and my transaction is sitting in his transaction pool. I wonder how long it will be before it's dropped. It's been there for over a day.

My txid is 6fa3cfa75ef51d194dfbceac9714fd67c89eded4ce7711fe36b2b7ee7d74647c, which wasn't relayed to other nodes so it's not visible on xmrchain.net

If it's not your node, you can't expect us to help you :)

Yeah, RIP..

Maybe in #monero though.

Just relay a new tx to working node

old not updated nodes are disconnected from the network now, so they're irrelevant

I guess my question is: My transaction is sitting in someone's memory pool. How long before it is dropped?

3 days

If they feel like it. They might keep it for longer, or less.

but if other nodes don't have it, they'll accept a new tx with the same inputs

I emailed him and told him to flush my transaction out of his memory pool.

Can I expedite this process somehow? You mentioned: Just relay a new tx to working node. What do you mean by this? Force a double-spend, essentially?

Is it even considered a double-spend if other nodes don't even know about the transaction?

send a new tx from your wallet

it's not a double spend

I sent 0.01 XMR to myself, I don't see a change in my balance (the recovery of the 1 XMR I (failed to) relay with the bricked node)

I think it's because the input selected for the 0.01 XMR wasn't the same as the inputs used for the 1 XMR I previously sent to the bricked node?

Run your own node, then rescan_spent in the wallet.

or connect to an updated and working node

and then rescan_spent

Or the wallet will probably auto do it if you refresh a couple times.

I sent the transaction from CakeWallet. Should I just restore the wallet on my desktop using the GUI wallet?

Can't hurt.

Well, you'll lose things like tx secret keys, destinations.

ie, stuff that doesn't get recorded on the chain.

Notes, etc. I get that part. Thanks

But from what you're saying, the wallet is fine. The node isn't.

Is the rescan_spent command available via the GUI wallet?

I think so. Not sure where though.

Okay, I'm comfortable with the CLI, I'll use that.

Hmm, I did rescan_spent and my balance is the same.

Anyway for me to verify that I'm not crazy (that indeed I sent the transaction to a bricked node)?

And that my balance is indeed reflextive of Y Monero - Amount Sent to Bricked Node

Maybe I'm incorrectly recounting the amount of Monero I had before I sent a transaction to the bricked node. I just want to confirm that is the case if indeed it's true

help

Woops, I meant to type 'help' in my CLI.

Maybe ask in #monero.

Sure

can i recommend making a patch release reverting monero-project/monero #8476

its causing issues for watch-only / offline signing setup

sorry, the commit is monero-project/monero ae0a840 - the issue linked is the problem

Issues such as

the signing node will fail to sign anything until you do a full output sync, which itself can take a while to process

so for a *cough* large org using this setup, its quite a burden to continually do a full output sync before every withdrawal request to make sure it will complete

and the monero node software shouldn't depend on this kind of behavior anyway - remote signing should work without continual output syncs

it was problem introduced in v0.18.0.0

a few questions on signing/verifyin/encrypting messages:

- is there an advantage/disadvantage to signing with the speed vs view key? I suppose this simply lets one prove they have certain keys?

- is there a way to encrypt/decrypt arbitrary strings? the library could expose such functionality

- on `verify`, do the other fields like `old` or `version` need to be somehow checked, or does `good` cover the summary?

s/speed/spend/

nks: thanks for explaining

nxs: *

Signing with the view key -> if you gave your view key to someone, they can impersonate you.

You can sign with any key. There's a RPC for signing arbitrary data with the spend key IIRC.

signing arbitrary data, yes, but not encrypting/decrypting to my knowledge

Oh, I'm confusing encrypt/signing on the second question. I don't think there is for that.

There's a funtion for it in wallet2 though, so it'd simple to add to RPC.

authenticated too.

Though vtnerd might have things he wants to change first if it's to be exposed via RPC.

I cna't recall what changed between v1 and v2 for signing, but good means the sig was verified as eihter v1 or v2.

So chcek for !old only if you want to ensure the signature was made with v2. Which is probably a good idea.

git log might shed some light about the version change, maybe it was exploitable before. Can't recall.

Thanks moo. I'd like to use encrypt/decrypt via the cpp api, so I'm thinking that I will look into creating a PR to expose those functions from wallet2 to the wallet-rpc and then exposing those to the cpp api. Should I coordinate with vtnerd or I will just ping him to the PR ...

Im not working on such a thing, moo may have mentioned it because there's also the ZeroMQ API which mirrors the HTTP-JSON-RPC one

or the tricky part over json is the encoding the binary ... hex I guess (thats how binary data is always encoding despite ineffiency on the wire)

if the api exports binary or hex, libraries could convert the binary client side

both HTTP and ZeroMQ use JSON for encoding, so you have to convert before setting the values in the DOM (and the opposite in the other direction)

the HTTP-JSON might do it automatically for all `std::string`, but I don't think they do

I mentioned it because IIRC you wanted to improve the authenticated encryption from wallet2, using... I forget now...

Poly1305 I think ?

oh man what does it use, I forgot now

Something I made :D

With at least *some* sanity though. Like sign after encrypt.

thats the function they want to expose?

I assume so.

woodser[m] : do you want an API for sending encrypted TO another person? like you could optionally sign who created it, and but then send that blob to another person?

because that function looks more like the same person doing the encryption/decryption, no? I think that may have been my point earlier if I made one

yeah we're looking to encrypt and decrypt arbitrary text using the same wallet keys

oh same keys, yeah then that function will work

^ jozsef

you'd definitely authentication to be set to true, but otherwise yeah

Yeah, looks like that fn will work. So we should expose to both HTTP and ZMQ RPC? And would the cyphertext have to be encoded before send to the API?

yes in both cases it has to be manually set to/from some json friendly format

everything else uses hex for simplicity, but its not wrong to use something else

base85 from zmq if you want efficiency (and annoy programmers), etc

Okay, I will look how other encode/decode is done.

12:55 <nikg83[m]> Maybe next cycle we have fork announce and code freeze alteast a few months (4-5) before so the user wallets/nodes are ready in time ? Anyways we are now not in the old 6 month fork schedule, and fork/update like once in 2-3yrs <-- we released binaries 1 month in advance, that should be enough time

exchanges disable deposit / withdrawals for security reasons when a fork happens

vtnerd: Hehe. Not necessarily to annoy, but for efficiency: I'd like to encrypt/decrypt and send relatively largeish data with it, e.g., containing multiple images and text.

also who knows what kind of transaction spam scripts forgot to update

<selsta> "12:55 <nikg83> Maybe next..." <- Yes, but prominent mobile wallets did a week/day before fork ? Also not every monero user tracks news/updates & most also defer it while everything is working

if we had 3-4 months buffer then plenty of users would have updated it, we have major fork not that often now so a few months more buffer is not going to hurt ? Unless it’s a emergency fork

Nikg i replied in community

Ill post it here..

BCH node implementers agreed on the May 2022 hardfork date a full year in advance; binaries were available months before the fork; still transaction volume fell by about 50% at the fork. And it was a block rules consensus change, not even a backwards-compatibility issue for wallets IIRC.

I would agree that more advance notice/binaries would be nice, but many, many people do not realize there is a fork until their software stops working.

Tldr from my community post

nxs: will revert it

>Yes, but prominent mobile wallets did a week/day before fork ?

This was their 100% their choice

moneromooo: any perf difference for that last change, always using MDB_APPEND?

seems like it shouldn't affect most of the relevant tables

I'll know in 1.5 hours :)

cool

hyc: well, before 1.6 hours. It fails with: Failed to write block_info record: MDB_KEYEXIST: Key/data pair already exists

Is the previous version actually wrong, or just non optimal ?

I reverted to the original patch for now.

seemed not optimal to me. but this error implies you're not actually traversing the DB in DB order

so ok, original patch is fine

I use MDB_FIRST/MDB_NEXT.

Yes, lines 221-226.

Could an intervening commit and cursor reopen interfere maybe ?

maybe

Cause I do that.

then your original patch is prob the way to go\

I'll try clearing APPEND for the first put after a commit and see if that helps.

It's got past that point.

cool

Oh wait, I'm not using your two flags at once change here.

Meh, still borks. Always at hte same place, oddly. The first table copies fine, the secone table breaks at/near start.

First atble takes about 3 minutes either way so it doesn't look like the two flags go faster anyway.

ok then never mind it

It now breaks with the old code... :S

8473 is just flaky hardware

doh

Ah, might have forgot a step, I don't test on the same VM.

A number of copies involved :)

Yeah nvm, it's fine.

wallet api tests have been disabled for a long time, correct? monero-project/monero #895

Yes. They'be been borked since the start pretty much, and nobody cared about them.

IIRC they had peculiar manual steps requirements to have them be able to run.

So what's a good way of testing exposing a new fn (at least by hand) to see what I'm screwing up?

Add some widget in the GUI to use it ? Even if placeholder for you.

The gUI?

Or replace an existing widget's code-that-calls-the-api with yours.

The window based wallet ?

monero-wallet-gui

Oh, I maybe talking about something else due to my ignorance. No. I want to expose a function from wallet2 to wallet-rpc.

Oh.

I guess that's not tested with wallet api, then.

Then you don't need wallet2_api at all, thankfully.

You add a python layer for it to utils/python-rpc/framework/wallet.py

Then you can call it from a test in tests/functional_tests/*.py

For starters though, maybe curl's easier.

The python function in utils/python-rpc/framework/wallet.py should be just a call with arguments btw, just expose the RPC, no extra logic please.

OK

hyc: monero-project/monero #8504

I thought we fixed this in randomx

or is this a different issue?

hm, this looks different

never saw failure to allocate cache before

and clearly it was succeeding up to that point

could be an actual memory leak in monerod?

I synced up with v0.18.1.0 and saw no increased memory usage on Mac

3.7GB full system RAM usage

and I didn't restart after the full sync

hyc it happened near or at randomx epoch change (block height 2689089)

according to the log there

yes so it may be a legit malloc failure, since it would alloc a new cache then

if that was the first time it crossed an epoch boundary in that run

it was

so the machine was just out of RAM

I can ask them how much RAM they have

vtnerd: how much work would it be to add github.com/jedisct1/supercop/tree/m…/crypto_scalarmult/curve25519/neon2 to our supercop repo for ARM CPUs?

for jamtis or something more immediate?

thats a speedup on curve25519/x25519 but not directly on ed25519

I think it would require recovery of y-coord then a conversion between curves

still might be faster (whereas jamtis is proposing x25519 directly for certain things)

You wrote "This should speed up the ECDH portion of the address scanning on relevant arm processors." in an old GitHub issue

so I wasn't sure if it was applicable for current monero

ah, yikes. Yeah I think it still would, it just loses some due to the extra math for conversion

seems more involved compared to crypto_sign/ed25519/amd64-51-30k and amd64-64-24k

a bit. y-coord recovery would be the blocker (at least for me)

specifically the sign portion, but maybe someone else knows immediately off hand

maybe I will have to live without ARM ASM optimizations until jamtis

I'll try to dig through the details, this would be a huge boost for the increasing number of arm64 users

Users = nodes or wallets?

wallets mainly, but we also have more nodes

supercop isn't currently used by the daemon for syncing, only for wallets

using it for historical sync would be an easy win but that's a different topic

easiest to speed up would be ge_add(), which is at the core of multiexp (bulletproofs currently, then bps & grootle with seraphis)

3.9GB is kind of a suspicious size for #8504. check to make sure he used a 64bit binary, not 32bit?

there is no 32bit mac binary

oh right forgot that was a mac

intel mac\

that's the one we cross compile with the newer sdk, but i don't see how low level malloc is impacted by this

right. well technically we allocate using mmap

but still, shouldn't have any issue there