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
> power
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 s
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 in
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 sing
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 observe
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 tr
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
> t
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
f
> 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 context
>> of this question first a bit more to avoid getting into the weeds too
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
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
>
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
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 accou
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 this:
Are there any useful applications
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 strong
> reasons why this would
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 intent of this particular
> P2SH address
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 spending
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 o
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 why
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 disa
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
21 matches
Mail list logo