03:34:17 <gingeropolous> i got a node stuck on 1983781/1983781
03:36:09 <gingeropolous> 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
03:39:50 <gingeropolous> huh, moneromooo , was this one of the things u added? 2019-12-05 13:57:18.537 W ge_frombytes_vartime failed at 442
11:53:44 <moneromooo> gingeropolous: long ago, yes.
11:53:52 <moneromooo> Not a recent thing. It means a tx is bad.
14:11:02 <kovri-slack> <woodser> to confirm, only short encrypted payment ids as part of an integrated address are permitted for new transactions?
14:14:46 <moneromooo> Yes. Technically plaintext ones are not rejected by consensus, just support was removed.
14:47:17 <kovri-slack> <woodser> is the seed offset basically a password which derives a new seed from an existing seed?
14:47:24 <kovri-slack> <woodser> allowing password-protected wallets to be recovered from a plain-text mnemonic?
14:47:46 <moneromooo> Yes.
16:41:17 <tomsmeding> 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
16:41:41 <tomsmeding> could this technically, possibly, go wrong?
16:42:22 <tomsmeding> where "wrong" means "throws an exception when retrieving the block hash at the height that was removed just now"
16:43:28 <moneromooo> Yes.
16:44:14 <tomsmeding> do you think it's _worth_ fixing? :)
16:44:24 <moneromooo> Yes.
16:44:34 <tomsmeding> I can make a PR with the similar cases (don't know yet how many there are)
16:44:45 <tomsmeding> will do soon :)
16:45:08 <moneromooo> I had assumed these database layer calls were atomic (while the Blockchain class ones were not).
16:45:10 <hyc> eh?
16:45:21 <moneromooo> db_lmdb, not lmdb :)
16:45:35 <hyc> if these functions are calling each other sequentially, then they are in the same DB transaction
16:45:39 <hyc> what can go wrong?
16:45:41 <tomsmeding> ah yes this refers to the BlockchainDB layer, not the underlying lmdb code
16:45:52 <tomsmeding> I don't think they're in the same DB transaction
16:46:22 <moneromooo> height() and _get_hash() both open their local readonly txn..
16:46:44 <hyc> do either of them *close* the txn?
16:46:52 <moneromooo> Often, there'll be a top level txn, but I don't think this must always be hte case.,
16:46:52 <hyc> if they're running in the same thread, they reuse the same txn
16:47:25 <hyc> ok
16:47:43 <hyc> if you know that they're not within the same DB txn all the time, then that probably should be fixed
16:47:51 <moneromooo> 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.
16:48:33 <moneromooo> Something that'd be nice is to have rw locks there too.
16:48:48 <moneromooo> (in Blockchain)
16:49:09 <hyc> yeah
16:49:11 <moneromooo> That's going to be a large amount of work to get right though I suspect.
16:49:53 <hyc> seems like, yeah
16:50:08 <hyc> would be nice to streamline all that. there's a lot of excess locking going on
16:51:54 <tomsmeding> the reason I'm seeing this is in fact because I'm working through the locking
16:52:01 <tomsmeding> trying to convert it to a rw lock
16:52:09 <hyc> ah, nice
16:52:11 <tomsmeding> no guarantees on time lines though
16:52:59 <moneromooo> Very nice :)
16:53:02 <hyc> Ideally, we would only keep blockchain_db::txn_start and txn_stop, and eliminate all critical sections immediately above that code
16:53:33 <hyc> wrap all related operations in a single explicit DB txn and ten forget about it.
16:54:09 <tomsmeding> you mean the critical regions in Blockchain?
16:54:13 <hyc> yes
16:54:50 <hyc> rwlocks are readers xor writers. LMDB txns are readers | writers, no blocking.
16:55:10 <tomsmeding> because I'm not too familiar with the db_lmdb code, I think I'm first going to use locking at the Blockchain level
16:55:10 <moneromooo> 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.
16:55:26 <tomsmeding> that would at least be correct though perhaps not optimal
16:55:54 <moneromooo> Anyway, I'll take any safe incremental improvement.
16:55:59 <tomsmeding> and would also cover all the other data that is in the Blockchain object itself
16:56:13 <moneromooo> Assuming it doesn't butcher the source massively :D
16:56:15 <hyc> yeah, any incremental improvement will help here
16:56:28 <tomsmeding> You'll be able to see when the PR comes in :)
16:57:04 <tomsmeding> this or next week if there's no weird stuff crossing my path (which is very possible)
16:57:55 <moneromooo> Thanks :)
17:07:30 <tomsmeding> are there any other potentially suspect uses of BlockchainDB outside of Blockchain?
17:07:35 <tomsmeding> s/uses/users/
17:08:00 <hyc> there may be some direct calls from cryptonote_core
17:08:32 <moneromooo> core_rpc_server does.
17:09:01 <moneromooo> That's the one that doesn't have an overarching db txn (and is known to be non atomic).
17:09:48 <moneromooo> git grep 'get_db()' would likely find all these.
17:10:30 <tomsmeding> that's plenty of hits
17:10:59 <tomsmeding> but it fits on my screen, so it should be doable :)
17:11:40 <moneromooo> Most are in tests or tools :)
17:11:51 <hyc> those non-atomic uses in core_rpc_server are pretty much all read-only
17:12:05 <hyc> could just do a txn_start()/stop() pair around them and they'd be fine
17:13:22 <moneromooo> Hmm. I've moved the lockedtxn away for reuse, that's not in any branch I can push though.
17:13:46 <moneromooo> Would that be useful ? That's the one that's currently in txpool.
17:14:16 <moneromooo> If so I can go and extract it in a PRable thing.
17:14:56 <hyc> oh, maybe a good idea
17:15:16 <moneromooo> I do use it in rpc actually.
17:15:35 <moneromooo> I'll do that later this evening if I don't forget.
22:48:54 <Masari> hi all any chance of some advice please many thanks
22:56:31 <scoobybejesus> No chance if you don't ask =)
22:56:46 <Masari45> hi there
22:57:16 <Masari45> needa little bit of advice please if you have a moment
22:57:24 <scoobybejesus> If you have a -dev question, go for it.  If it's not a -dev question, then hop in #monero
22:58:33 <Masari45> 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
23:00:10 <Masari45> my thought are why not ask the people that our code originates from as they will know the code inside and out
23:00:10 <moneromooo> Try asking then. If it's not too masari specific and not premine related, you might get an answer,
23:00:55 <Masari45> the question is we want to add nano devices to our code for one
23:02:12 <Masari45> this is all old hat for you lot but it seams miles away for us with out a dev
23:05:13 <Masari45> 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
23:06:00 <moneromooo> Totally depends how much stuff you changed really. Only you know that.
23:07:08 <Masari45> under stand that thank you
23:07:26 <moneromooo> 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.
23:08:21 <Masari45> sorry ledger yes i have beed advised the code is there but not configured
23:10:22 <Masari45> may 18 is where i believe the changes were made to your code allowing the devices to be used
23:12:21 <Masari45> is a patch something i could pay for ?
23:13:00 <Masari45> would anybody do the patch ? as you say if you dont ask the question you never know
23:14:16 <Masari45>  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.
23:14:36 <asymptotically> the git history from monero in the masari project is destroyed which makes it annoying
23:15:37 <Masari45> i can get any info any branch i have been offered that info i just do not know what to ask for
23:16:26 <Masari45> if i am honest i refuse to let masari die because the dev is lazy and cant be bothered
23:21:00 <moneromooo> There's src/device too.
23:22:35 <Masari45> that was a list of files that need to be looked at to be able to start the integration
23:23:13 <Masari45> i sure you can tell i am no dev but i am not afraid to ask questions and beg fro help when required
23:24:28 <MeowMeowMeowMeow> Did msr end up rebasing?
23:24:32 <Masari45> 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 https://discord.gg/Q52RVm3
23:25:26 <Masari45> 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
23:25:45 <Masari45> no we not been rebased
23:26:31 <Masari45> 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
23:27:26 <MeowMeowMeowMeow> 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
23:28:23 <Masari45> whats the best way to do that create a for form Xmr now or change al the code upto that point
23:29:07 <Masari45> sorry fork even from github
23:32:31 <moneromooo> 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.