Erlay: Bandwidth-efficient Bitcoin transaction relay protocol
github.com
github.com
Erlay itself is not terribly interesting except in the context of the specific robusness requirements such as exist in Bitcoin.
When robustness against malicious parties isn't a major concern O(N) gossip can also be achieved by more obvious protocols such as computing a spanning tree between nodes and forwarding along it. Erlay is interesting because it achieves the low bandwidth usage while preserving the robustness of "send everything to everyone you're connected to".
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2...
https://diyhpl.us/wiki/transcripts/london-bitcoin-devs/2019-...
It would be a huge privacy benefit, both for those running a p2p node, as well as to those broadcasting transactions (the government snoops passively monitoring would not know the location/ip from which a given new transaction originated).
Raising the stakes from a passive splitter to active MITM has value.
In particular, due to material published by Edward Snowden we know for a fact that nation state attackers have exploited this weakness to compromise the privacy of Bitcoin users, but even if before we knew that-- it's a reasonable assumption for any protocol which handles private information.
Unfortunately, Erik Voskuil (maintainer of "libbitcoin", a bitcoin node implementation used by virtually no one) has aggressively argued against any implementation of encryption with arguments that it would create a false sense of security and ultimately convert Bitcoin to a permissioned network. (e.g. https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016... and the surrounding thread; note that this was in _2016_. The same fruitless discussion repeated in subsequent years.)
I don't think any of Bitcoin's regular contributors have found his arguments persuasive in the slightest. Personally, I believe the arguments are outright incoherent. Never the less, these arguments are repeated every time its discussed.
After years of vicious abuse many Bitcoin contributors simply no longer have sufficient will remaining to proceed in the face of even more drama. It would be perfectly possible for Bitcoin Core to deploy encryption and for software like libbitcoin to not do so-- it doesn't have to be universally supported... but even so, the drama remains and no one wants to deal with it.
As a result little progress has been made in bringing the encryption functionality to completion and users are left needlessly exposed as a result.
I disagreed then and I disagree now, but my C isn’t up to the task (I can read it well enough, but I doubt I could securely implement a network crypto server the first try). Perhaps I will look into adding this to the golang bitcoin implementation, although I doubt it will go much of anywhere without bitcoind/bitcoin-core (the main canonical implementation) supporting it.
I didn't become aware of those snowden docs until a year and a half after the article about them... :( but the need was obvious enough before they came out (as you can see from the 2016 discussion on the subject).
Sitting down and coding is probably not the limiting reagent in getting the work completed. Review, herding cats, building positive momentum, etc. would all add a lot if you're willing and able to provide it. Collaborating on a second implementation would probably also be useful (though not so much in isolation, but it would be useful for testing and validation). (Heck, even just cheering work along to distract from drama and haters would probably accomplish a lot).
A functioning implementation goes a long way toward herding cats and building positive momentum. Amongst hackers, working code trumps a lot of objections; moreso if it is simply opportunistic and doesn't break anything for old clients, and can be disabled by the fearful pedants.
It's also a great starting point for other practical objections: with a working prototype, you can always counter "but what about edge case $x, huh smart guy?!" with a "well, here's a small patch to address $x, it's in the PR now", which is a great way to achieve forward progress.
I don't recall any objections raised that would be addressed by code. (though also, there have been at various points in time implementations, just not merge ready ones...)
In 2013 there were more serious privacy problems in the bitcoin software which probably would have made the encryption less relevant. Most of the known ones were addressed by 2016. I still didn't hear about the bitcoin tie in until Oct 2019, though, sadly.
Those people deserve privacy too.
Then, it would be possible after the fact to identify a MITM by checking those logs on both ends of the connection. Services could even exist to do this automatically.
The risk of being caught, even if small, would put most three letter agencies off sniffing this kind of thing.
We also came up with a strongly zero-knowledge authentication system where the connection receiver learns absolutely nothing about if authentication is being used by the connection initator. This prevents a MITM from adaptively "Opps, looks like that TCP connection failed" when they notice authentication being attempted in order to avoid detection.
This idea fits pretty nicely with how we manual connections work in Bitcoin... A normal node will make 8 automatic (random) outgoing connections plus up to another 8 connections to manually specified connections. Our thought was that if a manually specified connection was authenticated for partitioning resistance, and the auth failed it could just get treated as a random connection (and, of course, sound klaxons). The end result should be a phenomenal amount of herd immunity where even a small percentage using authentication should totally stop MITM attacks by attackers who really don't want to get detected.
If you're up for it-- jump on in! Other people, ... apparently aren't.
https://github.com/bitcoin/bips/blob/master/bip-0151.mediawi...
Shouldn't be difficult for even fairly ancient hardware.
The storage requirements for all live transaction outputs is possibly a limiting factor.
Am I missing something? Is the issue not the theoretical amount of computation required, but the fact implementations have significant overhead?
Edit: Don't just downvote, tell me where I'm wrong. This same weird propaganda that running a node of 100KB/s worth of transactions is actually a problem has been going on for years.
The number of transactions you can fit in 1MB (or whatever the current limit is) is very limited. Right now the biggest challenge with cryptocurrencies is that they do not scale to large numbers of transactions per second. This had resulted in $10 transaction fees and long delays in the past. Companies like bitpay refused to process your transaction on Steam because the exchange rate has changed significantly by the time your transaction has been confirmed on the blockchain. So you ended up missing $0.5 on a $39 transaction. You can decide to transfer the missing amount and pay the $10 transaction fee again or you can get a refund and bitcoin deducts the $10 transaction fee from your refund while bitpay is sending it back. The end result? Steam stopped accepting Bitcoins and so did other companies that year. I'm sure the fees are low again because all the people who wanted to use Bitcoin for day to day transactions have left because no platform accepts bitcoin payments anymore and therefore only the speculators are left who rarely initiate transactions.
The block size for Bitcoin is 4MB, not 1MB, too.
No it's not. Segwit introduced a new concept called block weight that's larger than 1MB, and in practice with normal transactions it gives around 1.4MB.