path: root/45/7287f3d00e017b0c44db7c6fb212178b9bdc7f

Return-Path: <jim.posen@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id D48EFE0C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 15 Mar 2018 06:43:23 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-it0-f47.google.com (mail-it0-f47.google.com
	[209.85.214.47])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 13E5237D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 15 Mar 2018 06:43:23 +0000 (UTC)
Received: by mail-it0-f47.google.com with SMTP id u5-v6so7816527itc.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 14 Mar 2018 23:43:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc; bh=oC/ozUT1mXx6VOoG3IUQzwnQlLAmNtK4rbmojbl64uY=;
	b=Ad2y3JkZoNTV1W/JiQbyUMzfvU54IWaHGs2IjXt8I8LueUyAc5QlZrQO9/5r91SuXs
	LtgtsmQBCBbCTV3y03n3eKy7sy/IxhQie4wB/JmxmCmDaSAWw1523uGm/M06Yc0BOYHF
	9amCfr17esbnWklWBPmEdDLScr5ilePR8pOiArojZcWfn7mt3C0za/U5rulEa/LyUA5U
	N762lSiFG0G9iObNEDWmCP4jp9jmmKNpeXbKB3K3HNqRzjVh4AFMQUf4SICl7sRXE833
	yvQ/S3/kQgVrJadpxZDKqA2R/nNkKi1XadObyEB/PHMFNzyEeWvl9VgktebK3xDzo1lY
	cXjw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc;
	bh=oC/ozUT1mXx6VOoG3IUQzwnQlLAmNtK4rbmojbl64uY=;
	b=XYHx7bMbeLJPYbRAqNFJM+a9Bt0BIfw1wHmdJFUyND5b80lw3+0/HxYYFpZVzVJCg8
	Iw870MoyuKugwbPKBJSTLmTIhlU3wM3sDiYzISw7t5lwqgO3kLEO2cMzXu79U7ibBNqy
	z0MtdgftjzWTM7+Q9ZTuBAjUqoaJl6AHIMsuQPSp6/9ZpLIy/iNliGUOnnBeAUgul3wO
	Wsj4Xsbea8MdSR/5a+QeQVQCGref18ZeXfVKXcYCgWP67Ke76QonLv8zoxYNfz0N4u7z
	Rrp2aWBRIJGN+tyzhKbwwZYPBaybs7Sto4ldTXU4W1He8ZGF7x27z2cxo4f+a2oM+3MD
	Mk6A==
X-Gm-Message-State: AElRT7G3I54LUtvKo5dqYnhhMagHlkqRA9VTF9w0fM9Gl7hjaWdGZfi4
	NBPhl6CiipY9jarY3b5XroaN6DPMckqePVUCdAk=
X-Google-Smtp-Source: AG47ELv+Dx6tsueaDOgOmz9q4nCVjt2b9XhtrXUMtwoPhOXgoNEkwXxUaiU9/9C5C9+fjCpM4RKtlu8P/muUDOKV1gY=
X-Received: by 2002:a24:5913:: with SMTP id
	p19-v6mr1897275itb.80.1521096202217; 
	Wed, 14 Mar 2018 23:43:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.90.16 with HTTP; Wed, 14 Mar 2018 23:43:21 -0700 (PDT)
In-Reply-To: <CALJw2w719qQnyvaJbe1wc39+4ERDST+zXCOjt0DiJpktD74QCA@mail.gmail.com>
References: <CALJw2w5=g-FL+MZ08DEoLxVzOKbSXeKu50drE1b4P0JZJpdTyA@mail.gmail.com>
	<CAPswA9xuVT74L87QO9TXGc6=O6Gd2kbQMBdmn=7zUm5OHXcfOA@mail.gmail.com>
	<CALJw2w719qQnyvaJbe1wc39+4ERDST+zXCOjt0DiJpktD74QCA@mail.gmail.com>
From: Jim Posen <jim.posen@gmail.com>
Date: Wed, 14 Mar 2018 23:43:21 -0700
Message-ID: <CADZtCSiSCDb1dzLCgr24jCNzzmcfsXuPyNVh+YJJ6rNqdsQh2Q@mail.gmail.com>
To: Karl Johan Alm <karljohan-alm@garage.co.jp>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000cd71ce05676dce51"
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
X-Mailman-Approved-At: Thu, 15 Mar 2018 12:53:35 +0000
Subject: Re: [bitcoin-dev] {sign|verify}message replacement
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Mar 2018 06:43:23 -0000

--000000000000cd71ce05676dce51
Content-Type: text/plain; charset="UTF-8"

I like this proposal, it seems sufficiently general.

How are scripts with OP_CLTV and OP_CSV handled by verifiers? Do they
always succeed? Or should an nLockTime and nSequence also be included in
the proof in a way that can be parsed out and displayed to verifiers?

I assume any signatures in the scriptSig/witness data would have no sighash
type?

On Wed, Mar 14, 2018 at 8:01 PM, Karl Johan Alm via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Wed, Mar 14, 2018 at 5:46 AM, Kalle Rosenbaum <kalle@rosenbaum.se>
> wrote:
> > I can't really see from your proposal if you had thought of this: A soft
> > fork can make old nodes accept invalid message signatures as valid. For
> > example, a "signer" can use a witness version unknown to the verifier to
> > fool the verifier. Witness version is detectable (just reject unknown
> > witness versions)  but there may be more subtle changes. Segwit was not
> > "detectable" in that way, for example.
> >
> > This is the reason why I withdrew BIP120. If you have thought about the
> > above, I'd be very interested.
>
> I'm not sure I see the problem. The scriptPubKey is derived directly
> from the address in all cases, which means the unknown witness version
> would have to be committed to in the address itself.
>
> So yeah, I can make a P2SH address with a witness version > 0 and a to
> me unknown pubkey and then fool you into thinking I own it, but I
> don't really see why you'd ultimately care. In other words, if I can
> SPEND funds sent to that address today, I can prove that I can spend
> today, which is the purpose of the tool, I think.
>
> For the case where the witness version HAS been upgraded, the above
> still applies, but I'm not sure it's a big issue. And it doesn't
> really require an old node. I just need to set witness version >
> current witness version and the problem applies to all nodes.
>
> On Wed, Mar 14, 2018 at 8:36 AM, Luke Dashjr <luke@dashjr.org> wrote:
> > I don't see a need for a new RPC interface, just a new signature format.
>
> All right.
>
> > Ideally, it should support not only just "proof I receive at this
> address",
> > but also "proof of funds" (as a separate feature) since this is a popular
> > misuse of the current message signing (which doesn't actually prove
> funds at
> > all). To do this, it needs to be capable of signing for multiple inputs.
>
> I assume by inputs you mean addresses/keys. The address field could
> optionally be an array. That'd be enough?
>
> > Preferably, it should also avoid disclosing the public key for existing
> or
> > future UTXOs. But I don't think it's possible to avoid this without
> something
> > MAST-like first. Perhaps it can be a MAST upgrade later on, but the new
> > signature scheme should probably be designed with it in mind.
>
> I'd love to not have to reveal the public key, but I'm not sure how it
> would be done, even with MAST.
>
> On Wed, Mar 14, 2018 at 12:12 PM, Anthony Towns <aj@erisian.com.au> wrote:
> > Wouldn't it be sufficient for old nodes to check for standardness of the
> spending script and report non-standard scripts as either invalid outright,
> or at least highly questionable? That should prevent confusion as long as
> soft forks are only making nonstandard behaviours invalid.
>
> That seems sensible to me. A warning would probably be useful, in case
> the verifier is running old software.
>
> -Kalle.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--000000000000cd71ce05676dce51
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I like this proposal, it seems sufficiently general.<div><=
br></div><div>How are scripts with OP_CLTV and OP_CSV handled by verifiers?=
 Do they always succeed? Or should an nLockTime and nSequence also be inclu=
ded in the proof in a way that can be parsed out and displayed to verifiers=
?</div><div><br></div><div>I assume any signatures in the scriptSig/witness=
 data would have no sighash type?</div></div><div class=3D"gmail_extra"><br=
><div class=3D"gmail_quote">On Wed, Mar 14, 2018 at 8:01 PM, Karl Johan Alm=
 via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.=
linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.or=
g</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">=
On Wed, Mar 14, 2018 at 5:46 AM, Kalle Rosenbaum &lt;<a href=3D"mailto:kall=
e@rosenbaum.se">kalle@rosenbaum.se</a>&gt; wrote:<br>
&gt; I can&#39;t really see from your proposal if you had thought of this: =
A soft<br>
&gt; fork can make old nodes accept invalid message signatures as valid. Fo=
r<br>
&gt; example, a &quot;signer&quot; can use a witness version unknown to the=
 verifier to<br>
&gt; fool the verifier. Witness version is detectable (just reject unknown<=
br>
&gt; witness versions)=C2=A0 but there may be more subtle changes. Segwit w=
as not<br>
&gt; &quot;detectable&quot; in that way, for example.<br>
&gt;<br>
&gt; This is the reason why I withdrew BIP120. If you have thought about th=
e<br>
&gt; above, I&#39;d be very interested.<br>
<br>
</span>I&#39;m not sure I see the problem. The scriptPubKey is derived dire=
ctly<br>
from the address in all cases, which means the unknown witness version<br>
would have to be committed to in the address itself.<br>
<br>
So yeah, I can make a P2SH address with a witness version &gt; 0 and a to<b=
r>
me unknown pubkey and then fool you into thinking I own it, but I<br>
don&#39;t really see why you&#39;d ultimately care. In other words, if I ca=
n<br>
SPEND funds sent to that address today, I can prove that I can spend<br>
today, which is the purpose of the tool, I think.<br>
<br>
For the case where the witness version HAS been upgraded, the above<br>
still applies, but I&#39;m not sure it&#39;s a big issue. And it doesn&#39;=
t<br>
really require an old node. I just need to set witness version &gt;<br>
current witness version and the problem applies to all nodes.<br>
<span class=3D""><br>
On Wed, Mar 14, 2018 at 8:36 AM, Luke Dashjr &lt;<a href=3D"mailto:luke@das=
hjr.org">luke@dashjr.org</a>&gt; wrote:<br>
&gt; I don&#39;t see a need for a new RPC interface, just a new signature f=
ormat.<br>
<br>
</span>All right.<br>
<span class=3D""><br>
&gt; Ideally, it should support not only just &quot;proof I receive at this=
 address&quot;,<br>
&gt; but also &quot;proof of funds&quot; (as a separate feature) since this=
 is a popular<br>
&gt; misuse of the current message signing (which doesn&#39;t actually prov=
e funds at<br>
&gt; all). To do this, it needs to be capable of signing for multiple input=
s.<br>
<br>
</span>I assume by inputs you mean addresses/keys. The address field could<=
br>
optionally be an array. That&#39;d be enough?<br>
<span class=3D""><br>
&gt; Preferably, it should also avoid disclosing the public key for existin=
g or<br>
&gt; future UTXOs. But I don&#39;t think it&#39;s possible to avoid this wi=
thout something<br>
&gt; MAST-like first. Perhaps it can be a MAST upgrade later on, but the ne=
w<br>
&gt; signature scheme should probably be designed with it in mind.<br>
<br>
</span>I&#39;d love to not have to reveal the public key, but I&#39;m not s=
ure how it<br>
would be done, even with MAST.<br>
<span class=3D""><br>
On Wed, Mar 14, 2018 at 12:12 PM, Anthony Towns &lt;<a href=3D"mailto:aj@er=
isian.com.au">aj@erisian.com.au</a>&gt; wrote:<br>
&gt; Wouldn&#39;t it be sufficient for old nodes to check for standardness =
of the spending script and report non-standard scripts as either invalid ou=
tright, or at least highly questionable? That should prevent confusion as l=
ong as soft forks are only making nonstandard behaviours invalid.<br>
<br>
</span>That seems sensible to me. A warning would probably be useful, in ca=
se<br>
the verifier is running old software.<br>
<br>
-Kalle.<br>
<div class=3D"HOEnZb"><div class=3D"h5">______________________________<wbr>=
_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</div></div></blockquote></div><br></div>

--000000000000cd71ce05676dce51--