4 ms·
For those who may not know the context, this has to do with long-term scaling of the Bitcoin network. The very first public response to Satoshi's announcement
by apo 9y ago
For those who may not know the context, this has to do with long-term scaling of the Bitcoin network.
The very first public response to Satoshi's announcement of Bitcoin was an expression of doubt about scalability:
We very, very much need such a system, but the way I understand your proposal, it does not seem to scale to the required size.
...
To detect and reject a double spending event in a timely manner, one must have most past transactions of the coins in the transaction, which, naively implemented, requires each peer to have most past transactions, or most past transactions that occurred recently. If hundreds of millions of people are doing transactions, that is a lot of bandwidth - each must know all, or a substantial part thereof.
https://www.mail-archive.com/cryptography@metzdowd.com/msg09963.html https://www.mail-archive.com/cryptography@metzdowd.com/msg09...
And the comment was spot-on. Naively implemented, Bitcoin can only scale linearly by putting every transaction onto the block chain. Double the transaction capacity means doubling the size of blocks.
Lightning Network scales the Bitcoin network by offering a secure method for keeping many, if not most, transactions off the block chain. This is done through a clever use of Script, Bitcoin's built-in programming language.
Two parties who want to transact at high speed jointly lock up some money with an on-chain transaction (thereby creating a "payment channel"). Then they send each other half-signed transactions spending the locked funds. Each transaction represents a kind of private ledger. Although any of these transactions can be published at any time, it will usually be mutually beneficial to avoid doing so and continue passing half-signed transactions back and forth. When it's time to call it quits, the last transaction is published.
In other words, the intermediate transactions never need to hit the block chain. Only the final settlement transaction needs to be published.
Lightning takes this one step further by providing a mechanism whereby a party can pay another party on behalf of a third party. This means that you can make Lightning payments without necessarily having an open channel with your intended payee. You just need an open channel and the network routes your payment.
Lightning Network has been in development for years. The idea has been repeatedly disparaged as "vaporware." The first mainnet release is a big deal because that characterization no longer applies. It also means we're going to see a real-world test of an idea that up until now hasn't been widely-tested.
The Bitcoin Cash split was due in large part to a group of Bitcoiners rejecting Lightning as a scaling option. They tend to believe not only that Bitcoin can scale by increasing block size, but that this is the best way.
- thisisit 9y ago> Each one represents a kind of private ledger. That is an interesting quote. So, without the blockchain, how does Lightning track which transactions have been completed?
- XR0CSWV3h3kZWg 9y agoBasically each party has signed tx that prove the most recent balance of channel, when they want to close the channel they just broadcast the last signed txs.
- apo 9y agoEach transaction spending the locked funds bears the signature of the party making the payment. The other party can then provide the counter-signature making the transaction valid on the Bitcoin network. The main security problem to solve is preventing one party from publishing a previous channel state (half-signed transaction) giving themselves more money than they actually have by rights. For example, Alice and Bob might start with a channel giving each of them 5 bitcoin. Then Alice makes two one-bitcoin payments to Bob: A | B ------ 4 | 6 3 | 7 Alice decides she wants to take back her last payment and instead publish the earlier transaction (signed by Bob) giving herself 4 bitcoin rather than the one giving herself 3. This problem is solved with hashed timelock contracts (HTLCs). Without getting too technical, HTLCs make it possible for a party who spots a counterparty attempting to publish an invalid transaction to take all of the money in the channel (i.e., Bob would take all 10 bitcoin). The main idea is that cryptographic hash functions are one-way. If I make a payment contingent on knowing a preimage to a hash value, I can cause the payment to become valid by revealing the preimage. Along with the signature to a transaction, Alice must also give Bob the preimage for the previous transaction before he will accept it. When she does, Bob knows that if Alice tries to play games, he can take all of her money. This video gives a high-level overview: https://www.youtube.com/watch?v=MpfvhiqFw7A https://www.youtube.com/watch?v=MpfvhiqFw7A
- vagab0nd 9y agoThis makes sense. However, this also means as one party of the off-chain transaction, I need to constantly monitor the main chain to make sure the other party doesn't try to screw me up. And if they do I need to publish the contract before they spend the money. Is this correct? And how can this be made 100% bulletproof?