From matsjj at gmail.com Thu Aug 13 18:37:18 2015 From: matsjj at gmail.com (Mats Jerratsch) Date: Thu, 13 Aug 2015 20:37:18 +0200 Subject: [Lightning-dev] Pure No-Trust Solution using only OP_CLTV Message-ID: Joseph asked, what changes OP_CLTV would bring to my Thunder proposal, and I started working out, how much is actually possible with only CLTV implemented. It is still unclear, how CLTV and CSV are activated, and there are discussions about adding them in one single softfork, rendering this design useless of course. Nevertheless, maybe someone can find some interest in it, I wasn't able to find it on the mailing list or in any paper. Excerpt from thunder.network: Channel Design: http://thunder.network/images/image09.png http://imgur.com/nmpRYSe (Mirror) With OP_CLTV it is possible to replace the payout-to-multisig-and-give-timelocked-partly-signed-transaction with a simple OP-code, specifying for how long the output should not be spent. With this it is able to completely mitigate all the malleability problems we have in our current solution. Let?s take a look into some of the changes made and their implications. Opening Transaction There are no longer refund transactions that needs to get interchanged. It is possible to directly make the refund to both parties part of the opening transaction. This completely removes any risk problems and allows for large amount of funds within the channel. As soon as the refund time has come, both parties can get their respective funds back with just their sole private key. As we cannot accomplish the exact distribution with just one output and CLTV, we use two outputs that only differ in the refund private key. By doing so, any channel transaction has to include both these outputs (and of course both has to be signed accordingly), leading to (slightly) larger transactions. Channel Transaction Settled Funds We use the same mechanism as in the opening transaction here, and added a multi-sig output to ensure that these funds are revocable. If both parties agree on a new version of the channel, they release their temporary signatures A2 and B2. If a party broadcasts a channel that was marked as revoked, the other party can steal those funds. Furthermore, malleability is no longer an issue, as refunds are only timelocked using CLTV, and in case of a revoke, the other party has both private keys. In any case, we are no longer depending on having a specific transaction presigned by the other party. Sending HTLC Making a payment now consists of 3 outputs. We combine the mechanism for refunds and for revocable transactions (see above) with the ability of the receiver to claim the payments in case he knows the secret R. We lowered the refund time to the general timeframe of a payment, such that it is enforceable by the sender. Again, as we don?t depend on presigned transactions, malleability is no longer an issue. Receiving HTLC The outputs of a receiving HTLC are very similar to those of a sending one, but with the private keys set accordingly. Also the timeframe is down to 6 days, such that we have plenty of time to determine if a payment will get refunded or not. Now there are a couple of problems with this design, mainly that HTLCs are not strictly revocable. If one party broadcasts a revoked transactions with HTLCs inside, the other party can just try to race against the propagation of the claiming transactions, which will often be fruitless. This goes for receiving payments, where the party can claim the funds with the secret R and also for sending payments, where he can use the refund option (for revoked channels which are older than the refund timeout). This can however completely mitigated using a simple reserve strategy (see below for details, it can be applied for payments in both directions). Additionally, this new channel design means that a channel will get closed and broadcasted completely, as soon as the refund condition for any payment in your channel is met. To counter this as a receiver of a payment, you have to reveal the secret or settle a new channel without the payment (manual refund) in time with the other party. As a sender, you have to check back the payment before the refund, to work out with the other party if the payment should refund or settle. Those timeframes are just for illustration, it might be preferable to play along with those numbers a bit. For example, the one day difference between the sender and the receiver means that in extreme cases the sender only has one day for updating his channel. Furthermore, there isn?t really a reason the receiver has 6 days time to reveal his secret, where 6 hours would be plenty of time as well. Finally, we can also extend the period for a payment, resulting in a longer lock-up time frame at the end of the channel. With channels being strictly no-trust, we can move towards larger amounts of funds inside the channels, mitigating the problem with non-revocable HTLCs and the workaround. It just becomes one additional rule we have to apply among all the others that are apparent already. Implementing these changes in the current Thunder implementations is trivial. It comes down to deleting a lot of methods currently necessary and switching to the new scripts. This goes for most channel design changes, as the design of Rusty for example. Appendix: Payments in older Channel Versions There is a problem, as settlement transactions are not time-encumbered (we want that whoever deserves the output of a payment to be able to claim it instantly, with no one possibly interfering). This means if one party has a channel transaction with a payments towards it, he can claim this payment under any circumstances. However, if this party does broadcast a revoked channel to claim such an output, the counterparty can still steal all settled funds and all funds towards his channel. It is therefore important to keep track of the amounts the other party is receiving. We have to know, which is the highest amount the other party ever had as receiving payments in his channel, and we must make sure that we decline any attempts of him spending money, such that his balance would drop below this amount. This will be more clear using this example: We start with a channel, with Alice and Bob, and both fund the mutual channel with 10 BTC. So at t=0 we are at Alice - 10 BTC Bob - 10 BTC Now imagine that for some reason, Alice received payments, such that she has 5 BTC as uncleared payments in her channel. t=t1 Alice - 10 BTC ( +5 BTC uncleared ) Bob - 5 BTC She reveals the secrets and Alice and Bob settle those payments, leading to t=t2 Alice - 15 BTC Bob - 5 BTC Now if Alice were to be free to spend all her money, if we don?t enforce the above rules, she could spend all her money (leading to legitimate payment contracts in other channels that we are obliged to). t=t3 Alice - 0 BTC Bob - 20 BTC But, as reasoned above, payments towards Alice can always be claimed by Alice, such that she can claim the 5 BTC from the t=t1 channel transaction and Bob losing those 5 BTC. The t=t1 transaction does spend 5 BTC directly towards Bob, and he can also claim the 10 BTC settled balance from Alice, but his net balance compared to the t=t3 is -5 BTC. To defend against this kind of attack, it is important to keep track of the maximum the other party has as receiving uncleared payments in his channel. In this case, the maximum Alice has as uncleared receiving payments is at t=t1, 5 BTC. This means, we have to make sure her balance does not drop below 5 BTC anymore. As agreeing on a channel with a payment is a mutual action, Bob can just refuse to accept a new channel transaction, where the balance of Alice would drop below 5 BTC. This rule also serves as an incentive to clear out receiving payments as soon as possible. The party who has sent a payment (Carol in this example) can only remove settle the payment after the receiving party has cleared the payment, and we don?t want the channel to clog.