Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 4680BEBF for ; Fri, 16 Mar 2018 02:00:08 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm0-f48.google.com (mail-wm0-f48.google.com [74.125.82.48]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7EAA85CF for ; Fri, 16 Mar 2018 02:00:07 +0000 (UTC) Received: by mail-wm0-f48.google.com with SMTP id h21so331438wmd.1 for ; Thu, 15 Mar 2018 19:00:07 -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=mJYlTLoq+scQ/fzkiXxgJDQTSrIPVNBMn6bstEH9r80=; b=H69VhV32AK1+/KTW30zxmi29nJ5vbenpAXokXRNPM7H2yoPEiNC9OUJT05bG5BXA5a I5bUrOGNdhah1dgh6FHHEiea4X1rH+XLdptLSQ1so6KpEtOqGbR71igVR+Gv8CD0GDqi 2Uns8L3E59+1agdmG9igX84FjApywa15OT8o70sj38a9PiRQxCvJQP1bAi5A87L7kBk2 zey8acCDcnDPSvQLgB9c1KYdTXxNadGebND1+Zn1Zc/+yfEI0z8wSD9Uh4FhJ3iGSbu2 4nCewLHApmiT9e/MU082u6EP2MY6YdUwMoBmSWZWuJ7ftaIQPGCnKfBXWcmxkrVpwI0X ADDg== 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=mJYlTLoq+scQ/fzkiXxgJDQTSrIPVNBMn6bstEH9r80=; b=XibL2bjApPRjiJPENNekOb95zYCJcA4qu27hmehIHKSQLaoZVtfadyvLfA5ognYwNV 10bCEOLlVnDmh1rFzPrdcTd/4gTvs20e0XA6VhaX35CRRMDTPkRKvbiQ8/Z+IwpudD7i YuN2ss1jeOvz4keoEsreXTwYLB40uQNjYCjEs+UDPdrjcwnwep1PfMrIe0BofBRMwgNR 5bbPXRLm2/DZwvEscEXyosOk6UvXIapsAB0tQdLkHtWFiZ+FjpBo8yr8RW+quqjFvMJm hUfmLOO0ZAAhEFmlS/5hpcfrFLtbJwu3q9zUvz5MPbIzZ/jaeGsk1KViIYlcXKr9EG/e IH3Q== X-Gm-Message-State: AElRT7HuLT87wpyzA5ehziQfBzOurVLUwR6r/8j0wcpu+tVziaUEm6cK cRqoY4P1p57pKStf5zsFOGx8GQtwWCGcwH2MI3w= X-Google-Smtp-Source: AG47ELu1SVC+EWRrJw2DtBHDAHNiX+1I6FArFsYW2D9pnb/FPxRrAAdtifTf6UKRCEOAfxJEktLwcELz9zL33mplZm0= X-Received: by 10.80.165.143 with SMTP id a15mr468007edc.289.1521165606007; Thu, 15 Mar 2018 19:00:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.175.228 with HTTP; Thu, 15 Mar 2018 18:59:45 -0700 (PDT) In-Reply-To: References: <201803141236.48869.luke@dashjr.org> <201803151414.06301.luke@dashjr.org> From: Greg Sanders Date: Thu, 15 Mar 2018 21:59:45 -0400 Message-ID: To: Karl Johan Alm , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="f403045c24d8973be205677df78f" X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org 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: Fri, 16 Mar 2018 02:00:08 -0000 --f403045c24d8973be205677df78f Content-Type: text/plain; charset="UTF-8" Sorry if I missed the rationale earlier, but why not just do a transaction, with a FORKID specifically for this? Then a node can have a mempool acceptance test that returns true even if the signature is not valid as per Bitcoin consensus, but only due to the FORKID? This way basically any wallet can support this provided generic FORKID support. On Thu, Mar 15, 2018 at 8:38 PM, Karl Johan Alm via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Thu, Mar 15, 2018 at 2:14 PM, Luke Dashjr wrote: > > Not necessarily specific UTXOs (that would contradict fungibility, as > well as > > be impossible for hot/cold wallet separation), but just to prove funds > are > > available. The current sign message cannot be used to prove present > possession > > of funds, only that you receive funds. > > By saying "not necessarily specific UTXOs", are you saying it may be > spent outputs? I'm a little confused I think. > > On Thu, Mar 15, 2018 at 8:53 PM, Jim Posen wrote: > > In this general signing-a-script context, I think a verifier might want > to > > see the time conditions under which it may be spent. The proof container > > could include an optional nLockTime which defaults to 0 and nSequence > which > > defaults to 0xFFFF... > > Good point! > > >> I think it would just use the default (SIGHASH_ALL?) for simplicity. > >> Is there a good reason to tweak it? > > > > I took another look and there should definitely be a byte appended to the > > end of the sig so that the encoding checks pass, but I think it might as > > well be a 0x00 byte since it's not actually a sighash flag. > > I think the sighash flag affects the outcome of the actual > verification, but I could be mistaken. > > -Kalle. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --f403045c24d8973be205677df78f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry if I missed the rationale earlier, but why not just = do a transaction, with a FORKID specifically for this? Then a node can have= a mempool acceptance test that returns true even if the signature is not v= alid as per Bitcoin consensus, but only due to the FORKID?

This way basically any wallet can support this provided generic FORKID s= upport.

On Thu, Mar 15, 2018 at 8:38 PM, Karl Johan Alm via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
On Thu, Mar 15, 2018 at 2:= 14 PM, Luke Dashjr <luke@dashjr.org> wrote:
> Not necessarily specific UTXOs (that would contradict fungibility, as = well as
> be impossible for hot/cold wallet separation), but just to prove funds= are
> available. The current sign message cannot be used to prove present po= ssession
> of funds, only that you receive funds.

By saying "not necessarily specific UTXOs", are you saying= it may be
spent outputs? I'm a little confused I think.

On Thu, Mar 15, 2018 at 8:53 PM, Jim Posen <jim.posen@gmail.com> wrote:
> In this general signing-a-script context, I think a verifier might wan= t to
> see the time conditions under which it may be spent. The proof contain= er
> could include an optional nLockTime which defaults to 0 and nSequence = which
> defaults to 0xFFFF...

Good point!

>> I think it would just use the default (SIGHASH_ALL?) for simplicit= y.
>> Is there a good reason to tweak it?
>
> I took another look and there should definitely be a byte appended to = the
> end of the sig so that the encoding checks pass, but I think it might = as
> well be a 0x00 byte since it's not actually a sighash flag.

I think the sighash flag affects the outcome of the actual
verification, but I could be mistaken.

-Kalle.
______________________________= _________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev

--f403045c24d8973be205677df78f--