public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Greg Sanders <gsanders87@gmail.com>
To: Karl Johan Alm <karljohan-alm@garage.co.jp>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] {sign|verify}message replacement
Date: Thu, 15 Mar 2018 21:59:45 -0400	[thread overview]
Message-ID: <CAB3F3Dv=xk68sx5c=9vKL9ynAVJoEY_hnbuZQ0tSe=7cBdWSVA@mail.gmail.com> (raw)
In-Reply-To: <CALJw2w49bsBNFBj3MvdzNL+Hu3zuq-dmrTv_6wgmO_ZaCXt1nA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1946 bytes --]

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 <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
> 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 <jim.posen@gmail.com> 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
>

[-- Attachment #2: Type: text/html, Size: 2830 bytes --]

  reply	other threads:[~2018-03-16  2:00 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-14  8:09 [bitcoin-dev] {sign|verify}message replacement Karl Johan Alm
2018-03-14  9:46 ` Kalle Rosenbaum
2018-03-14 16:12   ` Anthony Towns
2018-03-15  3:01   ` Karl Johan Alm
2018-03-15  6:43     ` Jim Posen
2018-03-15  7:25       ` Karl Johan Alm
2018-03-15 20:53         ` Jim Posen
2018-03-14 12:36 ` Luke Dashjr
2018-03-15  7:36   ` Karl Johan Alm
2018-03-15 14:14     ` Luke Dashjr
2018-03-16  0:38       ` Karl Johan Alm
2018-03-16  1:59         ` Greg Sanders [this message]
2018-03-16  2:04           ` Karl Johan Alm
2018-03-15 10:15   ` Damian Williamson
2018-03-26  8:53 ` Pieter Wuille
2018-03-27  8:09   ` Karl Johan Alm

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAB3F3Dv=xk68sx5c=9vKL9ynAVJoEY_hnbuZQ0tSe=7cBdWSVA@mail.gmail.com' \
    --to=gsanders87@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=karljohan-alm@garage.co.jp \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox