< bitcoin-git> [bitcoin] achow101 opened pull request #18204: descriptors: improve descriptor cache and cache xpubs (master...desc-xpub-cache) https://github.com/bitcoin/bitcoin/pull/18204
< bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/225aa5d6d519...a674e89d2771
< bitcoin-git> bitcoin/master 12a2f37 practicalswift: util: Avoid potential uninitialized read in FormatISO8601DateTime(int64_t ...
< bitcoin-git> bitcoin/master a674e89 fanquake: Merge #18162: util: Avoid potential uninitialized read in FormatISO8601Dat...
< bitcoin-git> [bitcoin] fanquake merged pull request #18162: util: Avoid potential uninitialized read in FormatISO8601DateTime(int64_t) by checking gmtime_s/gmtime_r return value (master...FormatISO8601DateTime-unitialized-read) https://github.com/bitcoin/bitcoin/pull/18162
< bitcoin-git> [bitcoin] fanquake closed pull request #16523: Add removemempoolentry RPC to evict transactions from the mempool (master...removemempoolentry) https://github.com/bitcoin/bitcoin/pull/16523
< bitcoin-git> [bitcoin] fanquake closed pull request #15873: Rpc removemempoolentry (master...rpc-removemempoolentry) https://github.com/bitcoin/bitcoin/pull/15873
< bitcoin-git> [bitcoin] fanquake closed pull request #16486: [consensus] skip bip30 checks when assumevalid is set for the block (master...2019-07-29-fassumevalid-bip34) https://github.com/bitcoin/bitcoin/pull/16486
< bitcoin-git> [bitcoin] fanquake closed pull request #13989: add avx512 instrinsic (master...1-avx512) https://github.com/bitcoin/bitcoin/pull/13989
< bitcoin-git> [bitcoin] fanquake closed pull request #17815: rpc: Make __cookie__ user immune to rpcwhitelist (master...2019-12-rpc-cookie-user-independence) https://github.com/bitcoin/bitcoin/pull/17815
< ariard> #17443 has been rebased and is quite simple to review and push forward wallet-node refactoring (though maybe conflicts with other wallet PRs)
< gribble> https://github.com/bitcoin/bitcoin/issues/17443 | Drop checkFinalTx and use Median Time Past to check finality of wallet transactions by ariard · Pull Request #17443 · bitcoin/bitcoin · GitHub
< hadjiszs> sipa: MarcoFalke: is there someone working on dandelion++ implementation as for BIP156 ? I am planning to work on top of your #13947
< gribble> https://github.com/bitcoin/bitcoin/issues/13947 | Dandelion transaction relay (BIP 156) by MarcoFalke · Pull Request #13947 · bitcoin/bitcoin · GitHub
< sipa> hadjiszs: i believe dandelion os a dead end
< aj> sipa: hmm, i thought that was just "it's a lot more work than we thought" not "it's impossible and not worth further work" ?
< sipa> i pretty much believe there isn't a reasonable solution that ticks all the boxes
< sipa> i don't have a strong argument for this, and would be very happy to be convinced otherwise
< aj> ok, i'll remain naively optimistic then
< bitcoin-git> [bitcoin] fanquake closed pull request #18116: depends: Use clang for Ubuntu 16.04 (master...20200211-clang-ubuntu) https://github.com/bitcoin/bitcoin/pull/18116
< bitcoin-git> [bitcoin] practicalswift opened pull request #18206: tests: Add fuzzing harness for bloom filter classes (CBloomFilter + CRollingBloomFilter) (master...fuzzers-bloom_filter) https://github.com/bitcoin/bitcoin/pull/18206
< bitcoin-git> [bitcoin] meshcollider pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/a674e89d2771...03f98b15ad4f
< bitcoin-git> bitcoin/master 2ce3447 Vasil Dimov: Deduplicate the message verifying code
< bitcoin-git> bitcoin/master f8f0d98 Vasil Dimov: Deduplicate the message signing code
< bitcoin-git> bitcoin/master e193a84 Jeffrey Czyz: Refactor message hashing into a utility function
< bitcoin-git> [bitcoin] meshcollider merged pull request #17577: refactor: deduplicate the message sign/verify code (master...message-dedup) https://github.com/bitcoin/bitcoin/pull/17577
< bitcoin-git> [bitcoin] meshcollider pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/03f98b15ad4f...31c0006a6cd5
< bitcoin-git> bitcoin/master 29a21c9 Sjors Provoost: [rpc] set default bip32derivs to true for psbt methods
< bitcoin-git> bitcoin/master 5bad792 Sjors Provoost: [test] PSBT RPC: check that bip32_derivs are present by default
< bitcoin-git> bitcoin/master 31c0006 Samuel Dobson: Merge #17264: rpc: set default bip32derivs to true for psbt methods
< bitcoin-git> [bitcoin] meshcollider merged pull request #17264: rpc: set default bip32derivs to true for psbt methods (master...2019/10/bip32_derivs) https://github.com/bitcoin/bitcoin/pull/17264
< provoostenator> AppVeyor is in a bad mood again.
< bitcoin-git> [bitcoin] sipsorcery opened pull request #18207: WIP: Touch appveyor vcpkg file to force refresh (master...appveyor-force-refresh) https://github.com/bitcoin/bitcoin/pull/18207
< provoostenator> Surprising number of "needs rebase" after #17577, even though most of those PRs built right on top of it.
< gribble> https://github.com/bitcoin/bitcoin/issues/17577 | refactor: deduplicate the message sign/verify code by vasild · Pull Request #17577 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] sipsorcery closed pull request #18207: WIP: Touch appveyor vcpkg file to force refresh (master...appveyor-force-refresh) https://github.com/bitcoin/bitcoin/pull/18207
< instagibbs> yeah annoying, but review should be pretty simply
< instagibbs> simple
< vasild> I just checked #18115 for example. It is "based" on #17577 but the commit ids are different: https://0bin.net/paste/ZgRPbnAXjrPZvk9Q#KZaaPhwa3QeB34w8wMdr5JVyKwkl+WaVI9rcjfb5H7z
< gribble> https://github.com/bitcoin/bitcoin/issues/18115 | wallet: Pass in transactions and messages for signing instead of exporting the private keys by achow101 · Pull Request #18115 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/17577 | refactor: deduplicate the message sign/verify code by vasild · Pull Request #17577 · bitcoin/bitcoin · GitHub
< vasild> so, from git perspective #18115 is not based on #17577
< gribble> https://github.com/bitcoin/bitcoin/issues/18115 | wallet: Pass in transactions and messages for signing instead of exporting the private keys by achow101 · Pull Request #18115 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/17577 | refactor: deduplicate the message sign/verify code by vasild · Pull Request #17577 · bitcoin/bitcoin · GitHub
< vasild> I tried to rebase achow101/sign-in-spkman on top of bitcoin/master and got a conflict not related to 17577, but due to #17264 which modified src/wallet/psbtwallet.h (git show 29a21c906 -- src/wallet/psbtwallet.h) and 18115 deleted the file. To resolve, I replayed the change on wallet.h: git rebase bitcoin/master ; git rm src/wallet/psbtwallet.h ; sed -i '' 's/bip32derivs = false/bip32derivs =
< gribble> https://github.com/bitcoin/bitcoin/issues/17264 | rpc: set default bip32derivs to true for psbt methods by Sjors · Pull Request #17264 · bitcoin/bitcoin · GitHub
< vasild> true/' src/wallet/wallet.h ; git add src/wallet/wallet.h ; git rebase --continue
< sdaftuar> sipa: around? i was just discussing wtxid-relay with gleb, he brought up that the erlay proposal included a 128-bit wtxid-relay component as well, which made me think that if we wanted to go that route, i should just update my proposal for wtxid-relay to do that
< sipa> sdaftuar: yeah, that seems reasonable
< sdaftuar> sipa: but that made me wonder if 128-bit commitments are secure enough for transaction relay; seems like in protocols where multiple parties are jointly constructing transactions, you only get 64-bit security against collisions, which could be used to interfere with relay?
< sipa> hmm
< sipa> 2^64 is still an enormous amount of work... not "impossible", but it's still several days with a modern ASIC miner
< gleb> For the context, there's no real need to use 128-bit in Erlay, it's just an additional bandwidth saving, maybe about 5% of the overall bandwidth a node consumes.
< sipa> (assuming an ASIC could even be used for that purpose of course)
< sipa> and at those cost levels there are probably easier ways to interfere with relay
< bitcoin-git> [bitcoin] yusufsahinhamza opened pull request #18208: rpc: Fix RPCExamples (master...fix-rpc-examples) https://github.com/bitcoin/bitcoin/pull/18208
< sdaftuar> right, and maybe protocols today work in such a way to make this not really an issue, just hard for me to reason about it
< bitcoin-git> [bitcoin] yusufsahinhamza closed pull request #18197: rpc: update some RPCExamples to bech32 (master...rpc-examples) https://github.com/bitcoin/bitcoin/pull/18197
< sipa> sdaftuar: like... you could just create a double spend instead
< bitcoin-git> [bitcoin] yusufsahinhamza reopened pull request #18197: rpc: update some RPCExamples to bech32 (master...rpc-examples) https://github.com/bitcoin/bitcoin/pull/18197
< sipa> so i think the goal is making sure relay isn't worse accidentally
< sipa> rather tha intentionally
< MarcoFalke> PSA to review locally. GitHub is again serving corrupt pull requests on the website
< achow101> vasild: usually when I base a PR on other commits, we just cherry pick those commits and base the whole thing on whatever the master was at that time
< achow101> so the commit hashes won't match, but the diffs do
< achow101> then during a rebase, those commits can be dropped and the overall diff stays the same
< vasild> achow101: I see, github nevertheless, still prints "This branch has conflicts that must be resolved ... src/util/message.h" even though when I tried the rebase there was not a conflict in src/util/message.h
< MarcoFalke> vasild: GitHub backend is down or lagging, so that might be the issue
< sdaftuar> sipa: not sure i follow... are there protocols where you and i might produce a multisig transaction (signing a shared output i can't double-spend),but where interfering with the relay of that jointly-constructed transaction is beneficial to me somehow?
< sdaftuar> ie in lightning
< achow101> It's normal for github to say there's a merge conflict when the files that were modified by the base PR gets merged
< sdaftuar> this might be easier for me to talk about if i actually had any idea how lightning works, let me ask someone here :)
< sipa> sdaftuar: oh good point, let me think more
< vasild> achow101: yes, all good
< sipa> sdaftuar: somehow i thought a collision would need multiple parties to collaborate; need more caffeine
< sdaftuar> i just talked it through with matt and he seems to believe that what i'm saying would be a concern in lightning (at least theoretically -- as a practical matter i have no idea)
< sipa> another possibility is just skipping 128-bit wtxid for now, and doing it as a later step (orthogonal to wtxid and erlay)
< sipa> or not
< gleb> I'm afraid that means that final potential version will have to support txid, wtxid, and trunc-wtxid, so 3 different filters?
< bitcoin-git> [bitcoin] yusufsahinhamza closed pull request #18197: rpc: update some RPCExamples to bech32 (master...rpc-examples) https://github.com/bitcoin/bitcoin/pull/18197
< sipa> gleb: at least with ordered indexes, one index suffices for both 128-bit and 256-bit lookups
< sipa> ah, but the current mempool index is not ordered
< sdaftuar> my instinct is that for a 5% bandwidth savings (once we have erlay), it's not really worth the effort to try to convince ourselves that the truncated hash is safe, but i feel a bit bad being a defeatist
< gleb> Yeah, at this point I'd also prefer to stick with 256-bit ids, for the reason suhas points out. I also bet someone smart would decide to waste their time to write a paper about attacking bitcoin with this thing :)
< sipa> maybe that's indeed best
< bitcoin-git> [bitcoin] kiminuo opened pull request #18210: Type hints in Python tests (master...feature/type-hint-minimum) https://github.com/bitcoin/bitcoin/pull/18210
< instagibbs> gleb, another way to look at it is including truncated wtxid may slow down erlay, which has asymptotic win, not just %
< instagibbs> wrt number of peers
< instagibbs> slow down acceptance of erlay*
< gleb> instagibbs: Why would it slow down the acceptance of erlay?
< instagibbs> another bikeshedding/discussion, just like here :)
< instagibbs> maybe I'm wrong, then nevermind me
< sipa> instagibbs: that's boring, sure you're not up for a trial by combat to determine who is right?
< gleb> instagibbs: In this particular case I was less optimistic about people caring, but yeah, you're right in that sense.
< bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/31c0006a6cd5...c3b471592346
< bitcoin-git> bitcoin/master 2a6a6ea practicalswift: tests: Add fuzzing harness for bloom filter class CBloomFilter
< bitcoin-git> bitcoin/master eabbbe4 practicalswift: tests: Add fuzzing harness for rolling bloom filter class CRollingBloomFil...
< bitcoin-git> bitcoin/master c3b4715 MarcoFalke: Merge #18206: tests: Add fuzzing harness for bloom filter classes (CBloomF...
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #18206: tests: Add fuzzing harness for bloom filter classes (CBloomFilter + CRollingBloomFilter) (master...fuzzers-bloom_filter) https://github.com/bitcoin/bitcoin/pull/18206
< sdaftuar> jeremyrubin: around?
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #18211: test: Work around scheduler_tests intermittent failures (take 2) (master...2002-testSchedulerWorkaround) https://github.com/bitcoin/bitcoin/pull/18211
< achow101> what would cause std::map to not find an element that's definitely there?
< achow101> examining in gdb tells me the element is there and the key I'm searching with is correct. but it always returns end()
< sipa> achow101: was the key elememt modified after inserting?
< achow101> no
< sipa> what is the key type?
< achow101> KeyOriginInfo. I added an operator<
< sipa> what pr?
< achow101> I haven't pushed it yet. it's supposed to be a modification to #18204
< gribble> https://github.com/bitcoin/bitcoin/issues/18204 | descriptors: improve descriptor cache and cache xpubs by achow101 · Pull Request #18204 · bitcoin/bitcoin · GitHub
< sipa> ok link to code/branchm
< sipa> ?
< achow101> descriptor_tests fails currently due to that maps thing
< sipa> your operator< is inconsistent
< achow101> it is?
< sipa> if a.fingerprint > b.fingerprint you have to return false
< sipa> even if a.path < b.path
< achow101> ah
< sipa> the general structure of such comparators is something like: if a.x < b.x return true; if a.x > b.x return false; if a.x == b.x fall through to next tie breaker
< achow101> I guess that explains why it only failed with the multi descriptors too
< achow101> when I had more than one xpub in the map
< sipa> right