From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 1ED6F12 for ; Thu, 24 May 2018 09:44:31 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm0-f44.google.com (mail-wm0-f44.google.com [74.125.82.44]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 253B76C8 for ; Thu, 24 May 2018 09:44:30 +0000 (UTC) Received: by mail-wm0-f44.google.com with SMTP id o78-v6so3381369wmg.0 for ; Thu, 24 May 2018 02:44:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=REaGpRIELaUiq0uTR+CvpPtu6yn00fN1xY+VFiwZwOk=; b=Drtvu5GpheGdsuwi04Rx0oPMM3hdvq8ACjzhoL0lSQYPH+9ETmRPjRf6FhnyPMtj7C bX6Iid0louBGQZtvgbSNtyOJnCVsftPK2RAgBYvTctEgxJGyo3/T1J1zXjmlzladIk+U uGz6jGaF9EALn0tRRnPmXBko3tkrTrZBAySzF3SBAoDPX2DoD2TuVhxZ1R9U7bsTUw96 jhUtQOjIL9yjabnrAIeSUVdRFSEdxhIv1++Md5NiTbQwNnCFFfdYmlrQJPdFT2/VW5He VqFz5aEZ+rVbjqye/tP3DPjNuqrxt4kzk5qup2QEn8bpSi7d8LqnO02xert2hGpL5Ofe B+ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=REaGpRIELaUiq0uTR+CvpPtu6yn00fN1xY+VFiwZwOk=; b=ouppzgzyw380DJWq914vBYQaFqtVhJbSLTlCV3rU/pQPTwCBvoNYcLWwePPNIdmkjq tGcSblFWSRQOS/EMoY2VEiixCGmCvltnjO8Z0CITpr8stC+T2esCANT/IK6oBJAu+81R NT0MOOWxj1u3b9iUtn0nTbhgHYmipVvJU8oRa/oXDIcX5Ea73mBb0V67oc8R5DIXupe8 V7lH3wJJ1karx3/GwUjlSkII2KujxMH1wLkbf3ZFacpKj/y9R62DkWmaujuOzzR1oZds gLD2YXFKh3CNDcHzSL2nE2IQPPpMAfMI8zBaqYRM1p3Gb1PODv67MlOKjzA4ttvmH2X+ bY4A== X-Gm-Message-State: ALKqPwdN5RcxUUE8JnbvUlxA3uG8wKF8tkMdem5n/iKMIfoSBon/TTw3 9KMRZ9/WPLLuFJtxm118RnaydsUOpoOr+lXvlys= X-Google-Smtp-Source: AB8JxZqx2kh71y6SHq29SBicRUIbJIVDCuLKJDxm4XkWVuHLoNcz8gmSn/Zso1XI8Tj11WftI1K+bAfFUlEo9iWDZhY= X-Received: by 2002:a50:ed92:: with SMTP id h18-v6mr11498095edr.102.1527155068798; Thu, 24 May 2018 02:44:28 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Natanael Date: Thu, 24 May 2018 11:44:16 +0200 Message-ID: To: Gregory Maxwell , Bitcoin Dev Content-Type: multipart/alternative; boundary="000000000000648c96056cf07ff2" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Should Graftroot be optional? X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2018 09:44:31 -0000 --000000000000648c96056cf07ff2 Content-Type: text/plain; charset="UTF-8" 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. > --000000000000648c96056cf07ff2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


= 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":=C2=A0 since the signer(s) could have signed an ar= bitrary
transaction instead, being able to delegate is strictly less powerful.
Moreover, absent graftroot they could always "delegate" non-atomi= cally
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 m= y argument here is simply that in many cases, not all stakeholders in a tra= nsaction will hold one of the private keys required to sign. And such stake= holders would want a guarantee that the original script is followed as prom= ised.=C2=A0

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.=C2=A0

I'm not concerned by the ability to move funds to an addres= s with the new rules that you'd otherwise graftroot in, only that you c= an 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.=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
--000000000000648c96056cf07ff2--