MIME-Version: 1.0
In-Reply-To: <CAPswA9xuVT74L87QO9TXGc6=O6Gd2kbQMBdmn=7zUm5OHXcfOA@mail.gmail.com>
References: <CALJw2w5=g-FL+MZ08DEoLxVzOKbSXeKu50drE1b4P0JZJpdTyA@mail.gmail.com>
	<CAPswA9xuVT74L87QO9TXGc6=O6Gd2kbQMBdmn=7zUm5OHXcfOA@mail.gmail.com>
From: Karl Johan Alm <karljohan-alm@garage.co.jp>
Date: Wed, 14 Mar 2018 23:01:03 -0400
Message-ID: <CALJw2w719qQnyvaJbe1wc39+4ERDST+zXCOjt0DiJpktD74QCA@mail.gmail.com>
To: Kalle Rosenbaum <kalle@rosenbaum.se>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] {sign|verify}message replacement
Precedence: list

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 o=
r
> future UTXOs. But I don't think it's possible to avoid this without somet=
hing
> 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.