< 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.
< 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
< 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