That's why I'm bullish on Ripple ( Tick = XRP ). Transactions take about 3 seconds vs an hour on Bitcoin [1]. Plus Ripple's Blockchain technology has real use-cases with about 100 Banks around the world already using it for cross border transfers and liquidity.
[1] Source: Ripple CEO on CNBC - https://www.reddit.com/r/Ripple/comments/7miikv/ripple_ceo_w...
Also, here's the No Paywall version of the OP https://archive.is/6BD2U
Centralized.
https://ripple.com/insights/how-we-are-further-decentralizin...
I love decentralized crypto stuff. But let's be real, most people don't care how their payments are processed.
If XRP is actually valuable, the risk of compromise of its huge wallet should be really scary for anyone.
Use case is an advantage that Ripple has. However, then again, Ripple is pretty much owned by the banks, so that's a downer.
https://www.reddit.com/r/Bitcoin/comments/5f8w7f/if_both_seg...
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!
So, could you then make a new blockchain for all LN transactions, seperate from Bitcoin?
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.
Yes, but I meant using a blockchain for the decentralised aspect of things.
> 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!
Is it bad to use 4 transactions for 1 transaction when it makes your transaction througput 100000x higher?
> 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.
Aren't there already altcoins that have solved the transaction scalability problem?
Not really. It'll increase latency on commit confirmation and that might suck, though.
>Aren't there already altcoins that have solved the transaction scalability problem?
Nope. There's ones that can scale better than bitcoin, but in the end there's only so many parameters you can tune and an actual solution requires more than just tuning block size / block rate.