Content | Time | Tags |
---|---|---|
Payment Channels | 6 min | payment channels, primer, video |
Understanding Payment Channels | 10 min | payment channels |
Lightning Network BOLT by BOLT with Jim Posen | 60 min | BOLTs, video |
Lightning ≈ Bitcoin | 35 min | video |
History of the Lightning Network | 51 min | video |
Revocable Transactions | 10 min | revocable transactions |
Bitcoin timelocks in a nutshell | 6 min | timelocks, primer |
Bitcoin Timelocks Explained | 16 min | timelocks |
Hashed Timelock Contracts with Rusty Russell | 5 min | HTLCs |
Visualizing HTLCs and the Lightning Network's Dirty Little Secret | 10 min | HTLCs |
HTLC implementation in the Core wallet | 20 min | HTLCs |
- Given the fact that Lightning is punishment-based and that it requires nodes to be online, could an attacker trick you into publishing old states and lose all your funds?
-
When 2 parties exchange the previous commitment’s secrets (to invalidate prev state), how do you make sure that the exchange happen atomically? i.e., whether both receive the other’s secret, or none at all?
-
Related to (2), how do you exchange previous commitment's data if the parties aren't online on the same time?
- How can signature checks of arbitrary data be used to not have to store signatures for each channel state?
- Why do CSV and CLTV rely on nLocktime or nSequence being set in the transaction that is spending the outputs when the script could check the if the requirements are being met by itself?
- Can both CSV and CLTV be used in the same Output and are there any known use cases for it? "all nSequence locked transactions are opting into RBF": in general why do these 2 concepts (timelock & RBF) are mixed together? why can't a nSequence-locked tx opt out of RBF (but a nTimeLock-locked tx can)? was this intentional? what are the implications of this?
- Is it fair to say UTXO-level timelocks are superior to tx-level timelocks? as they are baked directly into the protocol & allow more flexiblity/control. Are tx-level timelocks still necessary? (Assuming there's a way to implement UTXO-level timelocks without relying on nLockTime/nSequence)