Re: [Lightning-dev] [bitcoin-dev] Eltoo / Anyprevout & Baked in Sequences
> > This would disallow using a relative locktime and an absolute locktime > for the same input. I don't think I've seen a use case for that so far, > but ruling it out seems suboptimal. I think you meant disallowing a relative locktime and a sequence locktime? I agree it is suboptimal. What do you make of sequence tagged keys? ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [bitcoin-dev] Eltoo / Anyprevout & Baked in Sequences
On Wed, Jul 07, 2021 at 06:00:20PM -0700, Jeremy via bitcoin-dev wrote: > This means that you're overloading the CLTV clause, which means it's > impossible > to use Eltoo and use a absolute lock time, It's already impossible to simultaneously spend two inputs if one requires a locktime specified by mediantime and the other by block height. Having per-input locktimes would satisfy both concerns. > 1) Define a new CSV type (e.g. define (1<<31 && 1<<30) as being dedicated to > eltoo sequences). This has the benefit of giving a per input sequence, but the > drawback of using a CSV bit. Because there's only 1 CSV per input, this > technique cannot be used with a sequence tag. This would disallow using a relative locktime and an absolute locktime for the same input. I don't think I've seen a use case for that so far, but ruling it out seems suboptimal. Adding a per-input absolute locktime to the annex is what I've had in mind. That could also be used to cheaply add a commitment to an historical block hash (eg "the block at height 650,000 ended in cc6a") in order to disambiguate which branch of a chain split or reorg your tx is valid for. Cheers, aj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Asymmetric features
Good morning list, I've been mulling over some limitations of our feature bits mechanism and I'm interested in your ideas and comments. Our feature bits mechanism works well for symmetric features (where both peers play the same role) but not so well for asymmetric features (where there is a client and a service provider). Here is a hypothetical example to illustrate that. Any similarity to existing wallet features is entirely coincidental. Alice has a mobile lightning wallet that can be woken up via push notifications. Bob runs a lightning node that can send push notifications to mobile wallets to wake them up on important events (e.g. incoming htlcs). We can't use a single feature bit to model that, because what Alice supports is actually "I can be woken up via push notifications", but she can't send push notifications to other nodes (and similarly, Bob only supports waking up other nodes, not receiving push notifications). So we must use two feature bits: `wake_me_up_plz` and `i_say_wake_up`. Alice activates `wake_me_up_plz`, Bob activates `i_say_wake_up` and it's now clear what part of the protocol each node can handle. But how does Alice require her peers to support `i_say_wake_up`? She can't turn on the feature with the mandatory bit because then her peers would be confused and think she can wake up other devices. I see two potential solutions: 1. Re-purpose the meaning of `optional` and `mandatory` bits for asymmetric feature: the odd bit would mean "I support this feature" and the even bit would mean "I require my peer to support this feature" 2. Add a requirement to send a warning and disconnect when a client connects to a provider that hasn't activated the provider-side feature Thoughts? Cheers, Bastien Note: I opened an issue for that for those who prefer github: https://github.com/lightningnetwork/lightning-rfc/issues/885 ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
