Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id D48EFE0C for ; 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 ; Thu, 15 Mar 2018 06:43:23 +0000 (UTC) Received: by mail-it0-f47.google.com with SMTP id u5-v6so7816527itc.1 for ; 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: References: From: Jim Posen Date: Wed, 14 Mar 2018 23:43:21 -0700 Message-ID: To: Karl Johan Alm , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > 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 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 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
I like this proposal, it seems sufficiently general.
<= br>
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= ?

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.or= g> 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. Fo= r
> example, a "signer" can use a witness version unknown to the= verifier to
> fool the verifier. Witness version is detectable (just reject unknown<= br> > witness versions)=C2=A0 but there may be more subtle changes. Segwit w= as not
> "detectable" in that way, for example.
>
> This is the reason why I withdrew BIP120. If you have thought about th= e
> above, I'd be very interested.

I'm not sure I see the problem. The scriptPubKey is derived dire= ctly
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 ca= n
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 f= ormat.

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 prov= e funds at
> all). To do this, it needs to be capable of signing for multiple input= s.

I assume by inputs you mean addresses/keys. The address field could<= br> optionally be an array. That'd be enough?

> Preferably, it should also avoid disclosing the public key for existin= g or
> future UTXOs. But I don't think it's possible to avoid this wi= thout something
> MAST-like first. Perhaps it can be a MAST upgrade later on, but the ne= w
> 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 s= ure 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 ou= tright, or at least highly questionable? That should prevent confusion as l= ong as soft forks are only making nonstandard behaviours invalid.

That seems sensible to me. A warning would probably be useful, in ca= se
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--