← Back to team overview

mimblewimble team mailing list archive

Hash preimages, ZKCPs, atomic swaps and HTLC's

 


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

Attachment: signature.asc
Description: PGP signature