mimblewimble team mailing list archive

Hash preimages, ZKCPs, atomic swaps and HTLC's

To : mimblewimble@xxxxxxxxxxxxxxxxxxx

: mimblewimble@xxxxxxxxxxxxxxxxxxx From : Andrew Poelstra <apoelstra@xxxxxxxxxxxxxx>

: Andrew Poelstra <apoelstra@xxxxxxxxxxxxxx> Date : Tue, 17 Jan 2017 21:57:18 +0000

: Tue, 17 Jan 2017 21:57:18 +0000 Cc : Ethan Heilman <ethan.r.heilman@xxxxxxxxx>

: Ethan Heilman <ethan.r.heilman@xxxxxxxxx> User-agent: Mutt/1.7.1 (2016-10-04)

I met recently with Ethan Heilman and a few other people and we realized how to get hash preimages into MimbleWimble, as well as some other tricks, in a way that should let us get a lot of Bitcoin's power into the MW system. The required changes to MW are very small and in my corner of the world (specifically the Schnorr signatures on the excess values). This maybe ought to be a full paper with more detail, but I'll type out the ideas here for commentary and suggestions. 0. Proposed Change The proposed change is that the message that the excess value signs is e || L, where e is either the empty string (default) or a hash whose preimage must be provided, and L is either the empty string (default) or a locktime which must be provided. If the locktime is present, the excess value is not allowed to be included in any block whose height is less than the locktime. The locktime idea has been around since the dawn of MimbleWimble, but the hash preimage is new. The idea is that it's possible to produce a signature knowing only e = H(m), but to complete the transaction it's required to know m. Since both the preimage of e, and L, have to be stored in the blockchain forever, we should cap their length at 32 or 40 bytes or something. TBD. Maybe have no consensus-cap except the blocksize limit, and use standardness rules to effectively lower it, like Bitcoin does, Just In Case there are future extensions that might want a longer preimage. I dunno. 0.33. Multisigned Transactions There are a few ways that sender and receiver can communicate to produce a MW transaction. For this I'm going to assume that they are willing to interact: each produces half the transaction and the total transaction's excess value will be the sum of the two halves' excess values. The excess signature can be produced as an interactive Schnorr signature. 0.67. Hash-Locktimed transactions Suppose that I want to send a Bitcoin to Igno conditioned on him revealing a hash preimage. He sends me the hash e. We do the following. 1. I send the coins to a multisignature output controlled by the 2-of-2 of both of us, though I don't complete my half of signing the resulting excess value. 2. Igno produces a transaction that sends the coins back to me, locktimed to some time in the future; we complete this transaction. (Well, Igno does his part and I can do mine later.) 2a. I broadcast the first transaction, so there are coins on the chain that can be spent only with both our our consents. 3. I produce a transaction which sends these coins to Igno. With the excess I sign the hash e, leave the locktime blank, and do my part to sign. At this point Igno can either (a) complete the transaction, doing his part of the signature and revealing the preimage to the network, including me; or (b) do nothing, in which case I'll take the coin back after the lock time. Ok, this is a neat primitive. Here's what we can do with it: 1. Zero-Knowledge Contingent Payments Recall ZKCP, as written up here https://bitcoincore.org/en/2016/02/26/zero-knowledge-contingent-payments-announcement/ In this case, Igno produces a zero-knowledge proof that the hash preimage will decrypt the solution to some problem I care about. He gives me the encrypted solution and the hash and the proof, then we do the above exchange to trade the preimage for money. 2. Cross-chain atomic swaps. On another chain, Igno sends coins to me that I can only redeem by revealing a hash preimage (which he knows, I don't). On the MW chain we do this exchange so that Igno can take my coins by revealing the preimage. When he takes his coins, he reveals it, enabling me to take my coins. Note that this requires both chains to support hash preimages: all Bitcoin script derivatives, Ethereum, and now Mimblewimble support this. 3. Lightning I talked with Thaddeus Dryja just now and showed him down to do locktime and hash preimages, and he said this should be sufficient to create HTLC's (hash- timelocked lightning channels), so I guess this gives us full lightning support in principle. I don't really know how HTLC's work, but this matches my understanding :). These are the examples that I usually have in mind when I think about hash preimages ... I'm curious what other Bitcoin script applications there are, and whether there's anything more we need to support them. Cheers Andrew -- Andrew Poelstra Mathematics Department, Blockstream Email: apoelstra at wpsoftware.net Web: https://www.wpsoftware.net/andrew "A goose alone, I suppose, can know the loneliness of geese who can never find their peace, whether north or south or west or east" --Joanna Newsom