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
Re: [Lightning-dev] Commitment Transaction Format Update Proposals?
ZmnSCPxj 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. >> 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 (you *must* 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. Cheers, Rusty. ___ 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?
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. It seems the other parts of this proposal, do not need this base-layer change; so, this may delay the other parts (but perhaps it is not at all an issue to delay the other parts of this proposal...?). > 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. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
