Re: [Lightning-dev] Commitment Transaction Format Update Proposals?
ZmnSCPxj writes: > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > On Friday, October 12, 2018 2:36 PM, Rusty Russell > wrote: > >> ZmnSCPxj zmnsc...@protonmail.com writes: >> >> > Good morning Rusty and list, >> > >> > > 1. Rather than trying to agree on what fees will be in the future, we >> > > should use an OP_TRUE-style output to allow CPFP (Roasbeef) >> > > >> > >> > My understanding is that this would require some base-layer changes at >> > Bitcoin level first? At minimum IsStandard() modification, and I believe >> > luke-jr suggested, to make a consensus rule that OP_TRUE would not be >> > spendable beyond the block it appears in (i.e. it is used only for CPFP >> > hooking) to reduce UTXO database size at lower layer. >> >> If you look further down, it's actually a P2WSH to "OP_TRUE". Wastes >> some space, but it works today. > > Ah, I see. This will change again if the luke-jr proposal pushes through? > > Will robots arise which will attempt to claim as many OP_TRUE outputs as they > can find, claiming them afterwards during very-low-fee periods? I hope so! It's our technique to avoid polluting the UTXO set. Cheers, Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Proposal for syncing channel updates
Hi Zmn, > It may be reduced to a set reconciliation problem if we consider the > timestamp and enable/disable state of channel updates as part of an item, > i.e. a channel update of 111:1:1 at 2018-10-04 state=enabled is not the same > as a channel update of 111:1:1 at 2018-10-05 state=disabled. > > Then both sides can use standard set reconciliation algorithms, and for > channel updates of the same short channel ID, we simply drop all items except > the one with latest timestamp. > > The above idea might be less efficient than your proposed extension. Yes there may be some way use the structure of channel_update messages to transpose this into a set reconciliation problem, and use smarter tools like IBLTs. But we would need to have a good estimate for the number of differences between the local and remote sets. This would be the really hard part I think, and probably even harder to get right with channel_updates than with channel_announcements. I had a quick look at how this type of sync issue is handled in different contexts and my impression is that exchanging and and comparing timestamps would be the most natural solution ? But mostly my point is that I think we missed something with the current channel queries, so first I would like to know if other people agree with that :) and propose something that is close to what we have today, should be easy to implement if you already support channel queries, and should fix the issue that I think we have. Thanks, Fabrice ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Commitment Transaction Format Update Proposals?
Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Friday, October 12, 2018 2:36 PM, Rusty Russell wrote: > ZmnSCPxj zmnsc...@protonmail.com writes: > > > Good morning Rusty and list, > > > > > 1. Rather than trying to agree on what fees will be in the future, we > > > should use an OP_TRUE-style output to allow CPFP (Roasbeef) > > > > > > > My understanding is that this would require some base-layer changes at > > Bitcoin level first? At minimum IsStandard() modification, and I believe > > luke-jr suggested, to make a consensus rule that OP_TRUE would not be > > spendable beyond the block it appears in (i.e. it is used only for CPFP > > hooking) to reduce UTXO database size at lower layer. > > If you look further down, it's actually a P2WSH to "OP_TRUE". Wastes > some space, but it works today. Ah, I see. This will change again if the luke-jr proposal pushes through? Will robots arise which will attempt to claim as many OP_TRUE outputs as they can find, claiming them afterwards during very-low-fee periods? > > > > 3. The CLTV timeout should be symmetrical to avoid trying to game the > > > peer into closing. (Connor IIRC?). > > > > > > > I know this has been discussed before, but I wonder the rationale for the > > original asymmetric design, and the rationale for the new symmetric design. > > The original design does the minimum necessary (youmust have a > to-yourself delay to give time for the penalty tx to work). But, when > combined with fee asymmetry (funder pays), it can lead the fundee to not > care whether it forces the funder to perform a unilateral, or does a > graceful mutual close. > > It's not a major issue, but aligning incentives (to mutual close) makes > sense if we're changing other things I think. > I understand. I suppose this is minor improvement. It is also enabled somewhat by item 1 above (OP_TRUE CPFP hook). Currently, advantage of asymmetric is that the other side can CPFP the transaction. Now, with both having a CSV delay, neither side can CPFP, but with the CPFP hook anyone (including robots which might want to opportunistically steal OP_TRUE outputs during low-fee eras) can CPFP the transaction. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
