< 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 #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/18115 | wallet: Pass in transactions and messages for signing instead of exporting the private keys by achow101 · Pull Request #18115 · 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
< 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 =
< 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
< 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?
< 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 :)
< 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