< jeremyrubin>
harding: sdaftuar: if you were going to use sequences, you could also more simply just use a linked-list style tree which puts out b outputs per layer.
< jeremyrubin>
Which would enforce some sequencing
< jeremyrubin>
but it would be less fun to be at the end of such a tree
< jeremyrubin>
> [07:25] <sdaftuar> jeremyrubin: one practical thought to the issue you're seeing with a payment to 1000 outputs using a radix of 4: couldn't the sender just put a likely-to-be-confirmed-soon fee on the first five transactions (top 2 levels of the tree)? seems like that's a really small number of bytes, and once those are confirmed the situation gets much better
< jeremyrubin>
Yes this is possible, but can still get locked out if someone publishes one branch and then pays a higher fee on their descendant then saturates the descendant limit
< jeremyrubin>
Which would then lock up the higher ones
< bitcoin-git>
bitcoin/master cd68594 Andrew Chow: Only check the hash of transactions loaded from disk
< bitcoin-git>
bitcoin/master a884b32 Wladimir J. van der Laan: Merge #16911: wallet: Only check the hash of transactions loaded from disk...
< bitcoin-git>
[bitcoin] laanwj merged pull request #16911: wallet: Only check the hash of transactions loaded from disk (master...wallet-skip-checktx) https://github.com/bitcoin/bitcoin/pull/16911
< bitcoin-git>
[bitcoin] practicalswift opened pull request #17225: tests: Test serialisation as part of deserialisation fuzzing. Test round-trip equality where possible. (master...fuzzers-deserialize-with-roundtrip) https://github.com/bitcoin/bitcoin/pull/17225
< wumpus>
(harmless) new clang warning: bitcoin/src/qt/guiutil.cpp:855:26: warning: implicit conversion from 'long' to 'double' changes value from 9223372036854775807 to 9223372036854775808 [-Wimplicit-int-float-conversion]
< bitcoin-git>
[bitcoin] promag opened pull request #17226: gui: Fix payAmount tooltip in SendCoinsEntry (master...2019-10-payamount-tooltip) https://github.com/bitcoin/bitcoin/pull/17226
< bitcoin-git>
[bitcoin] practicalswift opened pull request #17229: tests: Add fuzzing harnesses for various Base{32,58,64} and hex related functions (master...fuzzers-base_encode_decode) https://github.com/bitcoin/bitcoin/pull/17229
< sdaftuar>
sipa: i saw there is some discussion (now partially deleted) on aj's PR relating to mapRelay and its future
< sdaftuar>
i want to make sure i understand your concern. my idea for mapRelay is to nuke it but continue to achieve its goal of not leaking information about transactions until we intend to
< sdaftuar>
(in fact, it falls short in its privacy goal right now due to a bug, which i would like us to improve)
< sipa>
that sounds good
< sdaftuar>
i don't believe anyone to my knowledge is proposing that we get rid of mapRelay and allow indiscriminate probing of our mempool contents -- i assume that is what you were objecting to?
< sipa>
i was just confused by the "it's not a privacy leak to change this, because there is already another leak" comment, without looking at the code
< sipa>
because that sounded like a terrible justification
< aj>
sipa: it makes it easier to see old tx's still in your mempool, and to obtain a copy of them. doesn't affect brand new tx's
< sdaftuar>
i'm not sure what marco means there. your earlier comment about testing the comments of our mempool is a subtle question, i think - the answer to that depends on the context?
< sdaftuar>
ie i think we should try to hide recently relayed transactions, but there's probably no transaction-relay-related privacy benefit to not serving things in our mempool that are old
< sipa>
well i was under the mistaken impression that this PR was giving up on mempool-presence testing, because of the "this is not leaking anything because things can be tested otherwise"
< sipa>
sorry, i shouls not have commented before looking at the PR
< sdaftuar>
ok, understood. i do think there are potential non-transaction-privacy related concerns with serving old mempool contents that could be brought up, so i don't want to gloss over any such issues if people think they're worth worrying about
< sdaftuar>
for instance: i think greg once mentioned that you could turn the bitcoin network nodes' mempools into a distributed file system
< sdaftuar>
another possible concern is if we exacerbate fingerprinting attacks
< sdaftuar>
i tend to think that the first concern is something we could expend engineering manpower to combat if it became a problem
< sdaftuar>
and the latter is overshadowed by other ways we can fingerprint that are not so easily stopped
< sipa>
geah
< sipa>
yeah
< bitcoin-git>
[bitcoin] theuni opened pull request #17231: depends: fix boost mac cross build with clang 9+ (master...fix-boost-clang9) https://github.com/bitcoin/bitcoin/pull/17231
< fanquake>
"Fixed" in Clang 9 by changing the output of -dumpversion from a hardcoded 4.2.1, to Clangs actual version.
< bitcoin-git>
[bitcoin] adamjonas opened pull request #17232: Sanity assert GetAncestor() != nullptr where appropriate (master...assert_get_ancestor) https://github.com/bitcoin/bitcoin/pull/17232
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #17233: travis: Run unit and functional tests on native arm (master...1910-travisNativeArm) https://github.com/bitcoin/bitcoin/pull/17233
< dongcarl>
I'm reading the codebase right now and it seems like we query DNS seeds before we use the fixed seeds? Is that right? Why do we do it this way?
< sipa>
dongcarl: static seeds are an absolute last resort
< dongcarl>
sipa: Why not use static seeds before we query DNS?
< harding>
dongcarl: because the fixed seeds are fallbacks in case the dynamic seeds (DNS) aren't working for some reason. The fixed seeds are just the results of a DNS query from probably months before when the software was in pre-release.
< sipa>
because we ideally never use hardcoded static centralized-by-committee-chosen sets of IPs for this
< harding>
The DNS seeds are recent results of nodes that were known to be up recently.
< sipa>
they're a very last resort
< dongcarl>
but aren't DNS seeds even more centralized-by-committee? I can see the case for "known to be up recently"...
< sipa>
right, but at least those are only used to query other IP addresses
< sipa>
rather than directly being IP addresses that are thrown direclty into addrman
< dongcarl>
sipa: Well aren't they functionally the same? Someone who takes over the DNS seeds can also affect what's in your addrman? Or am I missing something
< sipa>
i think you're right
< MarcoFalke>
I think if you query by DNS seeds, you'll ask at least three random ones. So an attacker would have to take over all of them to achieve 100% takeover.
< sipa>
there are other differences though... using the static seeds will just result in lots of connections to those IPs, which didn't actually ever commit to being online a lot of the te
< dongcarl>
I wonder what the use expectation is when they specify `-onlynet=onion`
< dongcarl>
user*
< dongcarl>
If we have hard-coded `.onion` addresses, I feel like those should be tried first, instead of the weird "connect thru an exit node to the address that one of the seeds resolve through" thing
< bitcoin-git>
bitcoin/master 4896bac MapleLaker: Add testcase to simulate bitcoin schema in leveldb
< bitcoin-git>
bitcoin/master c5ac7af MarcoFalke: Merge #17206: test: Add testcase to simulate bitcoin schema in leveldb
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #17206: test: Add testcase to simulate bitcoin schema in leveldb (master...dbwrapper_basic_data) https://github.com/bitcoin/bitcoin/pull/17206
< bitcoin-git>
[bitcoin] practicalswift opened pull request #17235: tests: Skip unnecessary fuzzer initialisation. Hold ECCVerifyHandle only when needed. (master...fuzz-initialize-when-needed) https://github.com/bitcoin/bitcoin/pull/17235