ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2021-06-02 📝 Original message: Good morning again LL, So ...
📅 Original date posted:2021-06-02
📝 Original message:
Good morning again LL,
So I started thinking as well, about Decker-Russell-Osuntokun and the Fast Forwards technique, as well as your "desync" idea.
And it seems to me that we can also adapt a variant of this idea with Decker-Russell-Osuntokun, with the advantage of **not** requiring the additional encumbrance at the outputs.
The technique is that we allow Bob the receiver to have possession of *later* states while Alice the sender only possesses an old state.
Alice sends the signatures for a new state (update + settlement) whenever it offers an HTLC to Bob, and whenever Bob fulfills the HTLC.
However, Alice *does not* wait for Bob to return signatures for a new state.
So Alice remains stuck with the old state.
* Suppose Alice wants to close the channel unilaterally.
* Alice broadcasts the old update tx.
* Bob has an incentive to bring its latest state onchain (bringing its privkey online and signing the latest update).
* All the payments are in the Alice->Bob direction.
* Even though Alice broadcasted an old state, it does not lose money since Decker-Russell-Osuntokun is non-punitive.
* Bob can bring its privkey online to close the channel unilaterally with the latest state.
So it looks to me that Decker-Russell-Osuntokun similarly does **not** require the additional encumbrance at the "main" outputs.
We simply allow the sender to remain at an older state.
So let us give a concrete example.
* Alice and Bob start at state 1: Alice = 50, Bob = 50.
* Alice offers a HTLC of value 10.
* Alice: state 1: Alice = 50, Bob = 50
* Bob: state 2: Alice = 40, Bob = 50, A->B HTLC = 10
* Bob fulfills, so Alice sends a new state.which transfers the A->B HTLC value to Bob.
* Alice: state 1: Alice = 50, Bob = 50
* Bob: state 3: Alice = 40, Bob = 60
* Bob brings its privkey online because it wants to send out via Alice (a forwarder).
It offers an HTLC B->A of value 20.
* Alice: state 4: Alice = 40, Bob = 40, B->A HTLC = 20
* Bob: state 3: Alice = 40, Bob = 60
Because publishing old state is "safe" under Decker-Russell-Osuntokun, it is fine for one participant to have *only* an older state!
And we can arrange the incentives so that the one with the latest state is the one who is most incentivized to publish the latest state.
(We should probably change the subject of this thread BTW)
Another advantage here is that unlike the Poon-Dryja Fast Forwards, we do *not* build up a long chain of HTLC txes.
At the worst case, we have an old update tx that is superseded by a later update tx instead, thus the overhead is expected to be at most 1 extra update tx no matter how many HTLCs are offered while Bob has its privkey offline.
Regards,
ZmnSCPxj
📝 Original message:
Good morning again LL,
So I started thinking as well, about Decker-Russell-Osuntokun and the Fast Forwards technique, as well as your "desync" idea.
And it seems to me that we can also adapt a variant of this idea with Decker-Russell-Osuntokun, with the advantage of **not** requiring the additional encumbrance at the outputs.
The technique is that we allow Bob the receiver to have possession of *later* states while Alice the sender only possesses an old state.
Alice sends the signatures for a new state (update + settlement) whenever it offers an HTLC to Bob, and whenever Bob fulfills the HTLC.
However, Alice *does not* wait for Bob to return signatures for a new state.
So Alice remains stuck with the old state.
* Suppose Alice wants to close the channel unilaterally.
* Alice broadcasts the old update tx.
* Bob has an incentive to bring its latest state onchain (bringing its privkey online and signing the latest update).
* All the payments are in the Alice->Bob direction.
* Even though Alice broadcasted an old state, it does not lose money since Decker-Russell-Osuntokun is non-punitive.
* Bob can bring its privkey online to close the channel unilaterally with the latest state.
So it looks to me that Decker-Russell-Osuntokun similarly does **not** require the additional encumbrance at the "main" outputs.
We simply allow the sender to remain at an older state.
So let us give a concrete example.
* Alice and Bob start at state 1: Alice = 50, Bob = 50.
* Alice offers a HTLC of value 10.
* Alice: state 1: Alice = 50, Bob = 50
* Bob: state 2: Alice = 40, Bob = 50, A->B HTLC = 10
* Bob fulfills, so Alice sends a new state.which transfers the A->B HTLC value to Bob.
* Alice: state 1: Alice = 50, Bob = 50
* Bob: state 3: Alice = 40, Bob = 60
* Bob brings its privkey online because it wants to send out via Alice (a forwarder).
It offers an HTLC B->A of value 20.
* Alice: state 4: Alice = 40, Bob = 40, B->A HTLC = 20
* Bob: state 3: Alice = 40, Bob = 60
Because publishing old state is "safe" under Decker-Russell-Osuntokun, it is fine for one participant to have *only* an older state!
And we can arrange the incentives so that the one with the latest state is the one who is most incentivized to publish the latest state.
(We should probably change the subject of this thread BTW)
Another advantage here is that unlike the Poon-Dryja Fast Forwards, we do *not* build up a long chain of HTLC txes.
At the worst case, we have an old update tx that is superseded by a later update tx instead, thus the overhead is expected to be at most 1 extra update tx no matter how many HTLCs are offered while Bob has its privkey offline.
Regards,
ZmnSCPxj