Joseph Poon [ARCHIVE] on Nostr: š Original date posted:2015-07-13 š Original message: On Tue, Jul 07, 2015 at ...
š
Original date posted:2015-07-13
š Original message:
On Tue, Jul 07, 2015 at 03:39:39PM +0930, Rusty Russell wrote:
> Feedback, optimizations, horrible holes?
I think this model works! As soon as OP_CHECKLOCKTIMEVERIFY soft-forks
into bitcoin, a basic lightning implementation may be theoretically
possible in real bitcoin (with some significant caveats)!
I think Thaddeus Dryja came up with a similar implementation to resolve
malleability in multisig (involving a clock and 2-input/2-output).
However, I think a true malleability fix is still ideal.
To complete the thought, I think it's possible to make the Commitment
Transactions malleability-safe under this construction.
> The order is as follows:
>
> 1) We both trade anchor txids and amounts.
> 2) We both trade signatures for the escape transactions, so either one
> can broadcast them.
> 3) Now we are sure to be able to recover our funds, we each broadcast
> our anchor txs.
> 4) If the other side broadcasts their escape transaction, abort and
> broadcast our escape transaction. After the timeout, we can spend
> it.
> 5) If the other side doesn't broadcast their anchor tx, abort and
> broadcast our escape transaction.
> 6) Otherwise, when the anchor txs reach the required depth, we exchange
> signatures for the commitment transaction.
> 7) If the other side broadcasts either escape transaction, broadcast
> the other escape transaction and the commitment tx as normal (this is
> a unilateral close) before they can reclaim their anchor funds.
To create the Commitment Transaction (in step 6 and all future
Commitment Transactions), it requires spending from the two inputs
separately and the output would require having OP_CLTV or OP_CSV in the
script output to determine whether a Commitment has been revoked. This
is necessary since one cannot be fully confident about the Transaction
ID beforehand.
If the inputs are 0.5 Alice and 0.5 Bob, the first Commitment
Transaction would refund 0.5 to Alice and 0.5 to Bob. As always, there
are a pair of Commitment Transactions per commitment state. Presume the
current block height is 350,000 and the channel closes at 355,760.
The Commitment Transaction which only Alice can broadcast, Commitment
1a, would have the following outputs:
0. 0.5 BTC
BobKey
1. 0.5 BTC
OP_IF
<AlicePubKey> OP_CHECKSIGVERIFY
<355,760> OP_CLTV OP_DROP
OP_ELSE
OP_HASH160 <RevocationHash> OP_EQUALVERIFY
<BobPubKey> OP_CHECKSIGVERIFY
OP_END
This is the general idea at least (haven't checked the script). Bob gets
all his money if Alice broadcasts it immediately because Alice is
attesting Bob should get *at least* 0.5 BTC. For the second output
(output 1), the first path gives Alice the funds at channel expiration.
The second path is so if the current Commitment transaction is not
Commitment 1 and Alice should lose all her money for incorrectly
broadcasting Commitment 1. Alice does this by attesting to Bob she
wouldn't broadcast Commitment 1 by giving the RevocationPreimage which
is hashed into RevocationHash.
Bob also has a Commitment Transaction which is the opposite (Alice's
funds get paid immediately, Bob's funds is encumbered by time).
The purpose of doing this type of construction instead of using
nLockTime on the transactions spending from the Commitment Transaction
is so that each output only requires one signature. By having only one
signature, malleability concerns can be mitigated, since that single
party can simply resign and is not dependent upon the cooperation of the
counterparty if the Commitment Transaction itself gets mutated. Since
the Commitment Transaction is only build after the Anchor and Escape
transactions exist, then this construction will allow for Lightning
Network channels to exist with OP_CLTV, with the caveat that with
uncooperative counterparties, you will have to wait until channel
expiration to get your money back. However, it does mean that playing
with LN is a possibility on the real bitcoin chain in the near future.
Very cool, Rusty!
--
Joseph Poon
š Original message:
On Tue, Jul 07, 2015 at 03:39:39PM +0930, Rusty Russell wrote:
> Feedback, optimizations, horrible holes?
I think this model works! As soon as OP_CHECKLOCKTIMEVERIFY soft-forks
into bitcoin, a basic lightning implementation may be theoretically
possible in real bitcoin (with some significant caveats)!
I think Thaddeus Dryja came up with a similar implementation to resolve
malleability in multisig (involving a clock and 2-input/2-output).
However, I think a true malleability fix is still ideal.
To complete the thought, I think it's possible to make the Commitment
Transactions malleability-safe under this construction.
> The order is as follows:
>
> 1) We both trade anchor txids and amounts.
> 2) We both trade signatures for the escape transactions, so either one
> can broadcast them.
> 3) Now we are sure to be able to recover our funds, we each broadcast
> our anchor txs.
> 4) If the other side broadcasts their escape transaction, abort and
> broadcast our escape transaction. After the timeout, we can spend
> it.
> 5) If the other side doesn't broadcast their anchor tx, abort and
> broadcast our escape transaction.
> 6) Otherwise, when the anchor txs reach the required depth, we exchange
> signatures for the commitment transaction.
> 7) If the other side broadcasts either escape transaction, broadcast
> the other escape transaction and the commitment tx as normal (this is
> a unilateral close) before they can reclaim their anchor funds.
To create the Commitment Transaction (in step 6 and all future
Commitment Transactions), it requires spending from the two inputs
separately and the output would require having OP_CLTV or OP_CSV in the
script output to determine whether a Commitment has been revoked. This
is necessary since one cannot be fully confident about the Transaction
ID beforehand.
If the inputs are 0.5 Alice and 0.5 Bob, the first Commitment
Transaction would refund 0.5 to Alice and 0.5 to Bob. As always, there
are a pair of Commitment Transactions per commitment state. Presume the
current block height is 350,000 and the channel closes at 355,760.
The Commitment Transaction which only Alice can broadcast, Commitment
1a, would have the following outputs:
0. 0.5 BTC
BobKey
1. 0.5 BTC
OP_IF
<AlicePubKey> OP_CHECKSIGVERIFY
<355,760> OP_CLTV OP_DROP
OP_ELSE
OP_HASH160 <RevocationHash> OP_EQUALVERIFY
<BobPubKey> OP_CHECKSIGVERIFY
OP_END
This is the general idea at least (haven't checked the script). Bob gets
all his money if Alice broadcasts it immediately because Alice is
attesting Bob should get *at least* 0.5 BTC. For the second output
(output 1), the first path gives Alice the funds at channel expiration.
The second path is so if the current Commitment transaction is not
Commitment 1 and Alice should lose all her money for incorrectly
broadcasting Commitment 1. Alice does this by attesting to Bob she
wouldn't broadcast Commitment 1 by giving the RevocationPreimage which
is hashed into RevocationHash.
Bob also has a Commitment Transaction which is the opposite (Alice's
funds get paid immediately, Bob's funds is encumbered by time).
The purpose of doing this type of construction instead of using
nLockTime on the transactions spending from the Commitment Transaction
is so that each output only requires one signature. By having only one
signature, malleability concerns can be mitigated, since that single
party can simply resign and is not dependent upon the cooperation of the
counterparty if the Commitment Transaction itself gets mutated. Since
the Commitment Transaction is only build after the Anchor and Escape
transactions exist, then this construction will allow for Lightning
Network channels to exist with OP_CLTV, with the caveat that with
uncooperative counterparties, you will have to wait until channel
expiration to get your money back. However, it does mean that playing
with LN is a possibility on the real bitcoin chain in the near future.
Very cool, Rusty!
--
Joseph Poon