| Thread Previous • Date Previous • Date Next • Thread Next |
On Mon, Jan 23, 2017 at 08:39:28PM +0100, Ruben Somsen wrote:
> 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.
>
Thanks Ruben. This is an excellent summary of where we stand compared to
systems like Bitcoin or Ethereum. I think it's possible to extend to pretty
much any script functionality (though I don't want to, absent any good
blockchain script languages right now) except for these two limitations.
>
> 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.
>
I don't think your workaround is workable because the only thing that remains
in the chain is the excess value, which has no amount associated with it, and
doesn't really have well-defined coins to destroy and recreate.
Right now this appears to be a fundamental limitation of MimbleWimble. I'm
curious though if there are any serious usecases out there that don't use
the multisigner intermediate stage. It seems even Bitcoin has this stage
so that it can have a locktimed "if somebody bails the protocol reverts"
mechanism.
An exciting difference in MW is that the two branches "revert after locktime"
and "move forward" don't appear in the chain as a script with a branch, the
branches are constructed as conflicting transactions and only one winds up
in the chain. This is like super-MAST and I need to think more to figure
out the consequences of it.
For sidechain stuff we'd want to have a separate Merkle root with incoming
and outgoing coins, and this root would not have deletable data. At least,
that's my current thinking. Same for multi-asset issuance or deissuance.
>
> 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.
>
I haven't yet studied this in detail but I think it works. This is really
cool. I mentioned above that there aren't any good blockchain script
languages out there, but this seems to be a very active area of research.
My feeling is that we should ensure that any future MW script has support
for triggers, but for now we probably shouldn't try to hack them in, given
that we can support a(n inefficient) version of Lightning without them,
where channels always have an expiry date on them.
>
> 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.
>
I'm pretty sure the excess is exactly what we want. Because an excess value
is a multisigning key this also gives fine access control as to who can
create triggers: any monotonic function can be represented as a single
Schnorr signature key, as long as all parties are around at setup time.
> 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.
>
Agreed, I think we want to copy Bitcoin's attitude of "transactions, once
valid, never stop being valid" although the reverse is allowable.
> 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.
Thanks very much for the credit. I think this trigger thing is huge, you've
identified the two problems I had remaining with a more expressive MW, and
you solved the one that I think really mattered. This is awesome.
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
| Thread Previous • Date Previous • Date Next • Thread Next |
