< gmaxwell> sdaftuar: any idea why on #13298 naumenkogs claims that changing the bucket count does not change propagation time? this seems improbable to me in the extreme.
< gribble> https://github.com/bitcoin/bitcoin/issues/13298 | Net: Random delays *per network group* to obfuscate transaction time by naumenkogs · Pull Request #13298 · bitcoin/bitcoin · GitHub
< gmaxwell> Since e.g. 2 buckets should be effectively half the delay to relay to someone.
< gmaxwell> vs 1
< sipa> gmaxwell: because in practice propagation is much faster through outgoing connections
< sipa> (where there is no bucket limit)
< gmaxwell> if it's true, what it means is basically all the propagation is done via outbounds...
< sipa> right
< gmaxwell> which is fine, but then thats an argument for using 1 bucket
< sipa> the argument against 1 bucket is bandwidth spikes
< gmaxwell> right now the code is n=8, r=2, which gleb didn't post images. And his figures give 63% success for first spy.
< gmaxwell> I was expecting 2,4 based on the comment "From these numbers, 2 buckets and R=4 seems optimal."
< nmnkgl> Well, I might have been confusing in my messages. Propagation time is slower 25-40% for r=4 comparing to r=2.
< nmnkgl> Oh, that's about buckets, right.
< gmaxwell> nmnkgl: well we can always decrease the base speed to get the propagation time back.
< gmaxwell> though also I don't have any particular reason to think making propagation slower would be a problem.
< gmaxwell> with the current behavior we still get very close to 100% hitrates on compact blocks.
< gmaxwell> I think past analysis of mining stuff suggested that mining infra had average delays on the order of 30 seconds. (e.g. only giving new work to miners somewhat infrequently)
< nmnkgl> The only thing I'm worried about here is correctness of my results :)
< gmaxwell> nmnkgl: your result isn't surprising if we assume that almost all propagation is done by the outbound side, which is plausable.
< gmaxwell> esp if, as I assume, your topology has all nodes with similar order and all accepting inbound.
< sipa> so the propagation speed across the network should be to some extent influenced by the time until the _first_ broadcast of a given transaction
< nmnkgl> I can measure what fraction is relayed through outgoing if we won't come up with a good explanation.
< sipa> if you have more independent buckets, that time will be lower, because there are more independent broadcast events
< gmaxwell> (luke's figures suggest about 10% of nodes are listening)
< sipa> turns out there is a simple formula for the minimum of multiple exponential distributions
< gmaxwell> sipa: but in terms of estimating e.g. impact on CB performance, the first delay is irrelevant.
< sipa> gmaxwell: no it isn't- as soon as the transaction is out, the rest of the network has a chance to relay it - even to your own peers
< sipa> i didn't mean to claim this is the dominant factor in propagation, but it matters
< gmaxwell> sipa: I just mean that we don't care about the time until the second node gets it, we care about the time between the second node and almost all nodes.
< sipa> something in between, i think
< gmaxwell> why in between?
< gmaxwell> I think we're probably talking past each other.
< sipa> perhaps
< nmnkgl> To be clear, I observed delay of less that 10% if increasing n buckets. In most of the cases up to 5%.
< nmnkgl> To be clear, I observed delay of less than 10% if increasing n buckets. In most of the cases up to 5%.
< gmaxwell> I think all these times are fast enough they're more or less background noise compared to ten minute confirmations and whatnot. But they can potentially impact CB effectiveness.
< sipa> i'm just trying to argue that having more buckets should be espected to reduce overall propagation delay across the network
< sipa> even if the average time for sending to any given peer is the same
< gmaxwell> OH
< gmaxwell> OKAY
< gmaxwell> sorry, you and nmnkgl are focused on debugging his simulation and I keep going off topic and trying to optimize the network.
< sipa> haha ok
< gmaxwell> yes, indeed, I expect the outbound count would change the propagation time, at least for the first hop, even if almost all the propagation happens via outbound links.
< gmaxwell> nmnkgl: simulate with r=1, you should see a very dramatic effect from the number of buckets.
< nmnkgl> will do.
< gmaxwell> would it be hard for you to simulate only 10% of nodes accepting inbounds?
< nmnkgl> Not at all, I already did that for spikes measurement.
< nmnkgl> I will share results tomorrow morning.
< bitcoin-git> [bitcoin] mruddy closed pull request #13596: zmq: update to avoid deprecated zeromq api functions and log zmq version used (master...zmq-deprecation-update) https://github.com/bitcoin/bitcoin/pull/13596
< sipa> jonasschnelli: i realize i'm very late with my review on your scanutxoset RPC... but i'm very surprised by the sweep transaction creation integration
< sipa> a separate createrawsweeptransaction RPC seems much more useful and sane
< sipa> the size estimation looks broken too; it assumes everything is P2SH-P2WSH with a dummy script inside?
< sipa> this is not something you can usefully implement without knowing the scripts involved
< sipa> as is, it seems the feature is identical to createrawtransaction with the unspents listed + a simple vbytes per input constant to estimate size
< sipa> Does it even work? It looks to me that for anything P2SH or P2WSH it won't even include the size of transactions in the estimate.
< sipa> Eh, size of the signatures.
< bitcoin-git> [bitcoin] YutakaNakasone opened pull request #13602: Trivial: delete "to" in comment (master...topic) https://github.com/bitcoin/bitcoin/pull/13602
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/287e4edc2fd2...0212187fc624
< bitcoin-git> bitcoin/master 1fc605a Akio Nakamura: fix bench/prevector.cpp...
< bitcoin-git> bitcoin/master 0212187 MarcoFalke: Merge #13598: bench: fix incorrect behaviour in prevector.cpp...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #13598: bench: fix incorrect behaviour in prevector.cpp (master...fix_bench_prevector) https://github.com/bitcoin/bitcoin/pull/13598
< bitcoin-git> [bitcoin] Sjors closed pull request #13029: Interpret absense of prune= as prune=1 if there are pruned blocks (master...2018/04/implicit_prune) https://github.com/bitcoin/bitcoin/pull/13029
< provoostenator> #12818 could use some (easy!) review love
< gribble> https://github.com/bitcoin/bitcoin/issues/12818 | [qt] TransactionView: highlight replacement tx after fee bump by Sjors · Pull Request #12818 · bitcoin/bitcoin · GitHub
< provoostenator> Unhappy Travis linter (I tried a restart), any idea why? https://travis-ci.org/bitcoin/bitcoin/builds/400849545
< provoostenator> It's also not whitespace, which I tested locally.
< Varunram> provoostenator: Travis says the error is from `test/lint/lint-shell-locale.sh`
< provoostenator> Ok, I'm guessing it wants me to add "export LC_ALL=C" at the top...
< bitcoin-git> [bitcoin] domob1812 opened pull request #13603: bitcoin-tx: Stricter check for valid integers (master...bitcointx) https://github.com/bitcoin/bitcoin/pull/13603
< bitcoin-git> [bitcoin] TheCharlatan opened pull request #13604: Add depends 32-bit arm support for bitcoin-qt (master...Qt59arm) https://github.com/bitcoin/bitcoin/pull/13604
< provoostenator> Another Travis mystery: https://travis-ci.org/bitcoin/bitcoin/jobs/400935074 "Done. Your build exited with 1." but nothing red
< arubi> provoostenator, https://travis-ci.org/bitcoin/bitcoin/jobs/400935074#L1493 , probably needs to be mkdir -p
< arubi> it didn't end up cd'ing into ./build because it's &&'ed
< provoostenator> Ah yes, because I'm now caching the build dir...
< CubicEarths> Exciting to the Schnorr bip submitted!! Is there a size savings on the signature for a standard, non-multisig tx?
< sipa> CubicEarths: read the email :)
< sipa> this is just a signature scheme, not an integration in bitcoin
< CubicEarths> ok ok. I'll re-ask in few months when a similar question becomes answerable :)
< sipa> thanks!
< CubicEarths> looks like a future implementation based on your work might save 8 bytes for a non-multisig tx
< bitcoin-git> [bitcoin] jhfrontz opened pull request #13605: Corrected text to reflect new[er] process of specifying fingerprints (master...update-gitian-keys-README) https://github.com/bitcoin/bitcoin/pull/13605