5 ms·

Because transaction-bandwidth is Bitcoin's dominant inefficiency?

by SilasX 7y ago

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.

Because transaction-bandwidth is Bitcoin's dominant inefficiency?

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