5 ms·

The basic question is how to scale; off-chain or on-chain. The rest is just theatrics and typical nerdy hyperbole. One side of the fight (Core / blockstream) w

The basic question is how to scale; off-chain or on-chain. The rest is just theatrics and typical nerdy hyperbole. One side of the fight (Core / blockstream) wants to scale off-chain, pushing transactions to side-chains and/or lighting networks, and want to profit from off-chain solutions. The other side of the fight (segwit2x / miners) wants to scale on-chain, making the blocks bigger, and profit from block fees. Both sides have pros and cons. Pros of off-chain solutions - more scalable, don't need expensive confirmations for each transaction, more long-term. Cons: the solutions don't exist yet and might be vaporware; segwit etc are just stepping stones. Pros of on-chain solutions - making the blocks larger can be done now, no need to wait for new software and new networks. Cons - makes the blocks larger, which makes running bitcoin nodes harder. Also cannot scale this way infinitely (you need to keep all the transactions on a disk forever). The discussion about segwit is in reality just discussion about how to scale, and who profits. As for me, I don't really care, Bitcoin is inefficient either way

kinghajj 9y ago
> Also cannot scale this way infinitely (you need to keep all the transactions on a disk forever). The whitepaper itself mentions that the Merkle tree can be pruned so that doesn't need to be the case. Do you know why there hasn't been more effort towards implementing that yet?
- erikpukinskis 9y ago
  The leaves still grow with the square root of the tree size, which is certainly better than linear, but doesn't really solve the problem. It buys you one less order of magnitude you have to scale to, but only one. If you're growing by an order of magnitude every few years, it's just buying you an extra few years lead time.
  - placeybordeaux 9y ago
    If we only wanted to track the current unspent outputs we're sitting at 54M which interestingly has been holding relatively constant since June. Where as the total number of transactions (size of blockchain in general) is at 240M and is strictly monotonically increasing. See UTXO here: https://blockchain.info/charts/utxo-count https://blockchain.info/charts/utxo-count See total TX here: https://blockchain.info/charts/n-transactions-total https://blockchain.info/charts/n-transactions-total Every block for the near future will include one new UTXO, but it can increase, decrease or keep the total number of UTXO the same.
- runeks 9y ago
  It would appear the Bitcoin network has a hard time agreeing on breaking changes :)
- fpgaminer 9y ago
  AFAIK the paper is referring to thin clients, right? You can already run those with the stock Bitcoin Core client. There's a command line argument that tells it to prune any blocks older than X. The disk space required by such clients is X times the maximum size of blocks + the size of the UTXO. But you still need full nodes who maintain all historical data. Because, AFAIK, there's no way other way to trustlessly establish a UTXO without rescanning the whole blockchain. Maybe there are ways; I'm not that deep into Bitcoin's internal at the moment.
  - rocqua 9y ago
    I think perhaps a soft-fork is possible where you store a hash of the UTXO pool in e.g. the coinbase transaction. This way you can verify a given UTXO pool by just checking the hash.
- monort 9y ago
  It is implemented, the command line option is a -prune=<n>
fpgaminer 9y ago
> One side of the fight (Core / blockstream) wants to scale off-chain, pushing transactions to side-chains and/or lighting networks, and want to profit from off-chain solutions. I think that gives the wrong impression. First off, Core != Blockstream. Secondly, the consensus amongst Core developers, as I read it, is they want as much on-chain as possible. Their definition of possible is what can a Bitcoin client handle on the average user's PC. The problem is that, today, the answer is not much. Increasing the blocksize to allow more transactions requires an exponential increase in the computational requirements of the Bitcoin client. So it's not really feasible to just "scale on-chain", as of today. SegWit accomplishes two things. 1) It's a stopgap. It's an effective blocksize increase to 2MB, and it enables lightning network which should hopefully reduce congestion on the Bitcoin network. 2) It's an optimization; SegWit transactions are cheaper than traditional transactions. SegWit is just a stopgap while developers implement a series of optimizations to the Bitcoin network that allow it to handle more capacity, without increasing the computational resources to the point where average users can't run the software. But those optimizations are going to take a long time.
- woah 9y ago
  Do any of these optimizations even get close to a 10x improvement? The network needs a 10000x improvement.
  - fpgaminer 9y ago
    > The network needs a 10000x improvement. Says who? Would I like Bitcoin to support 10,000x more transactions per second than it does now? Of course. But just because I _want_ it to, doesn't mean it's magically going to be able to. Bitcoin is what it is. I'd like ships that can go faster than the speed of light, but physics isn't going to bends its rules just because I want it to. We cannot, physically, increase Bitcoin's throughput 10,000x. We could change one constant, the max blocksize, make it 10GB and ... oops, now the network is broken. No one on Earth can actually validate 10GB blocks in the span of 10 minutes. And even if they could, who could handle 1.4 TB of increasing disk space per day? 10,000x is an extreme example of principals that apply to any blocksize increase. If we increase the blocksize, it means less and less PCs are capable of actually running the Bitcoin software. And it won't take much before the exponential complexity of validating blocks eats everything. Whether we like it or not, we are dependent on optimizing the Bitcoin network if we want any kind of scale. It will take time and it will take innovation. In the meantime, we have SegWit which enables lightning networks, which we can use for anything we don't need the full guarantees of a Bitcoin transaction for.
andrewla 9y ago
I think you understate the cons of the on-chain solutions. This said as a big-blocker myself. I think the size of the node is a consideration, but not a huge one -- before we started butting up against the limit, blocks were naturally much smaller than the 1MB limit -- the fear of spam and dust transactions never materialized, so there's no reason to expect that the economics are fundamentally different now. The biggest con by far is the hard-forking nature of the change. Changing the limit means that clients will have to accept blocks that they currently don't accept. This applies to core, of course, but also to the innumerable other implementations of the bitcoin protocol. Don't make the mistake of thinking that core is the only player here -- a hard fork is trouble for everyone, miners included, and has a substantial risk of causing two viable chains to appear, which is much more of a disaster for Bitcoin (because of how long it takes to adjust difficulty) than it was for Ethereum. With sufficient consensus, this becomes less of a problem for the same reason -- the defunct 5% chain (with 95% consensus) will take 280 days to converge on a new difficulty, during which time that network will be extremely congested. But if miners are misconfigured, etc., even if there is consensus there may be an unintentional hard fork. The second biggest problem is the rise in the risk of orphaned blocks. This, I think, is probably what holds most miners back -- the longer it takes to transmit and verify a block, the greater the chance of a block being orphaned is. Orphans hurt the security of the network by making it so that a smaller fraction of the net hashing power is actually being applied to the problem of securing the network. As much as people complain that the proof-of-work is "wasteful" in the ecological sense, wasting even that wasted work would make nobody happy. Segwit, on the other side of the debate, has the attachment to off-chain scaling, but also offers a solution to transaction malleability, which is a huge problem for bitcoin businesses as it can be difficult to tell whether a transaction ever made it to the network, much less rely on features like child-pays-for-parent. Since the current version of segwit is a soft fork, it should, in theory, work with existing non-core clients, and the Litecoin adoption should give us some information on how that works in practice, but Litecoin doesn't have nearly the adoption that Bitcoin does, so it's hard to generalize.

kinghajj 9y ago

> Also cannot scale this way infinitely (you need to keep all the transactions on a disk forever). The whitepaper itself mentions that the Merkle tree can be pruned so that doesn't need to be the case. Do you know why there hasn't been more effort towards implementing that yet?

erikpukinskis 9y ago
The leaves still grow with the square root of the tree size, which is certainly better than linear, but doesn't really solve the problem. It buys you one less order of magnitude you have to scale to, but only one. If you're growing by an order of magnitude every few years, it's just buying you an extra few years lead time.
- placeybordeaux 9y ago
  If we only wanted to track the current unspent outputs we're sitting at 54M which interestingly has been holding relatively constant since June. Where as the total number of transactions (size of blockchain in general) is at 240M and is strictly monotonically increasing. See UTXO here: https://blockchain.info/charts/utxo-count https://blockchain.info/charts/utxo-count See total TX here: https://blockchain.info/charts/n-transactions-total https://blockchain.info/charts/n-transactions-total Every block for the near future will include one new UTXO, but it can increase, decrease or keep the total number of UTXO the same.
runeks 9y ago
It would appear the Bitcoin network has a hard time agreeing on breaking changes :)
fpgaminer 9y ago
AFAIK the paper is referring to thin clients, right? You can already run those with the stock Bitcoin Core client. There's a command line argument that tells it to prune any blocks older than X. The disk space required by such clients is X times the maximum size of blocks + the size of the UTXO. But you still need full nodes who maintain all historical data. Because, AFAIK, there's no way other way to trustlessly establish a UTXO without rescanning the whole blockchain. Maybe there are ways; I'm not that deep into Bitcoin's internal at the moment.
- rocqua 9y ago
  I think perhaps a soft-fork is possible where you store a hash of the UTXO pool in e.g. the coinbase transaction. This way you can verify a given UTXO pool by just checking the hash.
monort 9y ago
It is implemented, the command line option is a -prune=<n>

fpgaminer 9y ago

> One side of the fight (Core / blockstream) wants to scale off-chain, pushing transactions to side-chains and/or lighting networks, and want to profit from off-chain solutions. I think that gives the wrong impression. First off, Core != Blockstream. Secondly, the consensus amongst Core developers, as I read it, is they want as much on-chain as possible. Their definition of possible is what can a Bitcoin client handle on the average user's PC. The problem is that, today, the answer is not much. Increasing the blocksize to allow more transactions requires an exponential increase in the computational requirements of the Bitcoin client. So it's not really feasible to just "scale on-chain", as of today. SegWit accomplishes two things. 1) It's a stopgap. It's an effective blocksize increase to 2MB, and it enables lightning network which should hopefully reduce congestion on the Bitcoin network. 2) It's an optimization; SegWit transactions are cheaper than traditional transactions. SegWit is just a stopgap while developers implement a series of optimizations to the Bitcoin network that allow it to handle more capacity, without increasing the computational resources to the point where average users can't run the software. But those optimizations are going to take a long time.

woah 9y ago
Do any of these optimizations even get close to a 10x improvement? The network needs a 10000x improvement.
- fpgaminer 9y ago
  > The network needs a 10000x improvement. Says who? Would I like Bitcoin to support 10,000x more transactions per second than it does now? Of course. But just because I _want_ it to, doesn't mean it's magically going to be able to. Bitcoin is what it is. I'd like ships that can go faster than the speed of light, but physics isn't going to bends its rules just because I want it to. We cannot, physically, increase Bitcoin's throughput 10,000x. We could change one constant, the max blocksize, make it 10GB and ... oops, now the network is broken. No one on Earth can actually validate 10GB blocks in the span of 10 minutes. And even if they could, who could handle 1.4 TB of increasing disk space per day? 10,000x is an extreme example of principals that apply to any blocksize increase. If we increase the blocksize, it means less and less PCs are capable of actually running the Bitcoin software. And it won't take much before the exponential complexity of validating blocks eats everything. Whether we like it or not, we are dependent on optimizing the Bitcoin network if we want any kind of scale. It will take time and it will take innovation. In the meantime, we have SegWit which enables lightning networks, which we can use for anything we don't need the full guarantees of a Bitcoin transaction for.

andrewla 9y ago

I think you understate the cons of the on-chain solutions. This said as a big-blocker myself. I think the size of the node is a consideration, but not a huge one -- before we started butting up against the limit, blocks were naturally much smaller than the 1MB limit -- the fear of spam and dust transactions never materialized, so there's no reason to expect that the economics are fundamentally different now. The biggest con by far is the hard-forking nature of the change. Changing the limit means that clients will have to accept blocks that they currently don't accept. This applies to core, of course, but also to the innumerable other implementations of the bitcoin protocol. Don't make the mistake of thinking that core is the only player here -- a hard fork is trouble for everyone, miners included, and has a substantial risk of causing two viable chains to appear, which is much more of a disaster for Bitcoin (because of how long it takes to adjust difficulty) than it was for Ethereum. With sufficient consensus, this becomes less of a problem for the same reason -- the defunct 5% chain (with 95% consensus) will take 280 days to converge on a new difficulty, during which time that network will be extremely congested. But if miners are misconfigured, etc., even if there is consensus there may be an unintentional hard fork. The second biggest problem is the rise in the risk of orphaned blocks. This, I think, is probably what holds most miners back -- the longer it takes to transmit and verify a block, the greater the chance of a block being orphaned is. Orphans hurt the security of the network by making it so that a smaller fraction of the net hashing power is actually being applied to the problem of securing the network. As much as people complain that the proof-of-work is "wasteful" in the ecological sense, wasting even that wasted work would make nobody happy. Segwit, on the other side of the debate, has the attachment to off-chain scaling, but also offers a solution to transaction malleability, which is a huge problem for bitcoin businesses as it can be difficult to tell whether a transaction ever made it to the network, much less rely on features like child-pays-for-parent. Since the current version of segwit is a soft fork, it should, in theory, work with existing non-core clients, and the Litecoin adoption should give us some information on how that works in practice, but Litecoin doesn't have nearly the adoption that Bitcoin does, so it's hard to generalize.