public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Jim Posen <jim.posen@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: Wed, 14 Mar 2018 23:43:21 -0700	[thread overview]
Message-ID: <CADZtCSiSCDb1dzLCgr24jCNzzmcfsXuPyNVh+YJJ6rNqdsQh2Q@mail.gmail.com> (raw)
In-Reply-To: <CALJw2w719qQnyvaJbe1wc39+4ERDST+zXCOjt0DiJpktD74QCA@mail.gmail.com>

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

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
>

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

  reply	other threads:[~2018-03-15  6:43 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 [this message]
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
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=CADZtCSiSCDb1dzLCgr24jCNzzmcfsXuPyNVh+YJJ6rNqdsQh2Q@mail.gmail.com \
    --to=jim.posen@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