6 ms·

I think this essay is top heavy: the conclusions can't hold given the assumptions. Take the first argument: for transactions to remain cheap one of three thi

I think this essay is top heavy: the conclusions can't hold given the assumptions. Take the first argument: for transactions to remain cheap one of three things has to happen, then those three things are painted as almost impossible. But the second one; "At the same fee level, transaction count must increase 250 folds." Seems completely possible. If transactions remain relatively cheap then bitcoin can be very useful for microtransactions. And if they are useful for microtransactions then, by there nature, there will be many more transactions. Then the author is all over the map in the second section. At one point saying decentralized entities are useless, then that they don't provide value compared to traditional centralized entities, then than they /are/ real competition for those traditional services but the only real beneficiaries of trustless decentralized transactions are people engaged in illegal activity. They close out by saying since cyberpunks, drug dealers, and gamblers use bitcoin now, it will never find a place in the public sphere. But the blockchain idea is a good one and will find some sort of use. TL:DR The first point was interesting but flawed. The rest was garbage.

StavrosK 12y ago
I think he means transactions per block, which is hard to increase 250x.
- DennisP 12y ago
  The Bitcoin devs are working right now on something that could increase the block size more than that. The main thing that limits the size is latency in propagating large blocks. But most miners already have most of the transactions in each block. All you really need to send is a small data structure that lets the miner reconstruct the full block, from the transactions he already has. An invertible bloom lookup table makes that pretty easy: http://www.i-programmer.info/programming/theory/4641-the-invertible-bloom-filter.html?start http://www.i-programmer.info/programming/theory/4641-the-inv... Using this, a home bandwidth connection could handle about 45,000 tx/sec, which is more than Visa at peak: https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2 https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2 The other problem is blockchain storage. They're planning to prune old empty addresses, which should help a lot. A more radical solution is to store the full blocks only for the last couple months, and only a linked set of hashes back to the beginning. That might be a bigger change than Bitcoin can handle, but another currency could do it.
  - StavrosK 12y ago
    Huh, interesting. I'm not familiar with the problem with large blocks, so I don't know why this proposed solution is good, but I'm glad it exists. If anyone wants to explain the problem, I would be indebted.
    - DennisP 12y ago
      The time to propagate blocks is proportional to the block size, and if it takes too long compared to the block frequency, you end up with forks. That's the main reason we only have a block every 10 minutes, and limit to 7 tx/sec. But the transactions are sent separately, so the miners can make blocks out of them. There's no need to duplicate them all in the blocks themselves.
      - StavrosK 12y ago
        I see, thank you. Pretty clear.
  - jedunnigan 12y ago
    Transactions not having to propagate across the network a second time in blocks is certainly nice, but that doesn't solve all the problems of large blocks. As you said, that proposal is focused on maintaining an incentive for miners to create large blocks without having to worry about orphan races. All full nodes still need to process everyone else's transactions, so bandwidth requirements are still hefty, just not squared. Even if someone's home connection can theoretically maintain 45k tx/s, how many of those generous full node maintainers out there will be excited about the prospect of their Bitcoin node using their entire internet connection? Storage requirements will also still be fairly intensive, even if nodes prune everything but the UTXO set (that needs to be stored in RAM--although that can change--it's a half gig). Not to mention that proposal can create problems where miners withhold transactions from other miners so they can build secret chains that other miners can't build on until they have see the withheld transactions. All that aside, your comment still ignores the reality of the situation. The Bitcoin network has been bleeding nodes for ages, and has settled around 6500-7000, probably a little more[1]. What that says to me is that even if Gavin's 20MB block proposal works for him on paper and on his VPS, the reality is that we can barely maintain a healthy node landscape with the current stresses of the network. Upping it to 20MB will likely cause a "shedding" and we will come to the new normal, so on and so forth, until we increase the block size so much that we end up with only a handful of nodes. This is all assuming the network continues grows to those needs, which I found doubtful. [1]http://getaddr.bitnodes.io/ http://getaddr.bitnodes.io/
- nutschig 12y ago
  Gavin argues that 1000x is possible. With the latest features of header-first syncing, and simultaneous multiple downloads of blocks, we're doing pretty well. https://blog.bitcoinfoundation.org/blocksize-economics/ https://blog.bitcoinfoundation.org/blocksize-economics/ In the future, the blockchain inital sync should be torrented by default.
- mrb 12y ago
  No, he means the combined (fee/tx * price * tx/block) metric must increase by 250x. So if, for example, average fees increase by 2.5x and price increased by 10x, then transaction/block only needs to increase by 10x in order to raise this metric by 250x. Not only this is possible, but this is likely. This metric has increased by 1,000,000x in the last few years, why would it suddenly plateau right now?
inoop 12y ago
> But the second one; "At the same fee level, transaction count must increase 250 folds." Seems completely possible. Possible, sure, but likely? Bitcoin has been around since 2009 and has so far failed to gain any real amount of mainstream adoption. I don't see any compelling reasons why this should change any time soon. To me, Bitcoin is not the internet of money, it's more like the Linux desktop of money. Sure you can argue it has certain benefits over the status quo, such as lower cost and freedom from certain 'evil' corporations, but the general public arguably doesn't care enough about these things to be bothered to make the switch, especially given the relatively high barrier of entry and low amount of third-party support. edit: anyone care to explain why I am being downvoted?

StavrosK 12y ago

I think he means transactions per block, which is hard to increase 250x.

DennisP 12y ago
The Bitcoin devs are working right now on something that could increase the block size more than that. The main thing that limits the size is latency in propagating large blocks. But most miners already have most of the transactions in each block. All you really need to send is a small data structure that lets the miner reconstruct the full block, from the transactions he already has. An invertible bloom lookup table makes that pretty easy: http://www.i-programmer.info/programming/theory/4641-the-invertible-bloom-filter.html?start http://www.i-programmer.info/programming/theory/4641-the-inv... Using this, a home bandwidth connection could handle about 45,000 tx/sec, which is more than Visa at peak: https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2 https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2 The other problem is blockchain storage. They're planning to prune old empty addresses, which should help a lot. A more radical solution is to store the full blocks only for the last couple months, and only a linked set of hashes back to the beginning. That might be a bigger change than Bitcoin can handle, but another currency could do it.
- StavrosK 12y ago
  Huh, interesting. I'm not familiar with the problem with large blocks, so I don't know why this proposed solution is good, but I'm glad it exists. If anyone wants to explain the problem, I would be indebted.
  - DennisP 12y ago
    The time to propagate blocks is proportional to the block size, and if it takes too long compared to the block frequency, you end up with forks. That's the main reason we only have a block every 10 minutes, and limit to 7 tx/sec. But the transactions are sent separately, so the miners can make blocks out of them. There's no need to duplicate them all in the blocks themselves.
    - StavrosK 12y ago
      I see, thank you. Pretty clear.
- jedunnigan 12y ago
  Transactions not having to propagate across the network a second time in blocks is certainly nice, but that doesn't solve all the problems of large blocks. As you said, that proposal is focused on maintaining an incentive for miners to create large blocks without having to worry about orphan races. All full nodes still need to process everyone else's transactions, so bandwidth requirements are still hefty, just not squared. Even if someone's home connection can theoretically maintain 45k tx/s, how many of those generous full node maintainers out there will be excited about the prospect of their Bitcoin node using their entire internet connection? Storage requirements will also still be fairly intensive, even if nodes prune everything but the UTXO set (that needs to be stored in RAM--although that can change--it's a half gig). Not to mention that proposal can create problems where miners withhold transactions from other miners so they can build secret chains that other miners can't build on until they have see the withheld transactions. All that aside, your comment still ignores the reality of the situation. The Bitcoin network has been bleeding nodes for ages, and has settled around 6500-7000, probably a little more[1]. What that says to me is that even if Gavin's 20MB block proposal works for him on paper and on his VPS, the reality is that we can barely maintain a healthy node landscape with the current stresses of the network. Upping it to 20MB will likely cause a "shedding" and we will come to the new normal, so on and so forth, until we increase the block size so much that we end up with only a handful of nodes. This is all assuming the network continues grows to those needs, which I found doubtful. [1]http://getaddr.bitnodes.io/ http://getaddr.bitnodes.io/
nutschig 12y ago
Gavin argues that 1000x is possible. With the latest features of header-first syncing, and simultaneous multiple downloads of blocks, we're doing pretty well. https://blog.bitcoinfoundation.org/blocksize-economics/ https://blog.bitcoinfoundation.org/blocksize-economics/ In the future, the blockchain inital sync should be torrented by default.
mrb 12y ago
No, he means the combined (fee/tx * price * tx/block) metric must increase by 250x. So if, for example, average fees increase by 2.5x and price increased by 10x, then transaction/block only needs to increase by 10x in order to raise this metric by 250x. Not only this is possible, but this is likely. This metric has increased by 1,000,000x in the last few years, why would it suddenly plateau right now?

inoop 12y ago

> But the second one; "At the same fee level, transaction count must increase 250 folds." Seems completely possible. Possible, sure, but likely? Bitcoin has been around since 2009 and has so far failed to gain any real amount of mainstream adoption. I don't see any compelling reasons why this should change any time soon. To me, Bitcoin is not the internet of money, it's more like the Linux desktop of money. Sure you can argue it has certain benefits over the status quo, such as lower cost and freedom from certain 'evil' corporations, but the general public arguably doesn't care enough about these things to be bothered to make the switch, especially given the relatively high barrier of entry and low amount of third-party support. edit: anyone care to explain why I am being downvoted?