Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2018-07-18 📝 Original message: (bitcoin-dev dropped from ...
📅 Original date posted:2018-07-18
📝 Original message:
(bitcoin-dev dropped from cc)
On Mon, Apr 30, 2018 at 05:41:38PM +0200, Christian Decker wrote:
> eltoo is a drop-in replacement for the penalty based invalidation
> mechanism that is used today in the Lightning specification. [...]
I think you can simplify eltoo further, both in the way the transactions
work and in the game theory ensuring people play fair.
In essence: rather than having a funding transaction spending to address
"X", and a set of ratcheting states that spend from-and-to the same
address "X", I think it's feasible to have a simpler ratchet mechanism:
(1) funding address: multisig by A and B as usual
(2) commit to state >=N by A
(3a) commit to state N by A after delay D; or
(3b) commit to state M (M>=N) by B
I believe those transactions (while partially signed, before posting to
the blockchain) would look like:
(1) pay to "2 A1 B1 2 OP_CHECKMULTISIG"
(2) signed by B1, nlocktime set to (N+E)
pay to "(N+E) OP_CLTV OP_DROP 2 A2a B2a 2 OP_CHECKMULTISIG"
(3a) signed by B2a, nSequence set to the channel pay to self delay,
nlocktime set to (N+E)
pays to the channel balances / HTLCs, with no delays or
revocation clauses
(3b) signed by A2a with SIGHASH_NOINPUT_UNSAFE, nlocktime set to (M+E)
pays to the channel balances / HTLCs, with no delays or
revocation clauses
You spend (2)+delay+(3a)+[claim balance/HTLC] if your counterparty
goes away. You spend (2) and your counterparty spends (3b) if you're
both monitoring the blockchain. (3a) and (3b) should have the same tx
size, fee rate and outputs.
(A1, A2a are keys held by A; B1, B2a are keys held by B; E is
LOCKTIME_THRESHOLD; N is the current state number)
That seems like it has a few nice features:
- txes at (3a) and (3b) can both pay current market fees with minimal
risk, and can be CPFPed by a tx spending your own channel balance
- txes at (2) can pay a non-zero fee, provided it's constant for the
lifetime of the channel (to conform with the NOINPUT rules)
- if both parties are monitoring the blockchain, then the channel
can be fully closed in a single block, by (2)+(3b)+[balance/HTLC
claims], and the later txes can do CPFP for tx (2).
- both parties can claim their funds as soon as the other can, no
matter who initiates the close
- you only need 3 pre-signed txes for the current state; the txes
for claiming HTLCs/balances don't need to be half-signed (unless
you're doing them via schnorr scriptless scripts etc)
The game theory looks fine to me. If you're posting transaction (2), then
you can choose between a final state F, paying you f and your counterparty
b-f, or some earlier state N, paying you n, and your counterparty b-n. If
f>n, it makes sense for you to choose F, in which case your counterparty
is also forced to choose state F for (3b) and you're forced to choose F
for (3a). If n>f, then if you choose N, your counterparty will either
choose state F because b-f>b-n and you will receive f as before, or
will choose some other state M>N, where b-m>b-f, and you will receive
m<f<n, which is a worse result. So the rational strategy seems to me
to be to choose either F all the time, or at worst an earlier state N
where every payment since then went from you towards your counterparty,
on the off-chance they're not watching the blockchain and you can get
that money back.
Note that unlike eltoo, dealing with attempted cheating in this scenario
has no extra cost over a completely fair/honest close. Always attempting
to cheat by trying to reclaim the last few payments if they were towards
your counterparty might help ensure implementations handle cheating well?
> eltoo addresses some of the issues we encountered while speficying and
> implementing the Lightning Network. For example outsourcing becomes very
> simple since old states becoming public can't hurt us anymore.
The scheme above isn't great for (untrusted) outsourcing, because if
you reveal enough for an adversary to post tx (3b) for state N, then
they can then collaborate with your channel counterparty to roll you
back from state N+1000 back to state N.
With eltoo if they do the same, then you have the opportunity to catch
them at it, and play state N+1000 to the blockchain -- but if you're
monitoring the blockchain carefully enough to catch that, why are you
outsourcing in the first place? If you're relying on multiple outsourcers
to keep each other honest, then I think you run into challenges paying
them to publish the txes for you.
Thoughts? Apart from still requiring NOINPUT and not working with
adversarial outsourcing, this seems like it works nicely to me, but
maybe I missed something...
Cheers,
aj
📝 Original message:
(bitcoin-dev dropped from cc)
On Mon, Apr 30, 2018 at 05:41:38PM +0200, Christian Decker wrote:
> eltoo is a drop-in replacement for the penalty based invalidation
> mechanism that is used today in the Lightning specification. [...]
I think you can simplify eltoo further, both in the way the transactions
work and in the game theory ensuring people play fair.
In essence: rather than having a funding transaction spending to address
"X", and a set of ratcheting states that spend from-and-to the same
address "X", I think it's feasible to have a simpler ratchet mechanism:
(1) funding address: multisig by A and B as usual
(2) commit to state >=N by A
(3a) commit to state N by A after delay D; or
(3b) commit to state M (M>=N) by B
I believe those transactions (while partially signed, before posting to
the blockchain) would look like:
(1) pay to "2 A1 B1 2 OP_CHECKMULTISIG"
(2) signed by B1, nlocktime set to (N+E)
pay to "(N+E) OP_CLTV OP_DROP 2 A2a B2a 2 OP_CHECKMULTISIG"
(3a) signed by B2a, nSequence set to the channel pay to self delay,
nlocktime set to (N+E)
pays to the channel balances / HTLCs, with no delays or
revocation clauses
(3b) signed by A2a with SIGHASH_NOINPUT_UNSAFE, nlocktime set to (M+E)
pays to the channel balances / HTLCs, with no delays or
revocation clauses
You spend (2)+delay+(3a)+[claim balance/HTLC] if your counterparty
goes away. You spend (2) and your counterparty spends (3b) if you're
both monitoring the blockchain. (3a) and (3b) should have the same tx
size, fee rate and outputs.
(A1, A2a are keys held by A; B1, B2a are keys held by B; E is
LOCKTIME_THRESHOLD; N is the current state number)
That seems like it has a few nice features:
- txes at (3a) and (3b) can both pay current market fees with minimal
risk, and can be CPFPed by a tx spending your own channel balance
- txes at (2) can pay a non-zero fee, provided it's constant for the
lifetime of the channel (to conform with the NOINPUT rules)
- if both parties are monitoring the blockchain, then the channel
can be fully closed in a single block, by (2)+(3b)+[balance/HTLC
claims], and the later txes can do CPFP for tx (2).
- both parties can claim their funds as soon as the other can, no
matter who initiates the close
- you only need 3 pre-signed txes for the current state; the txes
for claiming HTLCs/balances don't need to be half-signed (unless
you're doing them via schnorr scriptless scripts etc)
The game theory looks fine to me. If you're posting transaction (2), then
you can choose between a final state F, paying you f and your counterparty
b-f, or some earlier state N, paying you n, and your counterparty b-n. If
f>n, it makes sense for you to choose F, in which case your counterparty
is also forced to choose state F for (3b) and you're forced to choose F
for (3a). If n>f, then if you choose N, your counterparty will either
choose state F because b-f>b-n and you will receive f as before, or
will choose some other state M>N, where b-m>b-f, and you will receive
m<f<n, which is a worse result. So the rational strategy seems to me
to be to choose either F all the time, or at worst an earlier state N
where every payment since then went from you towards your counterparty,
on the off-chance they're not watching the blockchain and you can get
that money back.
Note that unlike eltoo, dealing with attempted cheating in this scenario
has no extra cost over a completely fair/honest close. Always attempting
to cheat by trying to reclaim the last few payments if they were towards
your counterparty might help ensure implementations handle cheating well?
> eltoo addresses some of the issues we encountered while speficying and
> implementing the Lightning Network. For example outsourcing becomes very
> simple since old states becoming public can't hurt us anymore.
The scheme above isn't great for (untrusted) outsourcing, because if
you reveal enough for an adversary to post tx (3b) for state N, then
they can then collaborate with your channel counterparty to roll you
back from state N+1000 back to state N.
With eltoo if they do the same, then you have the opportunity to catch
them at it, and play state N+1000 to the blockchain -- but if you're
monitoring the blockchain carefully enough to catch that, why are you
outsourcing in the first place? If you're relying on multiple outsourcers
to keep each other honest, then I think you run into challenges paying
them to publish the txes for you.
Thoughts? Apart from still requiring NOINPUT and not working with
adversarial outsourcing, this seems like it works nicely to me, but
maybe I missed something...
Cheers,
aj