Graftroot: Private and efficient surrogate scripts under the taproot assumption

Graftroot: Private and efficient surrogate scripts under the taproot assumption
2018-02-05 15:56 ` Ryan Grant
  
From: Gregory Maxwell @ 2018-02-05  5:58 UTC (permalink / raw)
  To: Bitcoin Dev

In my post on taproot I showed a simple commitment scheme for scripts
that is very efficient that there exists some collection of pubkeys
(like an M-of-N or even N-of-N) whos authorization is an acceptable
alternative to whatever other conditions we might want to impose on a
coin.  If this holds then when spends happen via the plain signature
path the existence of the alternative is never revealed, providing
privacy with improved efficiency compared to not being private at all.

Taproot suffers from a limitation that it only natively provides for
one alternative.  Trees or cascades of taproots can be done, but they
have less privacy and efficiency than just a single level. E.g. a tree
commitment has overhead that grows with the log of the number of
alternatives.

However, under the taproot assumption-- that there exists some
monotone function on plain public keys and nothing else that is
sufficient to authorize a transaction-- we can do even better.

With graftroot, the participants establish a threshold key, optionally
with a taproot alternative, just as they do with taproot.  At any
time, they can delegate their ability to sign to a surrogate script by
signing that script (and just the script) with their taproot key, and
sharing that delegation with whomever they choose.   Later, when it
comes time to spend the coin, if the signers aren't available and the
script must be used,  the redeeming party does whatever is required to
satisfy the script (e.g. provides their own signature and a timelock,
or whatnot)  and presents that information along with the signer's
signature of the script.

The result is that instead of allowing only one alternative an
unlimited number of alternatives can be provided. All are executed
with equal efficiency to a single alternative, and the number of them
is hidden without overhead.  Alternatives can be provided for existing
coins too, without requiring they get moved-- movement is only
required to destroy the ability to use alternatives by changing keys.

Allowing this kind of delegation makes sense because the same signers
could have just signed the transaction outright. The new script simply
stands in for them, if they're not available or cooperating. No
special conditions are needed outside of the surrogate script on when
the surrogate is allowed, because they can be written inside the
surrogate.

We've discussed delegation in script back to at least 2012-- with
speculation that enabling it may have been an original motivation
behind codeseperator. ... but these design discussions have gotten
mired in how to express and connect the levels of delegation.  But the
case where delegation is accomplished with a simple unconditional
signature is an especially simple case, and under the taproot
assumption the only case that is ever needed.

A naive implementation of this idea requires a complete signature
every time a surrogate is used, which means 64 bytes of data (assuming
128 bit ECC). This is higher overhead than taproot.

However,  the non-interactive schnorr aggregation trick[1] can be
applied to merge the S values of all graftroots and signatures in a
transaction into a single aggregate.  With this approach only a single
R value for each graftroot need be published, lowering the overhead to
~32 bytes-- the same as taproot. This has a side benefit of binding
the published grafts to a particular transaction, which might help
avoid some screwups.

In cases where the taproot assumption doesn't hold, taproot can still
be used by setting the public key to a NUMS point, which preserves
privacy (e.g. you can't distinguish txn where the key could never have
been used.)  A similar thing can be done for graftroot if the
signature is not a proof of knowledge (commits to the public key): you
select the signature in a NUMS manner, and then recover the applicable
public key.  Though this can't be done if the signature is a PoK, and
it's probably a pretty good idea to make it a PoK.

The primary limitation of this approach compared to taproot
alternatives and trees is that it requires that anyone who wants to
make use of a particular surrogate to interact with the participants
and store the resulting signature because a single party couldn't
compute it again on their own from public data. For trees and taproot
alternatives, the alternatives can be setup without any interaction
with the participants. The primary advantage is that it scales to any
number of alternatives with small constant overhead, can be delegated
after the fact, and can still be spent by the participants without
overhead.

Summarizing:   A coin's authorizing contract is decomposed into a top
level OR between a monotone function of pubkeys (such as N of N) and
any number of arbitrary surrogate scripts which are acceptable
authorizations.  A key aggregate (see [2]) is formed, and is used to
sign each of the the surrogates.  Participants save these signatures.
Later, when it comes time to spend the coin, if the pubkey holders are
unwilling or unavailable, the spender presents and satisfies the
relevant surrogate along with it's signature R-value and
non-interactively aggregates the S-value into the transaction's
overall aggregate signature.  The result is 0-overhead if the signers
cooperate, or ~32-byte overhead (plus the script) if they don't.  This
avoids the log() overhead of tree based schemes, and allows delegation
to take place before or after the fact but requires storage.  The
potential for unexpected surrogate replay if keys are reused in
foolish ways also needs to be kept in mind, though it may be somewhat
mitigated by aggregation. The existence of unused surrogates is
completely hidden.

I believe this general design is simple and powerful enough that it
avoids the rathole that earlier delegation discussions have suffered.




[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014272.html
And the secure construction at:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014308.html

[2] https://eprint.iacr.org/2018/068


 permalink raw reply	[|nested]
2018-02-05  5:58 [bitcoin-dev] Graftroot: Private and efficient surrogate scripts under the taproot assumption Gregory Maxwell

  2018-02-05 19:58   ` Gregory Maxwell
  
From: Ryan Grant @ 2018-02-05 15:56 UTC (permalink / raw)
  To: Gregory Maxwell, Bitcoin Protocol Discussion

Am I reading correctly that this allows unilateral key rotation (to a
previously unknown key), without invalidating the interests of other
parties in the existing multisig (or even requiring any on-chain
transaction), at the cost of storing the signed delegation?


 permalink raw reply	[|nested]
2018-02-05 15:56 ` Ryan Grant

  2018-02-09  7:29     ` Jeremy
  
From: Gregory Maxwell @ 2018-02-05 19:58 UTC (permalink / raw)
  To: Ryan Grant;  Bitcoin Protocol Discussion

On Mon, Feb 5, 2018 at 3:56 PM, Ryan Grant <bitcoin-dev@rgrant•org> wrote:
> Am I reading correctly that this allows unilateral key rotation (to a
> previously unknown key), without invalidating the interests of other
> parties in the existing multisig (or even requiring any on-chain
> transaction), at the cost of storing the signed delegation?

Yes, though I'd avoid the word rotation because as you note it doesn't
invalidate the interests of any key, the original setup remains able
to sign.  You could allow a new key of yours (plus everyone else) to
sign, assuming the other parties agree... but the old one could also
still sign.


 permalink raw reply	[|nested]
2018-02-05 19:58   ` Gregory Maxwell

  2018-02-09  7:42       ` Jeremy
  2018-02-22 12:19       ` Ryan Grant
  
From: Jeremy @ 2018-02-09  7:29 UTC (permalink / raw)
  To: Gregory Maxwell, Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 1627 bytes --]

This might be unpopular because of bad re-org behavior, but I believe the
utility of this construction can be improved if we introduce functionality
that makes a script invalid after a certain time (correct me if I'm wrong,
I believe all current timelocks are valid after a certain time and invalid
before, this is the inverse).

Then you can exclude old delegates by timing/block height arguments, or
even pre-sign delegates for different periods of time (e.g., if this
happens in the next 100 blocks require y, before the next 1000 blocks but
after the first 100 require z, etc).



--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>

On Mon, Feb 5, 2018 at 11:58 AM, Gregory Maxwell via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> On Mon, Feb 5, 2018 at 3:56 PM, Ryan Grant <bitcoin-dev@rgrant•org> wrote:
> > Am I reading correctly that this allows unilateral key rotation (to a
> > previously unknown key), without invalidating the interests of other
> > parties in the existing multisig (or even requiring any on-chain
> > transaction), at the cost of storing the signed delegation?
>
> Yes, though I'd avoid the word rotation because as you note it doesn't
> invalidate the interests of any key, the original setup remains able
> to sign.  You could allow a new key of yours (plus everyone else) to
> sign, assuming the other parties agree... but the old one could also
> still sign.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 2983 bytes --]

 permalink raw reply	[|nested]
2018-02-09  7:29     ` Jeremy

  2018-02-22 12:19       ` Ryan Grant
  
From: Jeremy @ 2018-02-09  7:42 UTC (permalink / raw)
  To: Jeremy;  Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 2222 bytes --]

I'm also highly interested in the case where you sign a delegate
conditional on another delegate being signed, e.g. a bilateral agreement.

In order for this to work nicely you also need internally something like
segwit so that you can refer to one side's delegation by a signature-stable
identity.

I don't have a suggestion of a nice way to do this at this time, but will
stew on it.

--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>

On Thu, Feb 8, 2018 at 11:29 PM, Jeremy <jlrubin@mit•edu> wrote:

> This might be unpopular because of bad re-org behavior, but I believe the
> utility of this construction can be improved if we introduce functionality
> that makes a script invalid after a certain time (correct me if I'm
> wrong, I believe all current timelocks are valid after a certain time and
> invalid before, this is the inverse).
>
> Then you can exclude old delegates by timing/block height arguments, or
> even pre-sign delegates for different periods of time (e.g., if this
> happens in the next 100 blocks require y, before the next 1000 blocks but
> after the first 100 require z, etc).
>
>
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
> <https://twitter.com/JeremyRubin>
>
> On Mon, Feb 5, 2018 at 11:58 AM, Gregory Maxwell via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>> On Mon, Feb 5, 2018 at 3:56 PM, Ryan Grant <bitcoin-dev@rgrant•org>
>> wrote:
>> > Am I reading correctly that this allows unilateral key rotation (to a
>> > previously unknown key), without invalidating the interests of other
>> > parties in the existing multisig (or even requiring any on-chain
>> > transaction), at the cost of storing the signed delegation?
>>
>> Yes, though I'd avoid the word rotation because as you note it doesn't
>> invalidate the interests of any key, the original setup remains able
>> to sign.  You could allow a new key of yours (plus everyone else) to
>> sign, assuming the other parties agree... but the old one could also
>> still sign.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>

[-- Attachment #2: Type: text/html, Size: 4702 bytes --]

 permalink raw reply	[|nested]
2018-02-09  7:29     ` Jeremy
  2018-02-09  7:42       ` Jeremy

  2018-02-22 19:44         ` Daniel Edgecumbe
  2018-06-30 11:49         ` Sjors Provoost
  
From: Ryan Grant @ 2018-02-22 12:19 UTC (permalink / raw)
  To: Jeremy;  Bitcoin Protocol Discussion

On Fri, Feb 9, 2018 at 7:29 AM, Jeremy <jlrubin@mit•edu> wrote:
> utility of this construction can be improved if we introduce functionality
> that makes a script invalid after a certain time

Tagging this thread with "nExpiryTime".  Search archives for more.


 permalink raw reply	[|nested]
2018-02-22 12:19       ` Ryan Grant

  2018-02-24 18:58           ` Gregory Maxwell
  2018-06-30 11:49         ` Sjors Provoost
  
From: Daniel Edgecumbe @ 2018-02-22 19:44 UTC (permalink / raw)
  To: bitcoin-dev

> However,  the non-interactive schnorr aggregation trick[1] can be
applied to merge the S values of all graftroots and signatures in a
transaction into a single aggregate.  With this approach only a single
R value for each graftroot need be published, lowering the overhead to
~32 bytes-- the same as taproot. This has a side benefit of binding
the published grafts to a particular transaction, which might help
avoid some screwups.

I don't think that binding grafts to a particular transaction requires this aggregation.
It seems to me that you could just sign H(txid, script) rather than H(script).
I'm not aware of whether this would break aggregation.

---
Daniel Edgecumbe / esotericnonsense
esotericnonsense@esotericnonsense•com
https://esotericnonsense.com
https://danedgecumbe.com


 permalink raw reply	[|nested]
2018-02-22 19:44         ` Daniel Edgecumbe

  
From: Gregory Maxwell @ 2018-02-24 18:58 UTC (permalink / raw)
  To: Daniel Edgecumbe, Bitcoin Protocol Discussion

On Thu, Feb 22, 2018 at 7:44 PM, Daniel Edgecumbe via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> I don't think that binding grafts to a particular transaction requires this aggregation.
> It seems to me that you could just sign H(txid, script) rather than H(script).
> I'm not aware of whether this would break aggregation.


That would require that you know the txid in advance. Sometimes you
do-- and a graftroot sighash flag could handle that... but usually you
wouldn't.  The case where you already do know it can sort of be
covered today without using the graftroot:  Sign a transaction
spending the multisig coin to the graft.  This isn't a strict
alternative however, because it's not atomic: you could imagine that
txn being announced and then the graft not being spent, while someone
would like to spend a different graft.  That non-atomiticity could be
addressed by making the graft spends an OR of all the other graft
spends but that isn't scalable or private.  Regardless, still doesn't
work if the graft isn't created after the fact.

The aggregation bit has the property of working just in time, even on
grafts created in advance.


 permalink raw reply	[|nested]
2018-02-22 12:19       ` Ryan Grant
  2018-02-22 19:44         ` Daniel Edgecumbe

  
From: Sjors Provoost @ 2018-06-30 11:49 UTC (permalink / raw)
  To: Ryan Grant, Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 641 bytes --]


> Op 22 feb. 2018, om 13:19 heeft Ryan Grant via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> het volgende geschreven:
> 
> On Fri, Feb 9, 2018 at 7:29 AM, Jeremy <jlrubin@mit•edu> wrote:
>> utility of this construction can be improved if we introduce functionality
>> that makes a script invalid after a certain time
> 
> Tagging this thread with "nExpiryTime".  Search archives for more.

Fill-or-kill transaction was the term used on the list:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/011042.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/011042.html>

Sjors

[-- Attachment #2: Type: text/html, Size: 1344 bytes --]

 permalink raw reply	[|nested]