Published on: 2015-07-14T05:56:57+00:00
Rusty Russell and Joseph Poon have been discussing the feasibility of implementing a basic lightning implementation in real bitcoin after OP_CHECKLOCKTIMEVERIFY soft-forks into it. However, there were some caveats that needed to be addressed. Joseph suggested using OP_CHECKSEQUENCEVERIFY (relative CTLV) to reduce these caveats and make the implementation possible. During their private email conversation, Rusty realized that the malleability issue could render the commitment transaction useless. However, he proposed a variant that Joseph approved of and made improvements upon. Rusty is currently finalizing the details.Rusty Russell has put forward a proposal for a basic lightning implementation that could potentially work in real bitcoin once OP_CHECKLOCKTIMEVERIFY is implemented. Thaddeus Dryja had previously come up with a similar implementation to tackle malleability in multisig by involving a clock and 2-input/2-output. However, a true malleability fix is still ideal. Russell believes it's possible to make the Commitment Transactions malleability-safe under his construction. The Commitment Transaction requires spending from the two inputs separately, and the output would have OP_CLTV or OP_CSV in the script output to determine if a Commitment has been revoked. For example, 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. Each commitment state has a pair of Commitment Transactions. Commitment 1a, which only Alice can broadcast, has specific outputs. Output 1 gives Alice the funds at channel expiration, while the second path ensures that if the current Commitment transaction is not Commitment 1, Alice loses all her money. Bob also has a Commitment Transaction that works in the opposite way. This construction allows for LN channels to exist with OP_CLTV, but in case of uncooperative counterparties, waiting until channel expiration is necessary to retrieve the money. Nevertheless, this indicates the possibility of utilizing LN on the real bitcoin chain in the near future.In a recent post, Rusty Russell revisited his ideas for establishing an anchor without new sighash modes. In the current draft paper and code, signatures are exchanged on the first commitment transaction before signing the anchor transaction. This can be done in Elements Alpha because it has segregated witness, but not in normal Bitcoin. To solve this problem, the proposal suggests having two anchors instead of one, each requiring both parties' signatures to spend. The commitment transaction has two inputs, one for each party. To recover funds in case of an abort, an intermediary transaction called "Escape" transactions is added. It spends the 2 of 2 anchor output but can be spent either by 2 of 2 (i.e., the commitment transaction) or back to the anchor owner after a delay using OP_CHECKSEQUENCEVERIFY. The process involves trading anchor txids and amounts, followed by trading signatures for the escape transactions so that either party can broadcast them. By doing this, both parties can ensure the recovery of their funds, and then they can proceed to broadcast their anchor transactions. If one side broadcasts their escape transaction, the other side should abort and broadcast their escape transaction. If one side doesn't broadcast their anchor tx, the other side should abort and broadcast their escape transaction. When the anchor txs reach the required depth, both parties exchange signatures for the commitment transaction. If one side broadcasts either escape transaction, the other side should broadcast the corresponding escape transaction and the commitment tx as usual before the first side reclaims their anchor funds. Although this technique involves three extra transactions (one for channel open and two for channel close), it does not introduce any new requirements.
Updated on: 2023-07-31T18:08:05.779949+00:00