i got a node stuck on 1983781/1983781

hrm, now its trying Height: 1983781/1985499 (99.9%) on mainnet, mining at 0 H/s, net hash 942.31 MH/s, v12, up to date, 6(out)+65(in) connections, uptime 7d 1h 35m 25s

huh, moneromooo , was this one of the things u added? 2019-12-05 13:57:18.537 W ge_frombytes_vartime failed at 442

gingeropolous: long ago, yes.

Not a recent thing. It means a tx is bad.

<woodser> to confirm, only short encrypted payment ids as part of an integrated address are permitted for new transactions?

Yes. Technically plaintext ones are not rejected by consensus, just support was removed.

<woodser> is the seed offset basically a password which derives a new seed from an existing seed?

<woodser> allowing password-protected wallets to be recovered from a plain-text mnemonic?

Yes.

question about lmdb and locks: the no-argument overload of Blockchain::get_tail_id() takes no locks and warns in a comment against using lmdb functions that depend on each other, but then proceeds to call BlockchainLMDB::top_block_hash(uint64_t*), which does exactly that

could this technically, possibly, go wrong?

where "wrong" means "throws an exception when retrieving the block hash at the height that was removed just now"

Yes.

do you think it's _worth_ fixing? :)

Yes.

I can make a PR with the similar cases (don't know yet how many there are)

will do soon :)

I had assumed these database layer calls were atomic (while the Blockchain class ones were not).

eh?

db_lmdb, not lmdb :)

if these functions are calling each other sequentially, then they are in the same DB transaction

what can go wrong?

ah yes this refers to the BlockchainDB layer, not the underlying lmdb code

I don't think they're in the same DB transaction

height() and _get_hash() both open their local readonly txn..

do either of them *close* the txn?

Often, there'll be a top level txn, but I don't think this must always be hte case.,

if they're running in the same thread, they reuse the same txn

ok

if you know that they're not within the same DB txn all the time, then that probably should be fixed

It's an auto mdb_txn_safe on the stack, soi I think it's closed when it goes out of scope, but I'm not very familiar with this code.

Something that'd be nice is to have rw locks there too.

(in Blockchain)

yeah

That's going to be a large amount of work to get right though I suspect.

seems like, yeah

would be nice to streamline all that. there's a lot of excess locking going on

the reason I'm seeing this is in fact because I'm working through the locking

trying to convert it to a rw lock

ah, nice

no guarantees on time lines though

Very nice :)

Ideally, we would only keep blockchain_db::txn_start and txn_stop, and eliminate all critical sections immediately above that code

wrap all related operations in a single explicit DB txn and ten forget about it.

you mean the critical regions in Blockchain?

yes

rwlocks are readers xor writers. LMDB txns are readers | writers, no blocking.

because I'm not too familiar with the db_lmdb code, I think I'm first going to use locking at the Blockchain level

Not quite possible since there's data that's not in the database. Like... *looks*... the block data received from peers when syncing.Though this could go in the db too.

that would at least be correct though perhaps not optimal

Anyway, I'll take any safe incremental improvement.

and would also cover all the other data that is in the Blockchain object itself

Assuming it doesn't butcher the source massively :D

yeah, any incremental improvement will help here

You'll be able to see when the PR comes in :)

this or next week if there's no weird stuff crossing my path (which is very possible)

Thanks :)

are there any other potentially suspect uses of BlockchainDB outside of Blockchain?

s/uses/users/

there may be some direct calls from cryptonote_core

core_rpc_server does.

That's the one that doesn't have an overarching db txn (and is known to be non atomic).

git grep 'get_db()' would likely find all these.

that's plenty of hits

but it fits on my screen, so it should be doable :)

Most are in tests or tools :)

those non-atomic uses in core_rpc_server are pretty much all read-only

could just do a txn_start()/stop() pair around them and they'd be fine

Hmm. I've moved the lockedtxn away for reuse, that's not in any branch I can push though.

Would that be useful ? That's the one that's currently in txpool.

If so I can go and extract it in a PRable thing.

oh, maybe a good idea

I do use it in rpc actually.

I'll do that later this evening if I don't forget.

hi all any chance of some advice please many thanks

No chance if you don't ask =)

hi there

needa little bit of advice please if you have a moment

If you have a -dev question, go for it. If it's not a -dev question, then hop in #monero

yes its dev related but to a coin i follow Masari we need some upgrades to our code and we are best part dev less at the moment so need some advice please

my thought are why not ask the people that our code originates from as they will know the code inside and out

Try asking then. If it's not too masari specific and not premine related, you might get an answer,

the question is we want to add nano devices to our code for one

this is all old hat for you lot but it seams miles away for us with out a dev

i was thinking would it just be better to fork xmr now then redo the code just advice not asking anybody to join us or even help

Totally depends how much stuff you changed really. Only you know that.

under stand that thank you

Assuming "nano" means ledger, there were a fair few changes to reroute crypto ops. Any patch bringing it to masari if it doesn't have it already will be pretty large.

sorry ledger yes i have beed advised the code is there but not configured

may 18 is where i believe the changes were made to your code allowing the devices to be used

is a patch something i could pay for ?

would anybody do the patch ? as you say if you dont ask the question you never know

look at the amount of commits from May 2018 to until Nano X support was added. This mostly means to look at any commits to src/wallet, src/simplewallet (as well as rpc). It's a fairly large amount of commits to pick, make changes to, etc.

the git history from monero in the masari project is destroyed which makes it annoying

i can get any info any branch i have been offered that info i just do not know what to ask for

if i am honest i refuse to let masari die because the dev is lazy and cant be bothered

There's src/device too.

that was a list of files that need to be looked at to be able to start the integration

i sure you can tell i am no dev but i am not afraid to ask questions and beg fro help when required

Did msr end up rebasing?

if there is anybody that would spare the few mins to help please would you consider joining our discord i am @flyguyry2.0 and the link is discord.gg/Q52RVm3

all i can say is thank you for your time i got to be up at 5 am for work and thank you for not killing me on the spot

no we not been rebased

that what people want to happen but i dont know where to start asking the questions on what needs to be changed or even where to start

from mem,, they needed to rebase cause know one knows the code there now, and it was going to be the quickest way to get ledger working

whats the best way to do that create a for form Xmr now or change al the code upto that point

sorry fork even from github

If Masari doen't have too many changes: put those commits in a branch off monero's git tree, then git rebase master. It'll take quite a while most likely. Fix all the conflicts carefully, and you'll end up with a msasri with ledger.