7 ms·

Erlay: Bandwidth-efficient Bitcoin transaction relay protocol

66 points by wyldfire 7y ago

kanzure 7y ago
Gleb has presented on this a few times, here are some transcripts: https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/erlay/ https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2... https://diyhpl.us/wiki/transcripts/london-bitcoin-devs/2019-11-13-gleb-naumenko-p2p-erlay/ https://diyhpl.us/wiki/transcripts/london-bitcoin-devs/2019-... paper: https://arxiv.org/abs/1905.10518 https://arxiv.org/abs/1905.10518
SilasX 7y ago
Because transaction-bandwidth is Bitcoin's dominant inefficiency?
- Taek 7y ago
  Transaction bandwidth is the primary inefficiency for continuously running nodes, yeah. Especially if you are using EC2 pricing.
  - BubRoss 7y ago
    $5 a month can buy a VPS that runs a node with 1% of all of its resources.
    - RL_Quine 7y ago
      Barely. The resource requirements for running a meaningfully performant node outstrip what you're getting on digitalocean. Most Bitcoin nodes as a result are horrendously slow compared with running on reasonable hardware.
      - BubRoss 7y ago
        Slow in what way? A computer from 15 years ago or old rasberry pi can run a node. What can't handle verifying one tiny block every 10 minutes while sending out data?
      - londons_explore 7y ago
        As far as I can see, running a bitcoin node requires looking up ~10 transaction inputs per second in a precomputed index, and running a handful of EC computations per second. 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?
  - deleted 7y ago
    [deleted]
- BubRoss 7y ago
  It isn't at all and it never was. The transactions being limited to 1MB every 10 minutes means that anyone that can watch a youtube video can run a node, or pay $5 per month. This is a solution in search of a problem. 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.
  - RL_Quine 7y ago
    Latency in the network is a big limitation. You can run a node at nearly dialup speed, but you'll be endlessly behind on the current state of the network and fairly useless at actually relaying that information to your peers. You really want to be able to process blocks in the order of a couple of hundred milliseconds, which is actually a hell of a lot of bandwidth at peak. In the worst case scenario (no pre-caching at all), 4MB of data in 100ms is 0.32Gbit, and that's not counting the TCP overhead and your actual processing of the data. The block size for Bitcoin is 4MB, not 1MB, too.
    - BubRoss 7y ago
      Where are you possibly getting that latency is a problem for 10 minutes in between blocks that miners are deciding? All a node needs to do is basic verification while sending out data. Anyone who has just synced with the chain can see that it takes less than a second per block. Where are your numbers coming from?
      - grapehut 7y ago
        He's conflating miner-concerns with general node ones. If you're running a miner, every millisecond is money. I operate nodes that takes up to like 20 seconds to get and validate a block (running no-mempool, and slow network/cpu) and it's absolutely no problem for my use case, which is pretty typical (accepting confirmed payments)
    - lawn 7y ago
      > 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.
- garmaine 7y ago
  It is on data-capped networks, like anyone behind an Xfinity home connection.
nullc 7y ago
Our implementation of the underlying set reconciliation primitive is probably of more general interest to HN. I submitted it previously ( https://news.ycombinator.com/item?id=18645790 https://news.ycombinator.com/item?id=18645790 ) but it got no love. 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".
sneak 7y ago
I still don’t know why the bitcoin p2p protocol doesn’t opportunistically encrypt, even unauthenticated. Bittorrent has been doing this for ages. 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.
- garmaine 7y ago
  It is being worked on: https://github.com/bitcoin/bips/blob/master/bip-0151.mediawiki https://github.com/bitcoin/bips/blob/master/bip-0151.mediawi...
  - nullc 7y ago
    BIP-151 has been withdrawn. There has recently been a little bit of activity, https://github.com/bitcoin/bitcoin/pull/18242 https://github.com/bitcoin/bitcoin/pull/18242 but without major cultural changes or several new and eager contributors I don't think this functionality is likely to be completed and deployed any time soon.
- nullc 7y ago
  I think it's an unambiguous ethical failure that Bitcoin's traffic isn't opportunistically encrypted. As protocol developers we have an obligation to provide for users at least a basic level of protection and because of known threats on the modern internet that protection almost always needs to include encryption. 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-June/012848.html 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.

66 points by wyldfire 7y ago

Gleb has presented on this a few times, here are some transcripts: https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/erlay/ https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2... https://diyhpl.us/wiki/transcripts/london-bitcoin-devs/2019-11-13-gleb-naumenko-p2p-erlay/ https://diyhpl.us/wiki/transcripts/london-bitcoin-devs/2019-... paper: https://arxiv.org/abs/1905.10518 https://arxiv.org/abs/1905.10518

SilasX 7y ago

Because transaction-bandwidth is Bitcoin's dominant inefficiency?

Taek 7y ago
Transaction bandwidth is the primary inefficiency for continuously running nodes, yeah. Especially if you are using EC2 pricing.
- BubRoss 7y ago
  $5 a month can buy a VPS that runs a node with 1% of all of its resources.
  - RL_Quine 7y ago
    Barely. The resource requirements for running a meaningfully performant node outstrip what you're getting on digitalocean. Most Bitcoin nodes as a result are horrendously slow compared with running on reasonable hardware.
    - BubRoss 7y ago
      Slow in what way? A computer from 15 years ago or old rasberry pi can run a node. What can't handle verifying one tiny block every 10 minutes while sending out data?
    - londons_explore 7y ago
      As far as I can see, running a bitcoin node requires looking up ~10 transaction inputs per second in a precomputed index, and running a handful of EC computations per second. 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?
- deleted 7y ago
  [deleted]
BubRoss 7y ago
It isn't at all and it never was. The transactions being limited to 1MB every 10 minutes means that anyone that can watch a youtube video can run a node, or pay $5 per month. This is a solution in search of a problem. 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.
- RL_Quine 7y ago
  Latency in the network is a big limitation. You can run a node at nearly dialup speed, but you'll be endlessly behind on the current state of the network and fairly useless at actually relaying that information to your peers. You really want to be able to process blocks in the order of a couple of hundred milliseconds, which is actually a hell of a lot of bandwidth at peak. In the worst case scenario (no pre-caching at all), 4MB of data in 100ms is 0.32Gbit, and that's not counting the TCP overhead and your actual processing of the data. The block size for Bitcoin is 4MB, not 1MB, too.
  - BubRoss 7y ago
    Where are you possibly getting that latency is a problem for 10 minutes in between blocks that miners are deciding? All a node needs to do is basic verification while sending out data. Anyone who has just synced with the chain can see that it takes less than a second per block. Where are your numbers coming from?
    - grapehut 7y ago
      He's conflating miner-concerns with general node ones. If you're running a miner, every millisecond is money. I operate nodes that takes up to like 20 seconds to get and validate a block (running no-mempool, and slow network/cpu) and it's absolutely no problem for my use case, which is pretty typical (accepting confirmed payments)
  - lawn 7y ago
    > 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.
garmaine 7y ago
It is on data-capped networks, like anyone behind an Xfinity home connection.

nullc 7y ago

Our implementation of the underlying set reconciliation primitive is probably of more general interest to HN. I submitted it previously ( https://news.ycombinator.com/item?id=18645790 https://news.ycombinator.com/item?id=18645790 ) but it got no love. 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".

sneak 7y ago

I still don’t know why the bitcoin p2p protocol doesn’t opportunistically encrypt, even unauthenticated. Bittorrent has been doing this for ages. 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.

garmaine 7y ago
It is being worked on: https://github.com/bitcoin/bips/blob/master/bip-0151.mediawiki https://github.com/bitcoin/bips/blob/master/bip-0151.mediawi...
- nullc 7y ago
  BIP-151 has been withdrawn. There has recently been a little bit of activity, https://github.com/bitcoin/bitcoin/pull/18242 https://github.com/bitcoin/bitcoin/pull/18242 but without major cultural changes or several new and eager contributors I don't think this functionality is likely to be completed and deployed any time soon.
nullc 7y ago
I think it's an unambiguous ethical failure that Bitcoin's traffic isn't opportunistically encrypted. As protocol developers we have an obligation to provide for users at least a basic level of protection and because of known threats on the modern internet that protection almost always needs to include encryption. 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-June/012848.html 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.