SF Bitcoin Devs Seminar: Scaling Bitcoin to Billions of Transactions Per Day
Why Bitcoin Stack Exchange recommends it
Bitcoin Stack Exchange users link it as the primary source for how payment channels, timelocks and multi-hop routing in the Lightning Network were first explained, often citing specific timestamps.
Recommended by 1 people across 1 different months, 2015 to 2019.
What it is
A seminar recording from the San Francisco Bitcoin Developers meetup in which Joseph Poon and Thaddeus Dryja present the original Lightning Network design. They cover payment channels, multi-hop payments with hash and time locks, and how off-chain transfers could let one blockchain handle global payment volume without custodial risk.
What people said
Recommends Thorkil Værge · 2019-10 · Bitcoin Stack Exchange · on “Can someone explain nLockTime?”
The payment channel I described here is the unidirectional payment channel that is explained in the first 10 minutes of this video: [this video]
Cites morsecoder · 2015-04 · Bitcoin Stack Exchange · on “Do new SIGHASH types need a hard fork or a soft fork?”
There have been a few new sighash types proposed. SIGHASH_NORMALIZED [this video] : Use a 'normalized' TXID in the inputs when serializing for signing. This normalized transaction id is calculated by removing the scriptSigs of the transaction that you are spending from before serializing. SIGHASH_NOINPUT [this video] : Just remove TXIDs from the inputs entirely. Useful for thwarting malleability, but allows funds sent to that same scriptPubKey again to be stolen, so you would only sign an input with this if you are sure you are never going to use that scriptPubKey again. SIGHASH_WITHINPUTVALUE [LINK] : Include the input's value when replacing the scriptSig with the previous scriptPubKey, so signers ca
Cites Eric Allam · 2017-11 · Bitcoin Stack Exchange · on “Is Lightning Network a blockchain technology?”
The Lightning Network [LINK] is a protocol that builds on top of a blockchain and uses cryptography to allow value to be transferred between untrusted parties outside of the blockchain, giving these value transfers the ability to handle increased capacity. But the Lightning network is built on top of a blockchain (hence it's known as a "layer 2" solution) because the value transferred in the network is funded by and settled to the originating blockchain. For more information check out this talk announcing [this video] the lightning network
Cites Sergei Tikhomirov · 2017-11 · Bitcoin Stack Exchange · on “Lightning network: Are decrementing timelocks used in bi-directional channels?”
I am surely not getting some part of this, but it seems to me that the paper [LINK] and the video [this video] (both listed on the official Lightning website [LINK] ) contradict each other. In particular, the paper describes a simple bi-directional payment channel in Section 3 using only one timelock value (1000 blocks). In the video though they claim [this video] that in order to reverse the direction of the channel you have to use a shorter timelock (which makes indefinite number of channel updates impossible). Are decrementing timelocks actually used in simple bi-directional channels? If so, what would go wrong if new commitment transactions were just created with the same timelock value, say, 1000
Cites Sergei Tikhomirov · 2017-12 · Bitcoin Stack Exchange · on “Lightning: why do we need decrementing timelocks in multi-hop payments?”
The video (at 28:25) [this video] from the official Lightning website describes a multi-hop payment. I understand what a hash-locked contract is, but I still don't understand why we need a timelock aspect here. As you see on the slide, in a multi-hop payment A -> B -> C -> D, (A -> B) has a 3-day nLockTime, (B -> C) has a 2-day nLockTime, and (C -> D) has a 1-day nLockTime. nLockTime [LINK] of time t means that the transaction can not be included in a block earlier than t. So as time passes, first the (C -> D) becomes valid, then (B -> C) becomes valid, then (A -> B) becomes valid. Joseph Poon says at 28:35 (emphasis mine): "Dave's and Carol's channel [...] closes first. And Carol is happy with t
Cites Bill Bisco · 2019-01 · Bitcoin Stack Exchange · on “Lightning Network: Is it creating 3 transactions instead of 2?”
I'm watching this [this video] Lightning Network presentation by the original authors. At 9 minutes in, he notes that all the network sees will be a transaction to the multisig address and then a transaction to Alice for 0.8 BTC and a transaction to Bob for 0.2 BTC. Is all of this effectively 3 transactions? Would it not be cheaper and clog the blockchain less by simpling having Alice send 0.1 BTC to Bob and then another 0.1 BTC to Bob and have 2 transactions instead of 3?