Another option would be to somehow encrypt this data in, say, an OP_RETURN
for any update transaction for each participant (perhaps worth breaking
update symmetry for efficiency on this...) that way if an update ever
happens on a state you don't have you can use your static key to decrypt
the relev
Without an exact implementation, one thing you could do to fix the lost
state issue would be to make the scripts something like:
[` CLTV DROP PKu CHECKSIGVERIFY GETLOCKTIME
BIP32DERIVE CHECKTRANSACTIONSIGNEDFROMSTACK`, `2016 CSV DROP PK_si
CHECKSIG`]
In order to upgrade to state M>= N+1 you'd ha
On Sun, Jul 11, 2021 at 10:01 PM Anthony Towns wrote:
> On Thu, Jul 08, 2021 at 08:48:14AM -0700, Jeremy wrote:
> > 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
Hi guys,
happy to see this being discussed again! When I came up with the idea,
it was originally intended for cases when there's an inherently trusted
exchange,
such as trading fiat for sats using an ATM. In this scenario only the push
amount was spendable.
Receiving more on top of that was disab
Hello world,
Suppose you have some payments going from Alice to Bob to Carol with
eltoo channels. Bob's lightning node crashes, and he recovers from an
old backup, and Alice and Carol end up dropping newer channel states
onto the blockchain.
Suppose the timeout for the payments is a few hours awa
