Re: [bitcoin-dev] Should Graftroot be optional?

[Andrew Poelstra via bitcoin-dev]

On Thu, May 24, 2018 at 11:44:16AM +0200, Natanael via bitcoin-dev wrote:
> 
> As stated above by Wuille this seems to not be a concern for typical P2SH
> uses, but my argument here is simply that in many cases, not all
> stakeholders in a transaction will hold one of the private keys required to
> sign. And such stakeholders would want a guarantee that the original script
> is followed as promised.
>

In this case, even mandatory graftroot would not allow the signing stakeholders
to take the coins. The reason is that if there are _any_ non-signing script
conditions that must be followed, then to use Taproot the top-level public key
needs to be unusable, e.g. by being a NUMS point. In that case the public key
would also be unusable for Graftroot.

Another way to see this is -- in any context where Graftroot seems dangerous,
there needs to be a reason why the ability to just create transactions is not
dangerous. In your example it seems that the signing parties can just take
the coins with or without Graftroot, so the problem is not in Graftroot but
in the way that the example is set up.
 
> I'm not concerned by the ability to move funds to an address with the new
> rules that you'd otherwise graftroot in, only that you can provide a
> transparent guarantee that you ALSO follow the original script as promised.
> What happens *after* you have followed the original script is unrelated,
> IMHO.
>

To do this in Taproot you need to disable the top-level key, which will also
disable Graftroot. 

-- 
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



signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Should Graftroot be optional?

[Natanael via bitcoin-dev]

Den tor 24 maj 2018 04:08Gregory Maxwell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> skrev:

>
> My understanding of the question is this:
>
> Are there any useful applications which would be impeded if a signing
> party who could authorize an arbitrary transaction spending a coin had
> the option to instead sign a delegation to a new script?
>
> The reason this question is interesting to ask is because the obvious
> answer is "no":  since the signer(s) could have signed an arbitrary
> transaction instead, being able to delegate is strictly less powerful.
> Moreover, absent graftroot they could always "delegate" non-atomically
> by spending the coin with the output being the delegated script that
> they would have graftrooted instead.
>
> Sometimes obvious answers have non-obvious counter examples, e.g.
> Andrews points related to blindsigning are worth keeping in mind.
>

As stated above by Wuille this seems to not be a concern for typical P2SH
uses, but my argument here is simply that in many cases, not all
stakeholders in a transaction will hold one of the private keys required to
sign. And such stakeholders would want a guarantee that the original script
is followed as promised.

I agree that such flags typically wouldn't have a meaningful effect for
funds from non-P2SH addresses, since the entire transaction / script could
be replaced by the very same keyholders.

I'm not concerned by the ability to move funds to an address with the new
rules that you'd otherwise graftroot in, only that you can provide a
transparent guarantee that you ALSO follow the original script as promised.
What happens *after* you have followed the original script is unrelated,
IMHO.

>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Should Graftroot be optional?

[Natanael via bitcoin-dev]

Den tor 24 maj 2018 01:45Gregory Maxwell  skrev:

> I am having a bit of difficulty understanding your example.
>
> If graftroot were possible it would mean that the funds were paid to a
> public key.  That holder(s) of the corresponding private key could
> sign without constraint, and so the accoutability you're expecting
> wouldn't exist there regardless of graftroot.
>
> I think maybe your example is only making the case that it should be
> possible to send funds constrained by a script without a public key
> ever existing at all.  If so, I agree-- but that wasn't the question
> here as I understood it.
>

I have to admit I not an expert on this field, so some of my concerns might
not be relevant. However, I think Wuille understood my points and his reply
answered my concerns quite well. I'm only asking for the optional ability
to prove you're not using these constructions (because some uses requires
committing to an immutable script), and that already seems to exist. So for
the future implementations I only ask that this ability is preserved.

I think such a proof don't need to be public (making such a proof in
private is probably often better), although optionally it might be. A
private contract wouldn't publish these details, while a public commitment
would do so.

>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev