5 ms·

Where did you find it stated that it's 2x. Isn't it much more, like million to billions times more, since 99.99% of transactions happen off-chain. https://www.

• annabellish 9y ago
  The <2x increase is from SegWit. That post is primarily talking about the Lightning Network, which is _not_ SegWit, is _not_ currently production ready, but _is_ an improvement to scaling. Unfortunately it's a much wider ranging change than SegWit is and has a lot more gotchas and caveats, not least that you're essentially just running a second layer that has nothing to do with bitcoin, save that you need to lock your money in the LN to use it and must do this with a transaction. In order to get money back out of the LN, you need to settle it with the blockchain, which still relies on the blockchain. Essentially, "how fast can SegWit + lightning go" is not actually all that useful a question. SegWit is wildly insufficient to let the LN work as a fast settlement layer over bitcoin because opening and closing LN channels still requires bitcoin transactions, and there simply isn't the throughput for this at scale. The only way that that can work is if we rely on the lightning network completely and effectively ignore bitcoin. In this case it can work, but the LN in this context is a centralised beast because you cannot afford to open new payment channels due to lack of space in the underlying layer. The promise of lightning, way back when, was the idea that you'd be able to instantly send money to your coffee shop via your existing channels with bob and alice, and if you didn't have a path to the coffee shop then it was no big deal beacuse you could just open one, and then you become alice and bob's conduit. Unfortunately, with the lower settlement layer unable to scale, we're in the scenario where you cannot open that payment channel with your coffee shop because you can't afford the fees because even at 4x today's capacity there simply isn't enough room for everyone to open payment channels to their coffee shops. So you open a payment channel once, to your bank or a bank-like entity, and they have payment channels to everyone else. Great, it works, you never touch the blockchain, and it's a centralised system again that has none of the properties people like about cryptocurrencies - whoops!
  • wellboy 9y ago
    Oh, that's a very detailed explanation, very interesting. So, could you then make a new blockchain for all LN transactions, seperate from Bitcoin?
    • annabellish 9y ago
      Well, you don't do LN transactions on a blockchain at all, that's where the speed improvements come from. It's all a lot more ad hoc than that. If I send you $5 via the LN, then the only communication that needs to happen is between us. We do _not_ announce it to the world like you do for a blockchain, there's no one centralised ledger of events. Eventually we need to "settle" our payment channel, because the way this works is that in order to send you $5, I need to commit that $5 to a payment channel first (which requires a bitcoin transaction to lock that money in place), send it to you via the channel, and then we can settle the payment channel (which requires another transaction to unlock the money, except to you instead of me) This is extremely inefficient for one transaction, though. You'd really need to commit a lot more money to your payment channel so you can use it for many things. If you use it for more than two things, you're gaining efficiency, but rememebr that you can't add money to it or take money out without going onto a blockchain. This unfortunately still leaves us with the cruical flaw of blockchains, in that they're a decentralised and consistent ledger and that's actually really expensive to maintain. It's why there's so much push-back against making bitcoin's blocks bigger, 'cos the bigger your blocks are the harder it gets to move everything around fast enough to keep things running. It might seem trivial to move 1MB every ten minutes, but remember that that's 1MB every ten minutes to every node on the network, sometimes via connections which aren't very fast. Most notably, the great firewall of china is actually not very fast at all, and so blocks moving into and out of china have to do so relatively slowly. We triple the block size and maybe we can't keep up any more, and if the network can't talk to itself fast enough to move blocks around every ten minutes we have a network partition that won't fix itself and a big problem. And that's fundamental, right? You can strip out PoW, you can tune all the values you like, it's just a question of bandwidth. 10MB blocks every ten minutes, 1MB blocks every minute, 100kb blocks every few seconds, it doesn't matter. The bandwidth to move that around a distributed global network isn't there. We can move all the LN opens/settlements to a different blockchain, but all we'll do is make it so that we have scaling problems on a different blockchain. To be perfectly honest, I can't see a way for it all to work smoothly. There's unsolved, Hard-with-a-capital-H distributed computing problems which need solving to make this work, and there hasn't been any progress made towards solving them. Bitcoin and friends appear to work because they balance in a kind of "habitable zone" between throughput and usage, where eschewing Consistency and Partition Tolerance from the CAP theorem doesn't seem too bad, because even though we've dropped Consistency the fact that we don't really get long network partitions means that your transactions aren't going to get undone very often (but it absolutely can happen!), and even though we've dropped Partitian Tolerance that isn't that bad because we don't really get long network partitions and we have a partitian resolution operator that only drops transactions sometimes. But if blocks can't get around the network fast enough then suddenly we do get major network partitions, and that means our mitigation for lack of consistency falls apart, and so we don't have a working partition resolution operator. We're left with our choice to pick only "A" from CAP, and have a highly available network that doesn't reliably commit transactions and very often splits into multiple partitions. Argh! Multiple blockchains could mitigate this issue, but they can't really talk to each other very well, not without incurring further losses of efficiency. In that scenario we'd need four transactions to send our $5 - one to open the channel, one to close it, and two to jump blockchains. Ack! These are just really hard problems and hopefully they can be solved, but right now there are no even proposed solutions which can fix this.