4 ms·

Payment channels, besides being alpha/never used in production, are also dependent on a transaction malleability fix. Since SegWit was rolled into this soft-for

by lhl 10y ago

Payment channels, besides being alpha/never used in production, are also dependent on a transaction malleability fix. Since SegWit was rolled into this soft-fork disaster, I'm pretty confident in saying it will never reach 95% and activate (there are almost as much BU/BCl support as BCo/SW support at this point), so a non-starter honestly. I'm not against PCs in principle, I just don't understand why the block size wasn't increased and then a fully tested version of LN being rolled out afterwards - instead we've 2 years where the blocksize cap has been looming, a year where Bitcoin functionality has actually been crippled (Bitcoin is the only "successful" technology I know of where it's getting more expensive and performing worse as time has been going on), and of course there's been a combination community and developer civil war/purge (and subsequent deadlock) that could have easily been avoided. This whole mess has been extremely counterproductive. Note, even in Poon and Dryja's original paper, they outline that LN still requires bigger blocks: "If we presume that a decentralized payment network exists and one person will make 3 blockchain transactions per year on average, Bitcoin will be able to support over 35 million users with 1MB blocks in ideal circumstances (assuming 2000 transactions per MB). This is quite limited, and an increase of the block size may be necessary to support everyone in the world using Bitcoin." It's worth pointing out that Bitcoin currently has just under 52K unconfirmed transactions in the backlog (this will take hours if not days to clear) and that PCs still have risks/failure modes from that as well (failure of breach remedy transactions can actually break down the counterparty trust system from my understanding, making rollbacks and even double spends possible).

runeks 10y ago
CHECKLOCKTIMEVERIFY/BIP65 fixes payment channels without fixing transaction ID malleability, so non-malleability is only a requirement for payment channels to work when we want to free received channel value while keeping the same channel ready for new payments. Technically, this could be solved by the client sending funds to two different outputs, and switching to output #2 while the settling transaction redeeming output #1 is being confirmed, and vice versa. It's a horrible hack, I know, but it works right now. Of course, the client app should take care of all of this, making it transparent to the user. I agree with Poon and Dryja that 1MB won't be enough forever, but payment channels is a bit like fiber, the capacity is basically unlimited. If you keep a payment channel open for a week, and then close it, it's completely irrelevant whether you made a single payment or 1 trillion payments over that channel, since nothing touches the Blockchain. In other words: if we are able to clear efficiently enough, it's also technically possible to get by with the 1MB limit, simply because payment channels have unlimited capacity, as they don't touch the Blockchain. > I'm not against PCs in principle, I just don't understand why the block size wasn't increased and then a fully tested version of LN being rolled out afterwards [..] Because a fully tested version of the Lightning Network doesn't exist. When it does, this plan will make sense, but that's not yet. Personally, I'm focusing my attention on something that I know is possible right now: consumer-to-merchant transactions using digital promissory notes issued in exchange for payment channel payments. It's not the most elegant solution, but unlike all other proposed solutions it actually can work right now. Much like is the case with Bitcoin, by the way. When Bitcoin was released, cryptographers/mathematicians weren't really pleased with it because of its "inelegance". But, in the end, it works better than anything else and it works right now.

by lhl 10y ago

runeks 10y ago

CHECKLOCKTIMEVERIFY/BIP65 fixes payment channels without fixing transaction ID malleability, so non-malleability is only a requirement for payment channels to work when we want to free received channel value while keeping the same channel ready for new payments. Technically, this could be solved by the client sending funds to two different outputs, and switching to output #2 while the settling transaction redeeming output #1 is being confirmed, and vice versa. It's a horrible hack, I know, but it works right now. Of course, the client app should take care of all of this, making it transparent to the user. I agree with Poon and Dryja that 1MB won't be enough forever, but payment channels is a bit like fiber, the capacity is basically unlimited. If you keep a payment channel open for a week, and then close it, it's completely irrelevant whether you made a single payment or 1 trillion payments over that channel, since nothing touches the Blockchain. In other words: if we are able to clear efficiently enough, it's also technically possible to get by with the 1MB limit, simply because payment channels have unlimited capacity, as they don't touch the Blockchain. > I'm not against PCs in principle, I just don't understand why the block size wasn't increased and then a fully tested version of LN being rolled out afterwards [..] Because a fully tested version of the Lightning Network doesn't exist. When it does, this plan will make sense, but that's not yet. Personally, I'm focusing my attention on something that I know is possible right now: consumer-to-merchant transactions using digital promissory notes issued in exchange for payment channel payments. It's not the most elegant solution, but unlike all other proposed solutions it actually can work right now. Much like is the case with Bitcoin, by the way. When Bitcoin was released, cryptographers/mathematicians weren't really pleased with it because of its "inelegance". But, in the end, it works better than anything else and it works right now.