Good morning Ruben,
> Hey Christian,
>
> Thanks for chiming in :)
>
> >It might be worth adopting the late fee binding we have in eltoo
>
> That is where my thinking originally went as well, but then I remembered that
> this alters the txid, causing the settlement tx to become invalid. What I am
Hey Christian,
Thanks for chiming in :)
>It might be worth adopting the late fee binding we have in eltoo
That is where my thinking originally went as well, but then I remembered
that this alters the txid, causing the settlement tx to become invalid.
What I am suggesting should be functionally t
> Wouldn't that result in a changing pubkey at each update, and thus
require an onchain move to be committed?
Suggestion was in line with original proposal where no keys are changing
ever, just not presupposing existence of MuSig.
On Thu, Mar 26, 2020 at 1:15 PM Christian Decker via bitcoin-dev <
Ruben Somsen via bitcoin-dev
writes:
> Regarding modification 1, I agree with ZmnSCPxj that
> Decker-Wattenhofer is your next best option, given that eltoo is not
> yet available. But if you are going to use a kickoff transaction, keep
> in mind that every previous owner will have a copy of it. Be
Very good point, but I think this is easy to fix.
It's not actually necessary that the quantity in (b) involve the SE's secret key
s1. It can be purely the blinding factor. This quantity gets relayed through the
SE anyway, after a round trip through owner 2, where the SE removes the blinding
nonce
Hi Tom,
Nice to see you working on this.
Regarding modification 1, I agree with ZmnSCPxj that Decker-Wattenhofer is
your next best option, given that eltoo is not yet available. But if you
are going to use a kickoff transaction, keep in mind that every previous
owner will have a copy of it. Becau
