6 ms·
None of the coins can scale realistically on-chain as a peer-to-peer system. If you run the numbers, the transaction volume of 1B people making one transaction
by VMG 9y ago
None of the coins can scale realistically on-chain as a peer-to-peer system. If you run the numbers, the transaction volume of 1B people making one transaction a day goes into the terabytes. If you externalize the costs of verifying that to third parties, you lose properties that make Bitcoin interesting to begin with.
For many people it was clear that off-chain transactions are the only feasible way to solve this. Small purchases in particular do not need to be broadcast to the whole network and can be routed in payment channels. Lighting Network is the most promising solution at the moment.
- canoebuilder 9y agoIf you externalize the costs of verifying that to third parties, you lose properties that make Bitcoin Isn't that what "off-chain transactions" and the "Lightning Network" are?
- VMG 9y agoLighting Network is a trustless protocol
- xocyabencl 9y agoIf lightning network includes tech that can support billions of transactions, can it be used without bitcoin? Why not use lighting with an uncongested coin?
- ozmbie 9y agoBitcoin is the most popular with the most resources behind it, so it makes sense to leverage off it. There's nothing stopping similar networks occurring on other coins.
- VMG 9y agoYes, any coin that has segwit or a comparable fix for malleability can use lightning. Litecoin is already supported. You can even have atomic swaps between both over lightning channels.
- canoebuilder 9y agoAre there any real world implementations of LN? Can it operate on it's own, or does it need to be a layer on top of a cryptocoin network? What incentive do LN node operators have to operate?
- VMG 9y agoYes, there are three interoperable implementations https://cdecker.github.io/lightning-integration/ https://cdecker.github.io/lightning-integration/ It runs on top of Bitcoin-like Blockchains that have segwit or something comparable. If you run a LN node you can charge fees for routing payments.
- canoebuilder 9y agoIf I pay for something using LN am I going to find it a superior experience to paying with cash or card, or am I going to find it a cumbersome experience for which I am charged an exorbitant fee?
- VMG 9y agoThe goal is to make it simple and inexpensive. Since it supports microtransactions in the sub-cent range and is irreversible, it would beat credit cards in those regards. The most expensive step would be opening a channel, but there is work on reducing that cost.
- ozmbie 9y agoThere is upfront work (first you need some bitcoin, then you need to make an on-chain transaction to open a payment channel) but after that, lightning payments are trustless, instant, and with small fees (it's designed to support micro-payments). But right now this is still VERY early in development.
- omarforgotpwd 9y agoNobody has figured out how to do this yet... nor should they have. You shouldn’t over optimize before you need to and you’ve seen where the real bottlenecks are. But now we need it, and we’ve seen where the bottlenecks are. New technologies and techniques will be needed to match Visa and Mastercard in speed and reliability.
- perfmode 9y agoActually, we should totally have scaling figured out in the design stage. You can’t buy it as an add-on
- Retric 9y agoNothing prevents a sharding as long as you have some way to prioritize in case of conflicts and you require delays from moving money into and out of accounts, but even that's not really needed. You don't need to store Terabytes per day for 1B daily transactions. BC does it differently, but you could get away with 4 byte time-stamp, 4 byte amount, 32 byte source public key, 32 byte destination public key = unique transaction + 32 byte signature demonstrating sender with correct private key signed that transaction. Now, 1 billion of those = 100GB per day = 36 TB per year which sounds like a lot but most nodes don't need the full amount just current state + verifiable hash + new transactions. But even that's not needed, suppose every node includes a subset of the account amounts so every K nodes allows you to recover the state of all accounts. That way you don't need a full database just the most recent K nodes and they have complete state. Some people can keep a historic archive, but the system operates even if that information was lost. (You would want some GC as well so accounts must either be larger than A or have a transaction within the last Z steps.) Granted, managing pending transactions increases bandwidth needs, but nodes can manage reputations based on only forwarding valid transactions. Some metrics so their is some statistical chance of conformation and you end up with ~2x overhead for unconfirmed but likely transactions. PS: You can also have the protocol grow so if the 11 of the last 20 nodes where full the new node is 1% larger.
- em3rgent0rdr 9y ago> "36 TB per year" Satoshi made a similar argument in Nov 2008 in response to a claim about Bitcoin not being able to scale: "The bandwidth might not be as prohibitive as you think. A typical transaction would be about 400 bytes (ECC is nicely compact). Each transaction has to be broadcast twice, so lets say 1KB per transaction. Visa processed 37 billion transactions in FY2008, or an average of 100 million transactions per day. That many transactions would take 100GB of bandwidth, or the size of 12 DVD or 2 HD quality movies, or about $18 worth of bandwidth at current prices." "If the network were to get that big, it would take several years, and by then, sending 2 HD movies over the Internet would probably not seem like a big deal." https://www.reddit.com/r/btc/comments/6navjt/very_first_discussion_of_bitcoin_by_satoshi_btc/ https://www.reddit.com/r/btc/comments/6navjt/very_first_disc... Note: this was before the DoS attack in 2009 where hackers tried to freeze the network by creating blocks of uneven or massive size. Which is why in Oct 2009, satoshi imposed the 1MB block size limit (I presume was intended as a temporary stopgap measure) to prevent future similar attacks.