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

On Thu, May 31, 2018 at 05:25:04PM -0700, Pieter Wuille via bitcoin-dev wrote: > The best argument for why Graftroot does not need to be optional I > think was how Greg put it: "since the signer(s) could have signed an > arbitrary transaction instead, being able to delegate is strictly less >

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

Good morning Greg, > On Wed, Jun 20, 2018 at 12:12 PM, ZmnSCPxj via bitcoin-dev > > bitcoin-dev@lists.linuxfoundation.org wrote: > > > This has the advantage that the Graftroot signature commits to a single > > outpoint and cannot be used to spend all outpoints that happen to pay to > > the

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

On Wed, Jun 20, 2018 at 12:12 PM, ZmnSCPxj via bitcoin-dev wrote: > This has the advantage that the Graftroot signature commits to a single > outpoint and cannot be used to spend all outpoints that happen to pay to the > same `P` public key. If it isn't possible to make a graftroot signature

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

Good morning Pieter and Tim and all, My understanding is that the idea now being discussed by Pieter and Tim is that the Graftroot signature is not `sign(P, script)` but instead `sign(P, sighash(tx))`, where `tx` is an "ordinary" transaction that spends the outpoint that pays to `P`, and a

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

What you're saying makes sense. By the way, an even stronger reason why you shouldn't be able to "repurpose" just a Graftroot signature as a transaction: You may want to reveal to others that you've delegated. But if an observer sees the delegation (literally the Graftroot signature), this

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

On Wed, Jun 6, 2018 at 5:48 AM, Tim Ruffing via bitcoin-dev wrote: > On Thu, 2018-05-31 at 17:25 -0700, Pieter Wuille via bitcoin-dev wrote: >> The best argument for why Graftroot does not need to be optional I >> think was how Greg put it: "since the signer(s) could have signed an >> arbitrary

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

I haven't read the original Graftroot thread, so maybe all of this has b een discussed already or is just wrong... Please correct me if this is the case. On Thu, 2018-05-31 at 17:25 -0700, Pieter Wuille via bitcoin-dev wrote: > The best argument for why Graftroot does not need to be optional I >

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

On Fri, May 25, 2018 at 3:14 AM, Johnson Lau wrote: > A graftroot design like this is a strict subset of existing signature > checking rules. If this is dangerous, the existing signature checking rules > must be dangerous. While you may be right in this situation, I'm not sure that conclusion

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

> On 24 May 2018, at 10:08 AM, Gregory Maxwell via bitcoin-dev > wrote: > > On Thu, May 24, 2018 at 1:58 AM, Pieter Wuille via bitcoin-dev > wrote: >> Thanks everyone who commented so far, but let me clarify the

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

While you have rescind your concern, I’d like to point out that it’s strictly a problem of SIGHASH_NOINPUT, not graftroot (or script delegation in general). For example, we could modify graftroot. Instead of signing the (script), we require it to sign (outpoint | script). That means a graftroot

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

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

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

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

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

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,

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

On Thu, May 24, 2018 at 1:58 AM, Pieter Wuille via bitcoin-dev wrote: > Thanks everyone who commented so far, but let me clarify the context > of this question first a bit more to avoid getting into the weeds too > much. My understanding of the question is

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

On Tue, May 22, 2018 at 11:17 AM, Pieter Wuille wrote: > Hello all, > > Given the recent discussions about Taproot [1] and Graftroot [2], I > was wondering if a practical deployment needs a way to explicitly > enable or disable the Graftroot spending path. I have no

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

On Wed, May 23, 2018 at 10:06 PM, Natanael via bitcoin-dev wrote: > Consider for example a P2SH address for some fund, where you create a > transaction in advance. Even if the parties involved in signing the > transaction would agree (collude), the original

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

Den tis 22 maj 2018 20:18Pieter Wuille via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> skrev: > Hello all, > > Given the recent discussions about Taproot [1] and Graftroot [2], I > was wondering if a practical deployment needs a way to explicitly > enable or disable the Graftroot

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

On Wed, May 23, 2018 at 01:50:13PM +, Andrew Poelstra via bitcoin-dev wrote: > > Graftroot also break blind signature schemes. Consider a protocol such as [1] > where some party has a bunch of UTXOs all controlled (in part) by the same > key X. This party produces blind signatures on receipt

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

On Tue, May 22, 2018 at 11:17:42AM -0700, Pieter Wuille via bitcoin-dev wrote: > > Given the recent discussions about Taproot [1] and Graftroot [2], I > was wondering if a practical deployment needs a way to explicitly > enable or disable the Graftroot spending path. I have no strong > reasons

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

Good morning Pieter and list, It seems to me, naively, that it would be better to make Graftroot optional, and to somehow combine Taproot and Graftroot. So I propose that the Taproot equation be modified to the below: Q = P + H(P, g, S) * G Where `g` is the "Graftroot flag", i.e. 0 if

[bitcoin-dev] Should Graftroot be optional?

Hello all, Given the recent discussions about Taproot [1] and Graftroot [2], I was wondering if a practical deployment needs a way to explicitly enable or disable the Graftroot spending path. I have no strong reasons why this would be necessary, but I'd like to hear other people's thoughts. As a