Bitcoin Forum

Recently Rusty figured out how LN could be made to work without malleability fixes (EDIT: except for BIP 62) : http://ozlabs.org/~rusty/ln-deploy-draft-01.pdf. The drawback of his approach is that monitoring the network to make sure the other guy doesn't post a revoked transaction is not outsourcable. You have to be monitoring the network yourself, otherwise the person you trusted to monitor it for you could give information to the other person on the LN channel and let them steal money from you.

My modification is a way to get the benefits of Rusty's modification, without giving up outsourcability.

In short, the reason malleability is a problem for the original LN design is that both people are funding the anchor tx, and one person is posting the anchor tx, and whoever posts it can modify it in such a way that he screws over both people.

A solution is to make the anchor transaction funded by just one person, and posted by that same person. That way, the funding person only screws over themselves if they modify the anchor tx before posting it.

Suppose Alice and Bob want a LN channel. Alice crafts an anchor tx funded by 5 BTC from herself. Its one output requires a signature from both Alice and Bob. (I'm simplifying by leaving out the details of OP_CSV and revoking commitments). Alice also crafts a commitment tx which spend's the anchor's output, sending all 5 BTC to an address Alice controls. Bob signs the commitment tx and send it back to Alice. Now Alice can post the anchor tx, because she knows she can spend it with the commitment tx that Bob just signed. Alice could modify the anchor's hash before posting it, but she would only be screwing over herself. So she posts the same anchor tx that her commitment tx refers to.

Now Alice can pay Bob, but Bob can't pay Alice via the LN channel because Bob has zero balance on the channel. However we can get to a state from here that is as if Alice and Bob had both funded the anchor tx with 2.5 BTC each. Bob just needs to pay Alice 2.5 BTC, and Bob and Alice need to modify the commitment txs and revoke the old ones. How can Bob pay Alice in a trustless way? He can open a simple temporary one-way payment channel to Alice. He transfers minuscule amounts of BTC over a one-way channel, and each time he does, he and Alice sign new commitment txns on the LN channel and revoke their old ones. At any point, Alice can only steal a minuscule amount from Bob (or vice versa -- they can do the transfers in either order, so either person is at risk of losing one cent or whatever the incremental transfer amount is). Once Bob transfers the 2.5 BTC to Alice via the simple one-way channel, Alice can close this channel and each person's "balance" on the LN channel is 2.5 BTC.

Because this avoids the escape transactions described in the paper linked above, either party can now outsource the work of watching the network for cheating attempts.

Will this work?

aj on the LN IRC channel suggested an improvement to this technique -- a better way for Bob to pay Alice instead of using a one way payment channel:


I also updated the original post to note that this does require BIP 62.

I like it!

The atomic swap to inside the channel seems like a useful rebalancing technique in general (though asking me late Saturday night it's possible I missed something!).  It's possibly more general than the thoughts I had for upgrading/changing anchors, but that requires more pondering.

It doubles the total opening time, which may or may not be a problem.  But outsourcability is so nice it's probably worth it!

Now please go back in time and post this last week, before I implement dual-anchors  ;D

Maybe you should take a break from implementing stuff until this innovation-storm settles down  :)

Glad it seems to work.

About the opening time: could you clarify why there's an extra delay?  I'm imagining that Alice would post her anchor tx and Bob would post his payment tx to Alice within seconds of each other. Bob is protected by a timeout, and Alice is protected because her tx is only paying herself at first. They wait until both txs are confirmed, then Bob can reveal his secret. Is this actually slower than your original method?

Let's assume that for some reason Bob wants it to be impossible for his tx to confirm and the anchor tx to be orphaned. I believe this can be solved by making Bob's payment outside of the channel dependent on an output from the anchor tx. The new anchor tx has a 5 BTC input from Alice, but now two outputs: one of value 1 satoshi spendable only by Bob, and another of 5 BTC (minus one satoshi) with spending requirements exactly like before. Bob broadcasts his tx paying Alice 2.5 BTC (if she knows his secret) using this 1 satoshi output as an input. Now Bob doesn't even have to wait for the anchor to be confirmed before revealing his secret, as long as he and Alice have exchanged suitable commitment txs that depend on the anchor's "main" output.

I thought I did!  :)

Good point!

And I've corrected my ml post, http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-July/000069.html (http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-July/000069.html)

Thanks!
Rusty.