6 ms·

> 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

> 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.
  - deleted 9y ago
    [deleted]
- shp0ngle 9y ago
  No. Except for Lightning Network, which is this software that somehow routes transactions on a separate network, and it's not bitcoin; it doesn't have the same assurances, there are some third-party channels that route the transactions. (I admit, I haven't studied LN in detail.) It uses bitcoin as a "backbone", sort of like you have SWIFT which is slow and expensive, and then you have credit card payments/paypal/whatnot that is built on top of it. LN specifically requires segwit (the main issue of this "civil war").
  - kanzure 9y ago
    > and it's not bitcoin; it doesn't have the same assurances, there are some third-party channels that route the transactions. (I admit, I haven't studied LN in detail.) lightning clients pass around bitcoin transactions to each other, check the protobufs: https://github.com/ElementsProject/lightning/blob/2bf92c906326d299e42317cc15727edf845b16ca/lightning.proto https://github.com/ElementsProject/lightning/blob/2bf92c9063... admittedly the protobufs have changed since i last looked, here's the canonical diagram describing the hashed timelock bitcoin transaction concept: https://github.com/ElementsProject/lightning/blob/2bf92c906326d299e42317cc15727edf845b16ca/doc/htlc.svg https://github.com/ElementsProject/lightning/blob/2bf92c9063... or read the paper https://lightning.network/lightning-network-paper.pdf https://lightning.network/lightning-network-paper.pdf > LN specifically requires segwit false, see http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/overview-of-bips-necessary-for-lightning/ http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/o...
    - shp0ngle 9y ago
      Thanks for the links. I was under the impression that LN needs maleability fix. (And I am not the only one who thinks that - see https://www.cryptocoinsnews.com/segwit-lightning/ https://www.cryptocoinsnews.com/segwit-lightning/ ) I don't take FlexTrans as serious attempt at malleability fixing
shp0ngle 9y ago
> Core != Blockstream The overlap is very large. In the same way, segwit2x != Chinere miners, but come on, there is an clear overlap. > It's an effective blocksize increase to 2MB If all users start using segwit addresses and segwit transactions, and if all wallets software will know how to send and receive it. And that will mean users will need to send their money to their segwit-enabled addresses first, which might, you know, clog the network. (In reality, nobody knows what will happen. Almost nobody uses segwit on litecoin right now, but litecoin is a toy currency...) hardfork would solve that issue immediately - no need to upgrade wallets, no need to figure out how do segwit-inside-P2SH addresses work (they are different from normal addresses!). > enables lightning network which should hopefully reduce congestion on the Bitcoin network Again nobody knows. Lightning network might be a vaporware. Literally nobody is using it, since it does not exist. > SegWit transactions are cheaper than traditional transactions Well, that's a matter of "policy", and I am not sure if segwit2x nodes will implement the segwit discount or not. There were some issues about that, but I think they didn't have time to remove the segwit discount yet. But they plan to. (Again I am not advocating big blocks, increasing blocks that way is not something that can be done forever. Segwit is fine, it solves some issues like maleability, but it's overhyped IMO. There is no scaling solution for bitcoin yet. And maybe there will not be?)
- kanzure 9y ago
  > In the same way, segwit2x != Chinere miners, but come on, there is an clear overlap there's more overlap with core developers and chaincode labs. > Lightning network might be a vaporware. Literally nobody is using it, since it does not exist. it does exist, https://github.com/lightningnetwork/lnd https://github.com/lightningnetwork/lnd and http://lightning.community/release/software/lnd/lightning/2017/05/03/litening/ http://lightning.community/release/software/lnd/lightning/20... and other implementations of lightning also exist.
  - shp0ngle 9y ago
    Interesting. I will try the docker example later BUT you have to admit it is still in research and not widely used/accepted/tested by users
andrewla 9y ago
> 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 I'm curious if you have some sources on this -- most of the anti-big-block claims that I have seen tend to settle on the hard fork being problematic, which is a very legitimate criticism (thought I need to dig up citations to play by my own rules here). There's also a significant group (I think unaffiliated with Core) that worries about the increase in orphanage that big blocks can lead to.
- fpgaminer 9y ago
  Sources would be nice, but I don't have the time to dig through the mailing lists for quotes from developers. To be fair, those claiming that Core is conspiring to move transactions off-chain would also need to cite sources. But quotes from developers are not particularly interesting anyway. What's far more interesting is what the Core developers have actually accomplished. Actions speak louder than words. They released SegWit which _is_ a 2MB upgrade to blocksize, as a softfork. It's exactly what the community wanted at the time (2MB), without any of the downsides (hardforking). In addition to that, it increased transaction efficiency, fixed bugs, and enhanced the protocol. SegWit is a thoughtfully designed protocol upgrade that accomplishes an order of magnitude more than any "upgrade" proposed by any of the alternative clients (Bitcoin-XT, Bitcoin Unlimited, and now SegWit2X). Post-SegWit the developers are already looking at Schnorr signatures to further increase throughput. They've worked tirelessly to optimize signature verification times and improve the efficiency of the P2P protocol. Why would they make all those efficiency improvements if their "evil plan" was to move everyone over to a lighting network? EDIT: To be clear, yes I realize not providing sources is a total cop out :P But not everyone has limitless time to peruse the mailing lists for quotes. I just try to provide my best understanding of things, given my experience working with Bitcoin and keeping eyes on the community and ecosystem.

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.
- deleted 9y ago
  [deleted]
shp0ngle 9y ago
No. Except for Lightning Network, which is this software that somehow routes transactions on a separate network, and it's not bitcoin; it doesn't have the same assurances, there are some third-party channels that route the transactions. (I admit, I haven't studied LN in detail.) It uses bitcoin as a "backbone", sort of like you have SWIFT which is slow and expensive, and then you have credit card payments/paypal/whatnot that is built on top of it. LN specifically requires segwit (the main issue of this "civil war").
- kanzure 9y ago
  > and it's not bitcoin; it doesn't have the same assurances, there are some third-party channels that route the transactions. (I admit, I haven't studied LN in detail.) lightning clients pass around bitcoin transactions to each other, check the protobufs: https://github.com/ElementsProject/lightning/blob/2bf92c906326d299e42317cc15727edf845b16ca/lightning.proto https://github.com/ElementsProject/lightning/blob/2bf92c9063... admittedly the protobufs have changed since i last looked, here's the canonical diagram describing the hashed timelock bitcoin transaction concept: https://github.com/ElementsProject/lightning/blob/2bf92c906326d299e42317cc15727edf845b16ca/doc/htlc.svg https://github.com/ElementsProject/lightning/blob/2bf92c9063... or read the paper https://lightning.network/lightning-network-paper.pdf https://lightning.network/lightning-network-paper.pdf > LN specifically requires segwit false, see http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/overview-of-bips-necessary-for-lightning/ http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/o...
  - shp0ngle 9y ago
    Thanks for the links. I was under the impression that LN needs maleability fix. (And I am not the only one who thinks that - see https://www.cryptocoinsnews.com/segwit-lightning/ https://www.cryptocoinsnews.com/segwit-lightning/ ) I don't take FlexTrans as serious attempt at malleability fixing

shp0ngle 9y ago

> Core != Blockstream The overlap is very large. In the same way, segwit2x != Chinere miners, but come on, there is an clear overlap. > It's an effective blocksize increase to 2MB If all users start using segwit addresses and segwit transactions, and if all wallets software will know how to send and receive it. And that will mean users will need to send their money to their segwit-enabled addresses first, which might, you know, clog the network. (In reality, nobody knows what will happen. Almost nobody uses segwit on litecoin right now, but litecoin is a toy currency...) hardfork would solve that issue immediately - no need to upgrade wallets, no need to figure out how do segwit-inside-P2SH addresses work (they are different from normal addresses!). > enables lightning network which should hopefully reduce congestion on the Bitcoin network Again nobody knows. Lightning network might be a vaporware. Literally nobody is using it, since it does not exist. > SegWit transactions are cheaper than traditional transactions Well, that's a matter of "policy", and I am not sure if segwit2x nodes will implement the segwit discount or not. There were some issues about that, but I think they didn't have time to remove the segwit discount yet. But they plan to. (Again I am not advocating big blocks, increasing blocks that way is not something that can be done forever. Segwit is fine, it solves some issues like maleability, but it's overhyped IMO. There is no scaling solution for bitcoin yet. And maybe there will not be?)

kanzure 9y ago
> In the same way, segwit2x != Chinere miners, but come on, there is an clear overlap there's more overlap with core developers and chaincode labs. > Lightning network might be a vaporware. Literally nobody is using it, since it does not exist. it does exist, https://github.com/lightningnetwork/lnd https://github.com/lightningnetwork/lnd and http://lightning.community/release/software/lnd/lightning/2017/05/03/litening/ http://lightning.community/release/software/lnd/lightning/20... and other implementations of lightning also exist.
- shp0ngle 9y ago
  Interesting. I will try the docker example later BUT you have to admit it is still in research and not widely used/accepted/tested by users

andrewla 9y ago

> 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 I'm curious if you have some sources on this -- most of the anti-big-block claims that I have seen tend to settle on the hard fork being problematic, which is a very legitimate criticism (thought I need to dig up citations to play by my own rules here). There's also a significant group (I think unaffiliated with Core) that worries about the increase in orphanage that big blocks can lead to.

fpgaminer 9y ago
Sources would be nice, but I don't have the time to dig through the mailing lists for quotes from developers. To be fair, those claiming that Core is conspiring to move transactions off-chain would also need to cite sources. But quotes from developers are not particularly interesting anyway. What's far more interesting is what the Core developers have actually accomplished. Actions speak louder than words. They released SegWit which _is_ a 2MB upgrade to blocksize, as a softfork. It's exactly what the community wanted at the time (2MB), without any of the downsides (hardforking). In addition to that, it increased transaction efficiency, fixed bugs, and enhanced the protocol. SegWit is a thoughtfully designed protocol upgrade that accomplishes an order of magnitude more than any "upgrade" proposed by any of the alternative clients (Bitcoin-XT, Bitcoin Unlimited, and now SegWit2X). Post-SegWit the developers are already looking at Schnorr signatures to further increase throughput. They've worked tirelessly to optimize signature verification times and improve the efficiency of the P2P protocol. Why would they make all those efficiency improvements if their "evil plan" was to move everyone over to a lighting network? EDIT: To be clear, yes I realize not providing sources is a total cop out :P But not everyone has limitless time to peruse the mailing lists for quotes. I just try to provide my best understanding of things, given my experience working with Bitcoin and keeping eyes on the community and ecosystem.