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
Published at
2023-06-09 12:43:38Event JSON
{
"id": "4ac1c48b4a8aaf01c6624b5ab0f27e5ea562f5271bba2c7326d4e37b9d21c64a",
"pubkey": "ccb4cc87c455b74febaee5929cfd0726421b2eea64ad2b16440b68e8c7433211",
"created_at": 1686314618,
"kind": 1,
"tags": [
[
"e",
"c2ba40f562a6207d34c6e66b361e338cc57efce6c2d7e65ea2659d0bf584fe0c",
"",
"root"
],
[
"e",
"a51b380653645d60a5e1a95693ee1a13f8c9866a1a9ce1ee4a793c726ba93a7d",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2015-07-13\n📝 Original message:\nOn Tue, Jul 07, 2015 at 03:39:39PM +0930, Rusty Russell wrote:\n\u003e Feedback, optimizations, horrible holes?\n\nI think this model works! As soon as OP_CHECKLOCKTIMEVERIFY soft-forks\ninto bitcoin, a basic lightning implementation may be theoretically\npossible in real bitcoin (with some significant caveats)!\n\nI think Thaddeus Dryja came up with a similar implementation to resolve\nmalleability in multisig (involving a clock and 2-input/2-output).\nHowever, I think a true malleability fix is still ideal.\n\nTo complete the thought, I think it's possible to make the Commitment\nTransactions malleability-safe under this construction.\n\n\u003e The order is as follows:\n\u003e \n\u003e 1) We both trade anchor txids and amounts.\n\u003e 2) We both trade signatures for the escape transactions, so either one\n\u003e can broadcast them.\n\u003e 3) Now we are sure to be able to recover our funds, we each broadcast\n\u003e our anchor txs.\n\u003e 4) If the other side broadcasts their escape transaction, abort and\n\u003e broadcast our escape transaction. After the timeout, we can spend\n\u003e it.\n\u003e 5) If the other side doesn't broadcast their anchor tx, abort and\n\u003e broadcast our escape transaction.\n\u003e 6) Otherwise, when the anchor txs reach the required depth, we exchange\n\u003e signatures for the commitment transaction.\n\u003e 7) If the other side broadcasts either escape transaction, broadcast\n\u003e the other escape transaction and the commitment tx as normal (this is\n\u003e a unilateral close) before they can reclaim their anchor funds.\n\nTo create the Commitment Transaction (in step 6 and all future\nCommitment Transactions), it requires spending from the two inputs\nseparately and the output would require having OP_CLTV or OP_CSV in the\nscript output to determine whether a Commitment has been revoked. This\nis necessary since one cannot be fully confident about the Transaction\nID beforehand.\n\nIf the inputs are 0.5 Alice and 0.5 Bob, the first Commitment\nTransaction would refund 0.5 to Alice and 0.5 to Bob. As always, there\nare a pair of Commitment Transactions per commitment state. Presume the\ncurrent block height is 350,000 and the channel closes at 355,760.\n\nThe Commitment Transaction which only Alice can broadcast, Commitment\n1a, would have the following outputs:\n\n0. 0.5 BTC\n\tBobKey\n1. 0.5 BTC\nOP_IF \n\t\u003cAlicePubKey\u003e OP_CHECKSIGVERIFY \n\t\u003c355,760\u003e OP_CLTV OP_DROP\nOP_ELSE\n\tOP_HASH160 \u003cRevocationHash\u003e OP_EQUALVERIFY\n\t\u003cBobPubKey\u003e OP_CHECKSIGVERIFY\nOP_END\n\nThis is the general idea at least (haven't checked the script). Bob gets\nall his money if Alice broadcasts it immediately because Alice is\nattesting Bob should get *at least* 0.5 BTC. For the second output\n(output 1), the first path gives Alice the funds at channel expiration.\nThe second path is so if the current Commitment transaction is not\nCommitment 1 and Alice should lose all her money for incorrectly\nbroadcasting Commitment 1. Alice does this by attesting to Bob she\nwouldn't broadcast Commitment 1 by giving the RevocationPreimage which\nis hashed into RevocationHash.\n\nBob also has a Commitment Transaction which is the opposite (Alice's\nfunds get paid immediately, Bob's funds is encumbered by time).\n\nThe purpose of doing this type of construction instead of using\nnLockTime on the transactions spending from the Commitment Transaction\nis so that each output only requires one signature. By having only one\nsignature, malleability concerns can be mitigated, since that single\nparty can simply resign and is not dependent upon the cooperation of the\ncounterparty if the Commitment Transaction itself gets mutated. Since\nthe Commitment Transaction is only build after the Anchor and Escape\ntransactions exist, then this construction will allow for Lightning\nNetwork channels to exist with OP_CLTV, with the caveat that with\nuncooperative counterparties, you will have to wait until channel\nexpiration to get your money back. However, it does mean that playing\nwith LN is a possibility on the real bitcoin chain in the near future.\n\nVery cool, Rusty!\n\n-- \nJoseph Poon",
"sig": "39457e690b7752e35f2f97de480c49c15850b52fa0c01d18a39e834150bad3dac72f58035e9ccba360e2928be49aed350a832a96c32edb90c75d202337d1d91d"
}