rbrunner claimed that the tx was broadcast

that message is written when the tx comes back to the node, will list more details on the github thread

is length of encrypted amount field enforced?

That sounds so much like a trick question.

You asked that a few times already, but never with details on what exactly is htat field.

There is a key in rct that is the amount. If that what you're afte r? If so, it's a key, not a field. A field sounds lilke somehting from extra, or some varint, but I don't see what it could be off the top of my head.

I had a discussion with sarang a couple months ago about range checking here, but if that's what you're after, there's builtin range checking that the amount is within 64 bit range (with negligible probability that it is not) IIRC.

If you're asking about a third thing, give details.

I never asked this before

encrypted amount is what's related to ecdhEncode

it's 8 bytes now, but could someone make a tx with more/less than 8>

?

vtnerd: that message is written when the tx comes back to the node, <- my 3 transactions went through with no problems as well and i got that message too.

I'm wondering if mdb_txn_safe::wait_no_active_txns in src/blockchain_db/lmdb/db_lmdb.cpp is working as intended. The transaction counter is only updated when used through mdb_txn_safe itself, but read transactions don't appear to use this class

This function is used to ensure there are no active transactions before calling mdb_env_set_mapsize in lmdb_resized, because according to the LMDB docs it may only called when there are no active txns:

"It may be called at later times if no transactions are active in this process. Note that the library does not check for this condition, the caller must ensure it explicitly."

Read txns can overlap with other txes. They just get old data if a write txs committed after htey started.

It doesn't mention that this only applies to write transactions, though

hyc: ^

I'd also say that if multiple read transactions are started which fail with MDB_MAP_RESIZED while a write transaction is active, mdb_env_set_mapsize might be called concurrently when the write transaction is closed

I am unsure whether or not this could lead to trouble, whether that function is thread safe

mdb_txn_safe is used for readtxns too

a single process using the DB can't get the MAP_RESIZED error.

that only comes up if a different process has resized the DB

env_set_mapsize is not threadsafe. it is up to the caller to ensure it only gets called once.