< moneyball>
is btcdrak still active / engaged with the Core project?
< gmaxwell>
No, drak has been gone a long time (and clearly someone else can tweet on that account, since the last tweets there were after drak was gone)
< sipa>
moneyball, gmaxwell: i think drak owns the account, but there is some shared access setup that lets certain others tweet from it, including me
< wumpus>
gmaxwell moneyball yes, I can log into the twitter
< wumpus>
have done version announcements a few times, it used to be btcdrak but they disappeared
< wumpus>
moneyball: soliciting discussions about things on twitter tends to be a really bad idea
< wumpus>
expect it will be 100% conspiracy theories and what not
< wumpus>
(there's nothing wrong with asking that question on twitter on your own personal accord, but having it come from "bitcoin core" is going to cause lots of noise)
< luke-jr>
is there a reason we build the test node caches without wallets, and then have all the nodes rescan the blockchain when each test starts? (cc MarcoFalke)
< luke-jr>
as opposed to just caching the wallets too?
< gmaxwell>
luke-jr: that sure sounds intentional
< wumpus>
luke-jr: it used to be the case that the entire data directory was cached, including wallet, that was changed for multiple reasons; different tests might have different wallet requirements, or no wallet requirements at all being the main one
< wumpus>
luke-jr: another one is that it used to be that the cache was preserved for multiple runs, so changes to wallet code would not be tested properly due to stale cache (I don't think this concern exists anymore)
< gmaxwell>
I think it's remarkable that you can't have twitter accounts or tweets that can't be replied to. "announce only" (of course, people could repeat things and disuss them, but their potentiall innane discussion wouldn't be stapled to your announcement.
< wumpus>
gmaxwell: there was a proposal to add that functionality to mastodon, but somehow it became *really* controversial
< wumpus>
I tend to agree it would be extremely useful for announcements, though, the way thread viewing works makes it so easy for people to staple inane troll replies or self-promotion to announcements and this happens all the time
< wumpus>
luke-jr: ideally, most of the tests would be able to run without wallet, there's some initiative in that direction
< gmaxwell>
It's really unfortunate, this culture of everyone gets to scribble over everyhing is so sad. I understand that Twitter lets you block people who reply with dumb stuff, but thats overpowered and creates its own drama.
< wumpus>
moneyball: in any case if you or anyone else want to sollicit feedback on address formats, I'm happy to retweet it on my main twitter account
< luke-jr>
wumpus: having a wallet file shouldn't impede -disablewallet ..?
< wumpus>
luke-jr: no, it doesn't, and copying the cache could be selective so that only tests that require the specific pre-cached wallet copy it; however this is somewhat more finnicky than the current approach
< wumpus>
luke-jr: it has been shown that caching can really mess with test results if not careful, so only do it if it saves significant time
< luke-jr>
well, in this case, it's breaking the zmqwallettx tests because the rescan causes every coinbase (in that wallet) to get a ZMQ notify
< wumpus>
I mean, speeding up the tests is definitely worthwhile, they're way too slwo at the moment, but be careful to not introduce any fragile constructions
< luke-jr>
if we want that behaviour to stay, it's possible to refactor around it I guess
< wumpus>
ok, right
< wumpus>
why is it suddenly breaking the zmqwallettx test?
< luke-jr>
wumpus: because it's rescanning the imported coinbase key at test startup, which triggers the zmq messages
< luke-jr>
the test isn't expecting those messages
< luke-jr>
note this is an unmerged feature
< luke-jr>
so the last time it was rebased was 0.17, before the caching changes
< wumpus>
okay, then I understand
< warren>
I apologize there were further delays in the planned list migration. The test import and configuration testing before a switch over is yet to happen. I think the testing will happen this next week.
< wumpus>
I get it, if it's not much more computationally involved and just as secure (or better) in the classical sense there's no drawback to using post-quantum cryptography, but also no need to rush it and make dumb mistakes
< bitcoin-git>
[bitcoin] fanquake closed pull request #15692: doc: Mention wiki release notes draft in release-process (master...1904-docRel) https://github.com/bitcoin/bitcoin/pull/15692
< achow101>
sipa: is there a reason for having descriptor's Parse return a unique_ptr vs a shared_ptr or something else?
< wumpus>
achow101: any reason why you'd like shared_ptr? unique_ptr tends to be the first choice as it has no extra run-time overhead in the form of reference counting and such
< achow101>
wumpus: i need to be able to pass around descriptors for descriptor wallets and unique_ptr is causing some issues for me, at least with my current design
< sipa>
achow101: you can convert a unique_ptr to a shared_ptr for almost no cost
< achow101>
right, I just wanted to check if there was some constraints that unique_ptr provides that you wanted with descriptors before I did that