From: Karl Johan Alm <karljohan-alm@garage•co.jp>
To: Kalle Rosenbaum <kalle@rosenbaum•se>
Cc: bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] {sign|verify}message replacement
Date: Wed, 14 Mar 2018 23:01:03 -0400 [thread overview]
Message-ID: <CALJw2w719qQnyvaJbe1wc39+4ERDST+zXCOjt0DiJpktD74QCA@mail.gmail.com> (raw)
In-Reply-To: <CAPswA9xuVT74L87QO9TXGc6=O6Gd2kbQMBdmn=7zUm5OHXcfOA@mail.gmail.com>
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.
next prev parent reply other threads:[~2018-03-15 3:01 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-14 8:09 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 [this message]
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
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=CALJw2w719qQnyvaJbe1wc39+4ERDST+zXCOjt0DiJpktD74QCA@mail.gmail.com \
--to=karljohan-alm@garage$(echo .)co.jp \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=kalle@rosenbaum$(echo .)se \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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