mimblewimble team mailing list archive

[Ruben Somsen <rsomsen@xxxxxxxxx>]

In bitcoin you can restrict an output with scripts, in Mimblewimble this is
impossible because the inputs and outputs are unlinked. However, we can
restrict a transaction from entering the blockchain until certain
conditions are met by including a script in the signature, as Andrew
Poelstra demonstrated with locktime and more recently hash locks [1].

This has a few limitations compared to bitcoin:

1. Signature reissuance: The owner of the UTXO can reissue a new signature
at any time, bypassing the restrictions of the script

2 Lack of position: Conditions that require the script to already have a
position on the blockchain cannot be replicated (e.g. OP_CSV locking the
output relative to the block it’s in [2])

These seem problematic, but if we can maneuver around them, we should be
able to replicate more scripting functionality in Mimblewimble. So let’s
examine the two points.


1. Signature reissuance

Scripts are meant to restrict how money can be spent. If you wish to
restrict yourself, the solution is simply to sign a transaction with the
desired script and throw away the key. The only difference here is that you
can’t prove key deletion to others.

If you wish to restrict your payment to a specific user (or users), the
solution is to use 2 of 2 (or more) multisig. You lock up your funds with
the intended recipient, and from there you sign another transaction to the
recipient with the desired script. You can’t take back your payment because
the funds were locked up, and the recipient won’t receive the funds until
they satisfy the requirement of the script. The only difference here is
that you retain the ability to remove the script at a later time.

If you wish to restrict a payment to an unknown future party (e.g. locking
coins for extension blocks or sidechains), none of the above works. Perhaps
this can be worked around by destroying the coins and allowing miners to
recreate them under specific conditions, but this still needs to be worked
out further.


2. Lack of position

We can’t use the position of the script itself, since it won’t enter the
blockchain until after it has been validated. However, we can use other
‘triggers’ instead: simply point to other data on the blockchain (or data
that will be published at a later date) and use that position instead. As
the name implies, the data acts as a trigger to the validity of the
transaction.

A simplified example: transaction A is only valid if a trigger in the form
of transaction B is in the blockchain and buried under 3 days of work. Note
how only the owner of transaction B had the ability to publish this
trigger. It is more versatile than relative locktime in bitcoin and can
serve the same function as HLTCs for Lightning [3].


Now that we have defined some workarounds for the scripting limitations in
Mimblewimble, we should be able to construct more scripts, including a
feature complete Lightning Network (i.e. bidirectional channels that don’t
expire, which was not possible before):

Tx A: 2 of 2 multisig between Alice and Bob on the mimwim blockchain

Tx B: spending tx A to refund Alice, transaction only valid if:
- Trigger 1 is on the blockchain (publishable by both Alice and Bob) and
- 3 days (counted in blocks) have passed since trigger 1 appeared (relative
locktime)

The channel is now ready for use and Alice publishes tx A, since she’s is
guaranteed to get her money back if Bob disappears. It won’t expire unless
trigger 1 gets published.

Tx C: spending tx A to send money from Alice to Bob, only valid if:
-  Trigger 1 AND trigger 2 (only publishable by Bob) are on the blockchain
and
- 1 day has passed for both (to allow room for invalidation, but before
refund tx B)

Now if Bob ever wants to pay Alice (reversing the direction of the
channel), tx C needs to be invalidated by disincentivizing Bob from ever
publishing trigger 2. Bob can do this by giving Alice the following
transaction:

Tx D: spending tx A to send ALL the money to Alice, only valid if:
- Trigger 2 is on the blockchain (no locktime needed)

If the channel is closed cooperatively, you simply spend tx A. This means
that tx B, C, D the trigger transactions, and all the related scripts won’t
need to go on the blockchain.


What has not yet been discussed, is specifically what data to use as
triggers. I don’t consider myself qualified enough to evaluate what would
be the best method, but I believe one way would be to refer by hash to a
certain excess value, since this is essentially a commitment to a unique
random number.

A privately shared early draft of the triggers proposal also included
triggers that invalidate transactions, but that has a number of issues and
probably isn’t needed for most cases.

A large part of this post consists of observations that were made
previously by Andrew Poelstra, who deserves most of the credit. The only
original idea to my knowledge is the use of triggers and how it can be used
to create a feature complete Lightning Network. I'm new to making
contributions in the field, so I do not expect this to be without flaws
(perhaps even fatal ones). Any feedback or comments are greatly appreciated.


Cheers,
Ruben Somsen




[1]
https://www.mail-archive.com/mimblewimble@xxxxxxxxxxxxxxxxxxx/msg00021.html

[2] https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki

[3]
https://en.bitcoin.it/wiki/Hashed_Timelock_Contracts#HTLCs_in_payment_channels