< bitcoin-git> [bitcoin] fanquake pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/be375b2206fe...ba4b3fbcf213
< bitcoin-git> bitcoin/master b9c1a76 Pieter Wuille: Squashed 'src/secp256k1/' changes from 2ed54da18a..8ab24e8dad
< bitcoin-git> bitcoin/master 894fb33 Pieter Wuille: Update src/secp256k1 subtree to upstream libsecp256k1
< bitcoin-git> bitcoin/master ba4b3fb fanquake: Merge #19944: Update secp256k1 subtree (including BIP340 support)
< bitcoin-git> [bitcoin] fanquake merged pull request #19944: Update secp256k1 subtree (including BIP340 support) (master...202009_secp256k1_schnorr) https://github.com/bitcoin/bitcoin/pull/19944
< bitcoin-git> [bitcoin] sipa closed pull request #17977: Implement BIP 340-342 validation (Schnorr/taproot/tapscript) (master...taproot) https://github.com/bitcoin/bitcoin/pull/17977
< bitcoin-git> [bitcoin] sipa opened pull request #19953: Implement BIP 340-342 validation (Schnorr/taproot/tapscript) (master...taproot) https://github.com/bitcoin/bitcoin/pull/19953
< aj> eek, github lets you click checkboxes in PRs and automatically edits them?
< sipa> yes
< sipa> i don't think just anyone can click them, though
< aj> i guess you can just unclick it, but still
< fanquake> aj: stop clicking all the buttons :p
< sipa> grr travis
< sipa> it somehow used the old commit branch to fetch from
< sipa> must be a very weird caching effect
< fanquake> Just another reason to never blindly trust "green ticks" and CIs
< aj> fanquake: i didn't think it was a button i was clicking!
< sipa> ok, fixed by pushing again it seems
< phantomcircuit> what? push all the buttons
< phantomcircuit> sipa, is accurate
< jeremyrubin> aj: all the noise on the lock annotations PRs makes me slightly hesitant on the epoch lock annotation patch fwiw; it seems like there's disagreement/confusion about what the annotations are or are not doing.
< aj> jeremyrubin: yeah :(
< sipa> phantomcircuit: it's xkcd, of course it's accurate
< kallewoof> very nathan pyle'esque
< bitcoin-git> [bitcoin] vasild closed pull request #19929: sync: use proper TSA attributes (master...use_proper_tsa_attributes) https://github.com/bitcoin/bitcoin/pull/19929
< bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/ba4b3fbcf213...06dbbe76dd02
< bitcoin-git> bitcoin/master 812037c Pieter Wuille: Change CSipHasher's count variable to uint8_t
< bitcoin-git> bitcoin/master 06dbbe7 fanquake: Merge #19931: Change CSipHasher's count variable to uint8_t
< bitcoin-git> [bitcoin] fanquake merged pull request #19931: Change CSipHasher's count variable to uint8_t (master...202009_siphash_sillyness) https://github.com/bitcoin/bitcoin/pull/19931
< bitcoin-git> [bitcoin] vasild opened pull request #19954: tor: make a TORv3 hidden service instead of TORv2 (master...torv3) https://github.com/bitcoin/bitcoin/pull/19954
< jb55> achow101: is it possible to corrupt wallets when jumping between master and v0.20.1? trying to figure out how all my wallets got nuked
< achow101> jb55: was it a descriptor wallet?
< achow101> otherwise, they shouldn't be corrupted
< jb55> well I loaded one to test, and obviously that failed to load when I went back. but I have really old wallets and wallets I've imported with importmulti. all of them have random keys in them now. its super weird: https://jb55.com/s/6ae99d5e19df80a3.png
< jb55> all of them have private keys enabled as well even though they were all watch only before
< jb55> if this is corruption its super weird no?
< achow101> sounsd like the private keys disabled flag got lost somehow
< achow101> which would be considered corruption
< jb55> for some reason when I upgraded to 0.20.1 it redownloaded the entire blockchain and all my wallets are unrecognizable/didn't pick up any txs during rescan
< jb55> something super weird going on
< achow101> that seems like a datadir issue
< jb55> guess I this gives me a change to reimport everything as descriptor wallets :P
< sipa> wumpus: it seems 0.20.1 is not bitcoin.org yet? https://github.com/bitcoin-dot-org/Bitcoin.org/pull/3435
< phantomcircuit> jb55, did you build against the right version of bdb?
< phantomcircuit> oh nvm that doesn't seem like a version mismatch
< jb55> I had the same thought but I didn't see any bdb updates between the nixpkgs revisions I updated
< jb55> but the fact that the blockchain redownloaded and all my wallets are scrambled seems to point to something going very wrong on my zfs storage after I updated my kernel/nixpkgs. still haven't figured it out though
< jb55> just surprised the wallets didn't fail to load and they're just filled with random keys I don't recognize =/
< luke-jr> :|
< phantomcircuit> jb55, is your zfs array mounted?
< jb55> phantomcircuit: what do you mean?
< sipa> jb55: i assume phantomcircuit means: is it possible you started bitcoind with the intended FS not mounted? if so, bitcoind would create fresh wallet(s)
< jb55> sipa: oh that seems likely, since they all look like new wallets
< jb55> now I'm wondering where the old ones went =/
< sipa> it would also explain why your node is starting sync from scratch :)
< phantomcircuit> jb55, often when upgrading kernels or zfs you can endup with zfs not actually loading filesystems or mounting them
< phantomcircuit> sounds like that's what happened
< jb55> well that's incredibly annoying
< phantomcircuit> the files are still in zfs probably you just have to actually mount the fs
< sipa> solution: use ZFS as your root filesystem
< sipa> that way it'll just fail to boot if something goes wrong
< luke-jr> XD
< sipa> (not joking, it's what i do)
< luke-jr> or even if it's /home, nothing should autocreate the dirs per user
< luke-jr> sipa: I also use ZFS for root
< sipa> cool
< jb55> I created a mountpoint /zbig/bitcoin on top of my /zbig hdd so that I could snapshot specifically that directory and none others. I think this is where I f'd up somehow
< jb55> I do use zfs for root as well on my ssd, but I don't think that was the issue here. definitely some mounting issue. thx guys
< sipa> woah! github now lists commits in a PR in topological order?
< sipa> when did that changer?
< jb55> finalllyyy
< sdaftuar> \o/
< luke-jr> inb4 we are merely inside sipa's dream
< sipa> i guess by "chronological order in the head branch" they mean topological...
< luke-jr> lol @ using chronological for the opposite
< sipa> ah, i think it may mean it's sorting by the internal "CommitDate" value in commits, which is reset on rebasing
< sipa> rather than the usually shown AuthorDate value, which is not normally rewritten
< sdaftuar> so my commit-date-grinding tool might break this? doh.
< * sipa> inspects sdaftuar's old commits
< sdaftuar> (actually, now i don't remember what timestamp i was grinding on, i should check)
< sdaftuar> sweet, i was using AuthorDate, good to go
< luke-jr> sdaftuar: grind? just set it.. :P
< phantomcircuit> luke-jr, presumably he was grinding the short id
< sdaftuar> much better version of #19858 if you ask me
< gribble> https://github.com/bitcoin/bitcoin/issues/19858 | Periodically make block-relay connections and sync headers by sdaftuar · Pull Request #19858 · bitcoin/bitcoin · GitHub
< sipa> what's ground about it? (that's the past tense of to grind, right?)
< sdaftuar> "daf..."
< sipa> ah!
< sdaftuar> i think the "t" was going to be hard
< sipa> sdaftuar: i don't see any actual commits in the bitcoin/bitcoin history though
< sipa> *like that
< sdaftuar> sipa: i guess this version of #15141 was never merged (though it would have been fun): https://github.com/sdaftuar/bitcoin/commits/15141.9
< gribble> https://github.com/bitcoin/bitcoin/issues/15141 | Rewrite DoS interface between validation and net_processing by sdaftuar · Pull Request #15141 · bitcoin/bitcoin · GitHub
< phantomcircuit> sdaftuar, i thought grinding was relatively cheap?
< sipa> it should just be SHA-1 hashing
< sipa> of the entire commit body + headers, though
< phantomcircuit> i guess to actually do it efficiently you'd need to be grinding something at the of the commit body
< luke-jr> phantomcircuit: that's the commit message
< phantomcircuit> or make the entire headers + commit body less than 80 bytes
< sipa> just end the commit with "Here is a random hex string! 2f3a531408d18276e183ab216c"
< phantomcircuit> 40 bytes?
< sipa> *message
< aj> sdaftuar: could use 5 as a standin for s?
< bitcoin-git> [bitcoin] n1rna opened pull request #19956: rpc: Improve invalid vout value rpc error message (master...rpc-invalid-vout-message) https://github.com/bitcoin/bitcoin/pull/19956
< yanmaani> What happened to the headers-only/SPV mode? (fClient)
< sipa> ?
< emzy> how to request onion addresses from a dnsseed?
< sipa> emzy: they're just treated as IPv6 (using onioncat encoding)
< sipa> i guess there could be a request flag for that
< * sipa> makes mental note: crap, not compatible with torv3
< emzy> but how to request.
< sipa> emzy: request AAAA records
< emzy> sipa: I had that realisation also.
< sipa> there is no special way to restrict just those
< sipa> emzy: on the other hand, when you're using bitcoin behind tor, you probably don't want to use dnsseeds in the first place, but addr_fetch nodes, which don't have that problem
< emzy> dig -t aaaa x49.dnsseed.emzy.de
< emzy> Yes I think there is a way to use dns with tor.
< emzy> over tor.
< luke-jr> what would tor do if we had a well-known onion privkey?
< luke-jr> would it do a sane anycast?
< emzy> btw. I have the import to bind working. I'm now setting up a test dns server.
< sipa> emzy: if you use bitcoin core with -proxy, dns seeds are not used directly; instead, a connection is made to the NS name of the DNS seeds (which in case of tor causes the exit node to resolve it, pick a random result, and forward the connection there), and a getaddr is requested, and the connection is closed after getting a response
< sipa> so in that scenario, the fact that dns seeds can't encode torv3 address isn't really a problem - the addr response will
< emzy> I see.
< luke-jr> sipa: sounds attackable
< sipa> how so?
< luke-jr> sipa: an attacker would just ensure his is publsihed most recently
< sipa> luke-jr: you're not supposed to share private keys with other parties
< sipa> i'm just answering what would answer if you did; i don't think it's a supported use case or advisable
< sipa> s/answer/happen/
< yanmaani> luke-jr: I don't think that would be stable.
< yanmaani> If you want load balancing, there's onionbalance
< luke-jr> yanmaani: I want trustless anycast
< luke-jr> yanmaani: route to any random node(s)
< yanmaani> nope, that wouldn't work
< yanmaani> For what purpose? Transaction broadcasting?
< yanmaani> One approach to that would be to make all Bitcoin nodes connect to the BitTorrent DHT, then randomly enter the BitTorrent DHT by brute-forcing IPv4 IPs (<200 UDP packets on average), and then broadcast to them. Or you could have Bitcoin receive transactions on UDP, and just send them to
< yanmaani> 2^32 * 250 / 100 MBit = 24h
< phantomcircuit> emzy, you can do all the dns requests over tcp over tor, but that's kind of insane
< emzy> Why insane?
< emzy> For torsocks docs: "torsocks can force the libc resolver to use TCP for name queries, if it does this it does it regardless of whether or not the DNS to be queried is local or not. This introduces overhead and should only be used when needed. "