Topic: [minisketch] Draft Erlay tx relay BIP published (Read 319 times)

just quickly pointing out the thread moderation policy:

• no trolling
• no trolls

because bitaps replied to a known troll account, their recent reply was wholly removed.

hmm, so less variance in overall propagation leads to less variance in respective mempools contents over time, and so of course compact block success rate improves. That makes sense, nice consequential effect.

Sure they are, they're required to tell two different transactions apart.

When txs are only identified by txids I can take a valid transaction mutate its witness to make it invalid (or just too low a feerate), and it'll have the same txid, so if you fetch by txid you can't avoid fetching the same junk multiple times-- you can't negative cache the invalid values.

wtxid works much better in that respect.  They need to be computed in any case because otherwise block propagation latency would be much higher,  and the computational cost of hashing a single transaction is pretty negligible in any case (and as mentioned, it's already being done). Switching to wtxid for relay has also been in the works for over three years.

This is a very odd decision in my opinion. Wtxids are not used anywhere (so it shouldn't be pre-computed already) and they are more expensive to compute, since the purpose is "optimization" using them seems to add to the overall time.

Imagine the simplest SegWit transaction, one that is spending 1x P2WPKH and creates 2x new outputs. To compute txid you'd have to compute 2x SHA256 of ~116 bytes but for computing wtxid you'd have to compute 2x SHA256 of ~225 bytes. The first round of these two require: 2 blocks and 4 blocks respectively. So the speed of computing txid in this case is nearly twice the speed of computing wtxid for a simple tx.
If the number of inputs were higher or if this was a longer witness (eg. spending a P2WSH of a 2of3 multisig scheme) the difference would be drastically more.

Simulation seems to show that it improves block propagation delay in fact.

Erlay's latency increase for propagation is almost entirely an increase in latency of the first hop.

Overall with the recommended parameters in simulation the result has transactions take a little longer to propagate but there is less variance in their overall propagation time.  This improves the block propagation speed because more often if a miner includes a txn everyone already has it. ... at least in simulation.

I wouldn't promote that as an advantage, because miners adding a small delay before including transactions would likely have a much greater non-additive effect ...  but it doesn't appear the an increase in orphaning is likely, at least.

We're mostly past that point. The same people they could deceive by doing that can be even better deceived by pure jargon-technobabble, and the Bitcoin industry won't even bother to call out the fraud in that case.  If they just copy bitcoin they'll be constrained by the realism of the bitcoin discussion of the copied tech and also risk irritating bitcoin people calling out their garbage.

Doesn't look good for your erlay fuelled scam if the inventors of erlay step up and call it a scam, much safer to promote rolling-hypercube-slasher-coordinator-masternode-unls or whatever where you can dismiss any criticism as pure ignorance and "toxic maximalism".

Agreement... more like a clusterfuck. Segwit got in via miracle. I don't see that ever happening again, ever.




My point is that someone would hardfork Bitcoin after Erlay and also include a 16MB blocksize or something and market it as the next big pump. The shitcoin market is all about marketing and taking advantage of events that raise attention. So pushing for the "blocksize increase because now we have Erlay" narrative, not getting the blocksize increase then going their way to market this fork of Bitcoin is something I see happening. However the hardfork is definitely pretty much dead but I predict in special situations someone will keep milking this cow, it's all about timing. And I will be there to dump for more actual BTC.

Erlay increases transaction latency some, but not to the extent that a 100% set-reconciliation based relay protocol would. But it's more latent than flood relay, which has optimal latency performance according to @naumenkogs' presentation.

It doens't affect block announcement latency, but could increase block orphaning rates at the margins.

the elephant in the room is whether a hard fork is politically tenable at all. tbh it's hard to imagine the network not splitting in that case.

we could expand space for witness data with a soft fork, right? that might work well in a post-schnorr world since sig aggregation can drastically reduce the number of sigops in any given tx.

can anyone speak to the transaction/block latency aspect?

sure, but people (myself, for instance) also said increasing the blocksize should be offset by mitigations that reduce it's impact. Erlay is one such mitigation, but there are also several more possible ways to do so.
Erlay gets us closer to making a future agreement on another blocksize increase a no-brainer, but I don't expect Erlay to break down all the resistance in the die-hard small block contingent, it's not the most significant scaling improvement on the table (and any improvement in scaling the Bitcoin network is a by-product of it's real objective)



You seem to be living in an alternate universe; agreement was reached last time, and the blocksize was quadrupled.



I repeat: Erlay is not a consensus change, so there is no plausible fork.

any fork-coin to avoid Erlay couldn't possibly work, people could make an Erlay implementation for the fork, and it would interoperate with the flood relay on that coin no problem. It would be a completely pointless exercise.

As far as I can tell, this could create another wave of people demanding a block size increase due the reduced costs in maintaining a node, so I can see pressure on raising the block size again making a case out of this update. The question is, will there be an agreement on increasing the block size this time? I bet that the outcome is a no. Looking forward to dumping "Bitcoin Erlay" for more Bitcoin

What is the motivation to switch to wtx_id?

corrected my link, thanks for pointing that out



no consensus changes are needed (erlay is a p2p layer change), so there's no scope for delaying or blocking this change. flood relaying will continue to be supported, and I think it's probably needed as a fallback mode in cases where set reconciliation doesn't work anyway (successful reconciliation is probabilistic)

it's also difficult to see what the objections could be. Maybe one could argue that erlay pushes transaction latency up high enough to erase gains in reduced block orphaning? if it came from the "small blocks bad" people, it would be hilarious hypocrisy, as their position was always that higher block orphaning rates was an acceptable trade-off for "big" blocks (i.e. >8MB). but I guess we can expect them to make a bunch of contradictory and self-refuting claims anyway, it's never stopped anybody before

https://arxiv.org/abs/1905.10518
You can link directly link in youtube now  

https://youtube.com/watch?v=YxsjdIl0034&t=13m00s

video on Erlay, presented by @naumenkogs:

https://youtube.com/watch?v=YxsjdIl0034&t=13m00s


(jump to minute 0:13:00 to get to the start)

https://github.com/naumenkogs/bips/blob/bip-reconcil/bip-reconcil.mediawiki


exciting, I didn't expect progress so quickly since the announcement of the Minisketch library this Spring.

This implementation does something really smart; @naumenkogs has opted to snip the txids to a fraction of their full length, then adds a salt to guard against hash collisions. This saves more bandwidth than set reconciliation alone. The total bandwidth savings are apparently ~40% over the flood based transaction relaying that Bitcoin uses now (and that's the figure for a "private" node with 8 outgoing connections, public nodes with hundreds of connections will save far more bandwidth).

I think daily tx relay on average uses something like 300MB? Not sure. If so, that would mean cutting that to 180MB


If this is an easy BIP to review, it could make it into Bitcoin next year