* [bitcoin-dev] RFC: Kicking BIP-322 (message signing) into motion
@ 2020-03-04 6:23 Karl-Johan Alm
2020-03-04 7:03 ` Karl-Johan Alm
2020-03-04 14:35 ` Luke Dashjr
0 siblings, 2 replies; 5+ messages in thread
From: Karl-Johan Alm @ 2020-03-04 6:23 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
Hello,
I noticed recently that a PR to Bitcoin Core that pretty much touched
everything my BIP-322 pull request touches (around the same
complexity) was merged without a thought given to BIP-322
compatibility, despite the BIP-322 PR being open for 2x the time. I
can only conclude from this that people dislike BIP-322 in its current
form, which the 9 month old pull request stagnating can probably
attest to.
There are several things that I can do to make this a bit more
appealing to people, which would hopefully kick the progress on this
forward. I have already put in a non-trivial amount of energy and
effort into maintaining the pull request as is, so I'd prefer if
people were harsh and unfiltered in their criticism rather than polite
and buffered, so I can beat this thing into shape (or abandon it, in
the worst case).
=============
1. People use signmessage as a way to prove funds. This is misleading
and should be discouraged; throw the sign message stuff out and
replace it entirely with a prove funds system.
I know in particular luke-jr is of this opinion, and Greg Maxwell in
https://github.com/bitcoin/bitcoin/pull/16440#issuecomment-568194168
leans towards this opinion as well, it seems.
=============
2. Use a transaction rather than a new format; make the first input's
txid the message hash to ensure the tx cannot be broadcasted. This has
the benefit of being able to provide to an existing hardware wallet
without making any modifications to its firmware.
I think Mark Friedenbach and Johnson Lau are of this opinion, except
Johnson Lau also suggests that the signature hash is modified, see
https://github.com/bitcoin/bips/pull/725#issuecomment-420040430 --
which defeats the benefit above since now hw wallets can no longer
sign.
Prusnak (I think he works at Trezor; apologies if I am mistaken) is
against this idea, and proposes (3) below:
https://github.com/bitcoin/bips/pull/725#issuecomment-420210488
=============
3. Use Trezor style
See https://github.com/trezor/trezor-mcu/issues/169
This has the benefit of already being adopted (which clearly BIP-322
is failing hard at right now), but has the drawback that we can no
longer do *generic* signing; we are stuck with the exact same
limitations as in the legacy system, which we kinda wanted to fix in
the updated version.
=============
4. Introduce OP_MESSAGEONLY
Quoting Johnson Lau at
https://github.com/bitcoin/bips/pull/725#issuecomment-420421058 :
"""
OP_MESSAGEONLY means the script following the code would never be
valid. For example, a scriptPubKey:
OP_IF OP_MESSAGEONLY <key_m> OP_ELSE <key_s> OP_ENDIF OP_CHECKSIG
For messaging purpose, OP_MESSAGEONLY is considered as OP_NOP and is
ignored. A message could be signed with either key_m or key_s.
For spending, only key_s is valid.
I don't think it is a big problem to consume a op_code. If this is a
real concern, I could modify it as follow: in message system,
OP_RETURN will pop the top stack. If top stack is msg in hex, it is
ignored. Otherwise, the script fails.
"""
=============
5. Some other solution
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] RFC: Kicking BIP-322 (message signing) into motion
2020-03-04 6:23 [bitcoin-dev] RFC: Kicking BIP-322 (message signing) into motion Karl-Johan Alm
@ 2020-03-04 7:03 ` Karl-Johan Alm
2020-03-04 14:35 ` Luke Dashjr
1 sibling, 0 replies; 5+ messages in thread
From: Karl-Johan Alm @ 2020-03-04 7:03 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
I forgot one:
=============
5. The current BIP itself is poorly written and/or unnecessarily
complex: e.g. remove the multi-proof support, and/or remove the
extensibility stuff for a future proof-of-funds extension, and/or
focus solely on the generic sign message stuff.
=============
6. Some other solution
On Wed, Mar 4, 2020 at 3:23 PM Karl-Johan Alm
<karljohan-alm@garage•co.jp> wrote:
>
> Hello,
>
> I noticed recently that a PR to Bitcoin Core that pretty much touched
> everything my BIP-322 pull request touches (around the same
> complexity) was merged without a thought given to BIP-322
> compatibility, despite the BIP-322 PR being open for 2x the time. I
> can only conclude from this that people dislike BIP-322 in its current
> form, which the 9 month old pull request stagnating can probably
> attest to.
>
> There are several things that I can do to make this a bit more
> appealing to people, which would hopefully kick the progress on this
> forward. I have already put in a non-trivial amount of energy and
> effort into maintaining the pull request as is, so I'd prefer if
> people were harsh and unfiltered in their criticism rather than polite
> and buffered, so I can beat this thing into shape (or abandon it, in
> the worst case).
>
> =============
> 1. People use signmessage as a way to prove funds. This is misleading
> and should be discouraged; throw the sign message stuff out and
> replace it entirely with a prove funds system.
>
> I know in particular luke-jr is of this opinion, and Greg Maxwell in
> https://github.com/bitcoin/bitcoin/pull/16440#issuecomment-568194168
> leans towards this opinion as well, it seems.
>
> =============
> 2. Use a transaction rather than a new format; make the first input's
> txid the message hash to ensure the tx cannot be broadcasted. This has
> the benefit of being able to provide to an existing hardware wallet
> without making any modifications to its firmware.
>
> I think Mark Friedenbach and Johnson Lau are of this opinion, except
> Johnson Lau also suggests that the signature hash is modified, see
> https://github.com/bitcoin/bips/pull/725#issuecomment-420040430 --
> which defeats the benefit above since now hw wallets can no longer
> sign.
>
> Prusnak (I think he works at Trezor; apologies if I am mistaken) is
> against this idea, and proposes (3) below:
> https://github.com/bitcoin/bips/pull/725#issuecomment-420210488
>
> =============
> 3. Use Trezor style
>
> See https://github.com/trezor/trezor-mcu/issues/169
>
> This has the benefit of already being adopted (which clearly BIP-322
> is failing hard at right now), but has the drawback that we can no
> longer do *generic* signing; we are stuck with the exact same
> limitations as in the legacy system, which we kinda wanted to fix in
> the updated version.
>
> =============
> 4. Introduce OP_MESSAGEONLY
>
> Quoting Johnson Lau at
> https://github.com/bitcoin/bips/pull/725#issuecomment-420421058 :
> """
> OP_MESSAGEONLY means the script following the code would never be
> valid. For example, a scriptPubKey:
>
> OP_IF OP_MESSAGEONLY <key_m> OP_ELSE <key_s> OP_ENDIF OP_CHECKSIG
>
> For messaging purpose, OP_MESSAGEONLY is considered as OP_NOP and is
> ignored. A message could be signed with either key_m or key_s.
>
> For spending, only key_s is valid.
>
> I don't think it is a big problem to consume a op_code. If this is a
> real concern, I could modify it as follow: in message system,
> OP_RETURN will pop the top stack. If top stack is msg in hex, it is
> ignored. Otherwise, the script fails.
> """
>
> =============
> 5. Some other solution
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] RFC: Kicking BIP-322 (message signing) into motion
2020-03-04 6:23 [bitcoin-dev] RFC: Kicking BIP-322 (message signing) into motion Karl-Johan Alm
2020-03-04 7:03 ` Karl-Johan Alm
@ 2020-03-04 14:35 ` Luke Dashjr
2020-03-04 14:43 ` Greg Sanders
1 sibling, 1 reply; 5+ messages in thread
From: Luke Dashjr @ 2020-03-04 14:35 UTC (permalink / raw)
To: bitcoin-dev, Karl-Johan Alm
In addition to starting with proof-of-funds instead of proof-of-receiver, it
would be nice to integrate with Taproot somehow or another. Perhaps
OP_MESSAGEONLY is the most straightforward way to do this? It might be a good
idea to have a message type after the opcode too.
On Wednesday 04 March 2020 06:23:53 Karl-Johan Alm via bitcoin-dev wrote:
> Hello,
>
> I noticed recently that a PR to Bitcoin Core that pretty much touched
> everything my BIP-322 pull request touches (around the same
> complexity) was merged without a thought given to BIP-322
> compatibility, despite the BIP-322 PR being open for 2x the time. I
> can only conclude from this that people dislike BIP-322 in its current
> form, which the 9 month old pull request stagnating can probably
> attest to.
>
> There are several things that I can do to make this a bit more
> appealing to people, which would hopefully kick the progress on this
> forward. I have already put in a non-trivial amount of energy and
> effort into maintaining the pull request as is, so I'd prefer if
> people were harsh and unfiltered in their criticism rather than polite
> and buffered, so I can beat this thing into shape (or abandon it, in
> the worst case).
>
> =============
> 1. People use signmessage as a way to prove funds. This is misleading
> and should be discouraged; throw the sign message stuff out and
> replace it entirely with a prove funds system.
>
> I know in particular luke-jr is of this opinion, and Greg Maxwell in
> https://github.com/bitcoin/bitcoin/pull/16440#issuecomment-568194168
> leans towards this opinion as well, it seems.
>
> =============
> 2. Use a transaction rather than a new format; make the first input's
> txid the message hash to ensure the tx cannot be broadcasted. This has
> the benefit of being able to provide to an existing hardware wallet
> without making any modifications to its firmware.
>
> I think Mark Friedenbach and Johnson Lau are of this opinion, except
> Johnson Lau also suggests that the signature hash is modified, see
> https://github.com/bitcoin/bips/pull/725#issuecomment-420040430 --
> which defeats the benefit above since now hw wallets can no longer
> sign.
>
> Prusnak (I think he works at Trezor; apologies if I am mistaken) is
> against this idea, and proposes (3) below:
> https://github.com/bitcoin/bips/pull/725#issuecomment-420210488
>
> =============
> 3. Use Trezor style
>
> See https://github.com/trezor/trezor-mcu/issues/169
>
> This has the benefit of already being adopted (which clearly BIP-322
> is failing hard at right now), but has the drawback that we can no
> longer do *generic* signing; we are stuck with the exact same
> limitations as in the legacy system, which we kinda wanted to fix in
> the updated version.
>
> =============
> 4. Introduce OP_MESSAGEONLY
>
> Quoting Johnson Lau at
> https://github.com/bitcoin/bips/pull/725#issuecomment-420421058 :
> """
> OP_MESSAGEONLY means the script following the code would never be
> valid. For example, a scriptPubKey:
>
> OP_IF OP_MESSAGEONLY <key_m> OP_ELSE <key_s> OP_ENDIF OP_CHECKSIG
>
> For messaging purpose, OP_MESSAGEONLY is considered as OP_NOP and is
> ignored. A message could be signed with either key_m or key_s.
>
> For spending, only key_s is valid.
>
> I don't think it is a big problem to consume a op_code. If this is a
> real concern, I could modify it as follow: in message system,
> OP_RETURN will pop the top stack. If top stack is msg in hex, it is
> ignored. Otherwise, the script fails.
> """
>
> =============
> 5. Some other solution
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] RFC: Kicking BIP-322 (message signing) into motion
2020-03-04 14:35 ` Luke Dashjr
@ 2020-03-04 14:43 ` Greg Sanders
2020-03-25 6:31 ` Karl-Johan Alm
0 siblings, 1 reply; 5+ messages in thread
From: Greg Sanders @ 2020-03-04 14:43 UTC (permalink / raw)
To: Luke Dashjr, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 4403 bytes --]
OP_MESSAGEONLY would make "dumb" signers like HWW more difficult to
support. They'd have to do script interpretation to make sure they're not
signing something real with funds.
Just FYI.
On Wed, Mar 4, 2020 at 9:35 AM Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> In addition to starting with proof-of-funds instead of proof-of-receiver,
> it
> would be nice to integrate with Taproot somehow or another. Perhaps
> OP_MESSAGEONLY is the most straightforward way to do this? It might be a
> good
> idea to have a message type after the opcode too.
>
> On Wednesday 04 March 2020 06:23:53 Karl-Johan Alm via bitcoin-dev wrote:
> > Hello,
> >
> > I noticed recently that a PR to Bitcoin Core that pretty much touched
> > everything my BIP-322 pull request touches (around the same
> > complexity) was merged without a thought given to BIP-322
> > compatibility, despite the BIP-322 PR being open for 2x the time. I
> > can only conclude from this that people dislike BIP-322 in its current
> > form, which the 9 month old pull request stagnating can probably
> > attest to.
> >
> > There are several things that I can do to make this a bit more
> > appealing to people, which would hopefully kick the progress on this
> > forward. I have already put in a non-trivial amount of energy and
> > effort into maintaining the pull request as is, so I'd prefer if
> > people were harsh and unfiltered in their criticism rather than polite
> > and buffered, so I can beat this thing into shape (or abandon it, in
> > the worst case).
> >
> > =============
> > 1. People use signmessage as a way to prove funds. This is misleading
> > and should be discouraged; throw the sign message stuff out and
> > replace it entirely with a prove funds system.
> >
> > I know in particular luke-jr is of this opinion, and Greg Maxwell in
> > https://github.com/bitcoin/bitcoin/pull/16440#issuecomment-568194168
> > leans towards this opinion as well, it seems.
> >
> > =============
> > 2. Use a transaction rather than a new format; make the first input's
> > txid the message hash to ensure the tx cannot be broadcasted. This has
> > the benefit of being able to provide to an existing hardware wallet
> > without making any modifications to its firmware.
> >
> > I think Mark Friedenbach and Johnson Lau are of this opinion, except
> > Johnson Lau also suggests that the signature hash is modified, see
> > https://github.com/bitcoin/bips/pull/725#issuecomment-420040430 --
> > which defeats the benefit above since now hw wallets can no longer
> > sign.
> >
> > Prusnak (I think he works at Trezor; apologies if I am mistaken) is
> > against this idea, and proposes (3) below:
> > https://github.com/bitcoin/bips/pull/725#issuecomment-420210488
> >
> > =============
> > 3. Use Trezor style
> >
> > See https://github.com/trezor/trezor-mcu/issues/169
> >
> > This has the benefit of already being adopted (which clearly BIP-322
> > is failing hard at right now), but has the drawback that we can no
> > longer do *generic* signing; we are stuck with the exact same
> > limitations as in the legacy system, which we kinda wanted to fix in
> > the updated version.
> >
> > =============
> > 4. Introduce OP_MESSAGEONLY
> >
> > Quoting Johnson Lau at
> > https://github.com/bitcoin/bips/pull/725#issuecomment-420421058 :
> > """
> > OP_MESSAGEONLY means the script following the code would never be
> > valid. For example, a scriptPubKey:
> >
> > OP_IF OP_MESSAGEONLY <key_m> OP_ELSE <key_s> OP_ENDIF OP_CHECKSIG
> >
> > For messaging purpose, OP_MESSAGEONLY is considered as OP_NOP and is
> > ignored. A message could be signed with either key_m or key_s.
> >
> > For spending, only key_s is valid.
> >
> > I don't think it is a big problem to consume a op_code. If this is a
> > real concern, I could modify it as follow: in message system,
> > OP_RETURN will pop the top stack. If top stack is msg in hex, it is
> > ignored. Otherwise, the script fails.
> > """
> >
> > =============
> > 5. Some other solution
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists•linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 6233 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] RFC: Kicking BIP-322 (message signing) into motion
2020-03-04 14:43 ` Greg Sanders
@ 2020-03-25 6:31 ` Karl-Johan Alm
0 siblings, 0 replies; 5+ messages in thread
From: Karl-Johan Alm @ 2020-03-25 6:31 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
Hello,
I propose simplifying BIP-322 down to the single-proof case, and
removing some abstractions (e.g. the "actions"/"purposes" stuff):
https://github.com/bitcoin/bips/pull/903
Feedback welcome.
New version below:
```
<pre>
BIP: 322
Layer: Applications
Title: Generic Signed Message Format
Author: Karl-Johan Alm <karljohan-alm@garage•co.jp>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0322
Status: Draft
Type: Standards Track
Created: 2018-09-10
License: CC0-1.0
</pre>
== Abstract ==
A standard for interoperable generic signed messages based on the
Bitcoin Script format.
== Background ==
* Assume two actors, a prover <code>P</code> and a verifier <code>V</code>.
* <code>P</code> wants to prove that they own the private key
<code>k</code> associated with a given address <code>A</code> (which
in turn is derived from the pubkey <code>kG</code>).
* Let <code>V</code> generate a message <code>M</code> and hand this
to <code>P</code>.
* <code>P</code> generates a signature <code>S</code> by signing the
message <code>M</code> using <code>k</code>. Given <code>S</code>,
<code>V</code> can prove that <code>P</code> has the private key
associated with <code>A</code>.
The astute reader will notice that the above is missing a critical
part, namely the pubkey <code>kG</code>, without which the verifier
cannot actually verify the message. The current message signing
standard solves this via a cryptographic trick, wherein the signature
<code>S</code> above is a special "recoverable signature" type. Given
the message <code>M</code> and the signature <code>S</code>, it is
then possible to recover the pubkey <code>kG</code>. The system thus
derives the address for the pubkey <code>kG</code>, and if it does not
match <code>A</code>, the proof is deemed invalid.
While this is a neat trick, it unnecessarily restricts and complicates
the message signing mechanism; for instance, it is currently not
possible to sign a message for a P2SH address, because there is no
pubkey to recover from the resulting signature.
== Motivation ==
The current message signing standard only works for P2PKH (1...)
addresses. By extending it to use a Bitcoin Script based approach, it
could be made more generic without causing a too big burden on
implementers, who most likely have access to Bitcoin Script
interpreters already.
== Specification ==
A new structure <code>SignatureProof</code> is added, which is a
simple serializable scriptSig & witness container.
=== SignatureProof container ===
{|class="wikitable" style="text-align: center;"
|-
!Type
!Length
!Name
!Comment
|-
|VarInt||1-8||scriptsiglen||Number of bytes in scriptSig data
|-
|Uint8*||[scriptsiglen]||scriptsig||ScriptSig data
|-
|VarInt||1-8||witlen||Number of entries in witness stack
|-
|Uint8[]*||[witlen]||wit||Witness stack, as [witlen] uint8* vectors,
each one prepended with a varint of its size
|}
In some cases, the scriptsig or wit may be empty. If both are empty,
the proof is incomplete.
=== Result Codes ===
A verification call will return a result code according to the table below.
{|class="wikitable" style="text-align: center;"
|-
!Code
!Description
|-
|INCOMPLETE||Empty proof.
|-
|INCONCLUSIVE||The given proof was consensus-valid but policy-invalid.
|-
|VALID||The proof was valid.
|-
|INVALID||The proof was invalid
|-
|ERROR||An error was encountered
|}
== Signing and Verifying ==
If the challenge consists of an address is in the P2PKH (legacy)
format, sign using the legacy format (further information below).
Otherwise continue as stated below.
For both cases, generate a sighash based on the given scriptPubKey and
message as follows:
# Define the message pre-image as the sequence "Bitcoin Signed
Message:\n" concatenated with the message, encoded in UTF-8 using
Normalization Form Compatibility Decomposition (NFKD)
# Let sighash = sha256(sha256(scriptPubKey || pre-image))
A private key may be used directly to sign a message. In this case,
its P2WPKH bech32 address shall be derived, and used as the input.
=== Signing ===
The signature is generated as follows:
# Derive the private key privkey for the scriptPubKey; FAIL if not VALID
# Generate and return a signature sig with privkey=privkey, sighash=sighash
=== Verifying ===
Verify a proof, given a standard flags value, a script sig, an
optional witness, and a derived sighash as described above.
While omitted below, ERROR is returned if an unforeseen error occurs
at any point in the process. A concrete example of this is if a legacy
proof is given as input to a non-legacy address; the deserialization
of the proof will fail in this case, and this should result in an
ERROR result.
# Verify Script with flags=consensus flags (currently P2SH, DERSIG,
NULLDUMMY, CLTV, CSV, WITNESS), scriptSig=script sig,
scriptPubKey=scriptPubKey, witness=witness, and sighash=sighash
# Return INVALID if verification fails
# Verify Script with flags=standard flags (above plus STRICTENC,
MINIMALDATA, etc.), scriptSig=script sig, scriptPubKey=scriptPubKey,
witness=witness, and sighash=sighash
# Return VALID if verification succeeds, otherwise return INCONCLUSIVE
== Legacy format ==
The legacy format is restricted to the legacy P2PKH address format.
Any other input (i.e. non-P2PKH address format) must be signed using
the new format described above.
=== Signing ===
Given the P2PKH address <code>a</code> and the message <code>m</code>,
and the pubkey-hash function <code>pkh(P) =
ripemd160(sha256(P))</code>:
# let <code>p</code> be the pubkey-hash <code>pkh(P)</code> for the
pubkey <code>P</code>, contained in <code>a</code>
# let <code>x</code> be the private key associated with <code>P</code>
so that <code>pkh(xG) = p</code>
# let <code>digest</code> be <code>SHA56d("Bitcoin Signed Message:\n"||m)</code>
# create a compact signature <code>sig</code> (aka "recoverable ECDSA
signature") using <code>x</code> on <code>digest</code>
The resulting proof is <code>sig</code>, serialized using the base64 encoding.
=== Verifying ===
Given the P2PKH address <code>a</code>, the message <code>m</code>,
the compact signature <code>sig</code>, and the pubkey-hash function
<code>pkh(P) = ripemd160(sha256(P))</code>:
# let <code>p</code> be the pubkey-hash <code>pkh(P)</code> for the
pubkey <code>P</code>, contained in <code>a</code>
# let <code>digest</code> be <code>SHA56d("Bitcoin Signed Message:\n"||m)</code>
# attempt pubkey recovery for <code>digest</code> using the signature
<code>sig</code> and store the resulting pubkey into <code>Q</code>
## fail verification if pubkey recovery above fails
# let <code>q</code> be the pubkey-hash <code>pkh(Q)</code> for the
pubkey <code>Q</code>
# if <code>p == q</code>, the proof is valid, otherwise it is invalid
== Compatibility ==
This specification is backwards compatible with the legacy
signmessage/verifymessage specification through the special case as
described above.
== Reference implementation ==
# Pull request to Bitcoin Core: https://github.com/bitcoin/bitcoin/pull/16440
== Acknowledgements ==
Thanks to David Harding, Jim Posen, Kalle Rosenbaum, Pieter Wuille,
and many others for their feedback on the specification.
== References ==
# Original mailing list thread:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-March/015818.html
== Copyright ==
This document is licensed under the Creative Commons CC0 1.0 Universal license.
== Consensus and standard flags ==
Each flag is associated with some type of enforced rule (most often a
soft fork). There are two sets of flags: consensus flags (which result
in a block being rejected, if violated), and policy flags (which
result in a transaction being accepted only if it is contained within
an actual block, and rejected otherwise, if violated). The policy
flags are a super-set of the consensus flags.
BIP322 specifies that a proof that validates for both rulesets is
valid, a proof that validates for consensus rules, but not for policy
rules, is "inconclusive", and a proof that does not validate for
consensus rules is "invalid" (regardless of policy rule validation).
The ruleset sometimes changes. This BIP does not intend to be
complete, nor does it indicate enforcement of rules, it simply lists
the rules as they stand at the point of writing.
=== Consensus rules ===
* P2SH: evaluate P2SH
([https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki
BIP16]) subscripts
* DERSIG: enforce strict DER
([https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki
BIP66]) compliance
* NULLDUMMY: enforce NULLDUMMY
([https://github.com/bitcoin/bips/blob/master/bip-0147.mediawiki
BIP147])
* CHECKLOCKTIMEVERIFY: enable CHECKLOCKTIMEVERIFY
([https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki
BIP65])
* CHECKSEQUENCEVERIFY: enable CHECKSEQUENCEVERIFY
([https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki
BIP112])
* WITNESS: enable WITNESS
([https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki
BIP141])
=== Policy rules ===
All of the above, plus (subject to change):
* STRICTENC: non-strict DER signature or undefined hashtype
* MINIMALDATA: require minimal encodings for all push operations
* DISCOURAGE_UPGRADABLE_NOPS: discourage use of NOPs reserved for upgrades
* CLEANSTACK: require that only a single stack element remains after evaluation
* MINIMALIF: Segwit script only: require the argument of OP_IF/NOTIF
to be exactly 0x01 or empty vector
* NULLFAIL: signature(s) must be empty vector if a CHECK(MULTI)SIG
operation failed
* LOW_S: signature with S > order/2 in a checksig operation
* DISCOURAGE_UPGRADABLE_WITNESS_PROGRAM: v1-16 witness programs are
non-standard (i.e. forbidden)
* WITNESS_PUBKEYTYPE: public keys in segregated witness scripts must
be compressed
* CONST_SCRIPTCODE: OP_CODESEPARATOR and FindAndDelete fail any
non-segwit scripts
== Test vectors ==
(TODO: update test vectors, which are based on previous iteration
where signature proofs contained additional data)
== Native segwit test vector ==
<pre>
address = bcrt1qe7nte4zk4ayly5tc53dtdjupgkz0lr8azx3rzz
scriptpubkey = 0014cfa6bcd456af49f25178a45ab6cb814584ff8cfd
message = hello
preimage = 0014cfa6bcd456af49f25178a45ab6cb814584ff8cfd426974636f696e205369
676e6564204d6573736167653a0a68656c6c6f
(scriptpubkey || "Bitcoin Signed Message:\nhello")
sighash = 790eef86c204f0bff969ff822121317aa34eff0215dbd30ccf031e7b2f3f0cc1
(sha256d(preimage), displayed in big-endian)
</pre>
The proof becomes:
<pre>
HEX: 01000000010002473044022075b4fb40421d55c55462879cb352a85eeb3af2138d3f0290
2c9143f12870f5f70220119c2995c1661138142f3899c1fd6d1af7e790e0e081be72db9c
e7bf5b5b932901210290beccd02b73eca57467b2b6f1e47161a9b76a5e67586e7c1dee9e
a6e2dcd869
Base64: AQAAAAEAAkcwRAIgdbT7QEIdVcVUYoecs1KoXus68hONPwKQLJFD8Shw9fcCIBGcKZXBZhE4
FC84mcH9bRr355Dg4IG+ctuc579bW5MpASECkL7M0Ctz7KV0Z7K28eRxYam3al5nWG58He6e
puLc2Gk=
</pre>
Split into components:
{|class="wikitable" style="text-align: center;"
|-
!Type
!Length
!Name
!Value
!Comment
|-
|Uint32||4||flags||<code>01000000</code>||proof format version
|-
|Uint8||1||entries||<code>01</code>||1 entry
|-
|VarInt||1-8||scriptsiglen||<code>00</code>||0 byte scriptsig
|-
|VarInt||1-8||wit entries||<code>02</code>||2 witness stack entries
|-
|VarInt||1-8||entry1len||<code>47</code>||71 byte entry
|-
|Uint8[71]||71||entry1||<code>3044022075b4fb40421d55c55462879cb352a85eeb3af213
8d3f02902c9143f12870f5f70220119c2995c1661138142f
3899c1fd6d1af7e790e0e081be72db9ce7bf5b5b932901</code>||Witness stack item 1
|-
|VarInt||1-8||entry2len||<code>21</code>||33 byte entry
|-
|Uint8[33]||33||entry2||<code>0290beccd02b73eca57467b2b6f1e47161a9b76a5e67586e
7c1dee9ea6e2dcd869</code>||Witness stack item 2
|}
The above test vector is for a bech32 P2WPKH (native segwit) address.
(Once BIP solidifies, will add test vector for other types.)
```
On Wed, Mar 4, 2020 at 11:43 PM Greg Sanders <gsanders87@gmail•com> wrote:
>
> OP_MESSAGEONLY would make "dumb" signers like HWW more difficult to support. They'd have to do script interpretation to make sure they're not signing something real with funds.
>
> Just FYI.
>
> On Wed, Mar 4, 2020 at 9:35 AM Luke Dashjr via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>
>> In addition to starting with proof-of-funds instead of proof-of-receiver, it
>> would be nice to integrate with Taproot somehow or another. Perhaps
>> OP_MESSAGEONLY is the most straightforward way to do this? It might be a good
>> idea to have a message type after the opcode too.
>>
>> On Wednesday 04 March 2020 06:23:53 Karl-Johan Alm via bitcoin-dev wrote:
>> > Hello,
>> >
>> > I noticed recently that a PR to Bitcoin Core that pretty much touched
>> > everything my BIP-322 pull request touches (around the same
>> > complexity) was merged without a thought given to BIP-322
>> > compatibility, despite the BIP-322 PR being open for 2x the time. I
>> > can only conclude from this that people dislike BIP-322 in its current
>> > form, which the 9 month old pull request stagnating can probably
>> > attest to.
>> >
>> > There are several things that I can do to make this a bit more
>> > appealing to people, which would hopefully kick the progress on this
>> > forward. I have already put in a non-trivial amount of energy and
>> > effort into maintaining the pull request as is, so I'd prefer if
>> > people were harsh and unfiltered in their criticism rather than polite
>> > and buffered, so I can beat this thing into shape (or abandon it, in
>> > the worst case).
>> >
>> > =============
>> > 1. People use signmessage as a way to prove funds. This is misleading
>> > and should be discouraged; throw the sign message stuff out and
>> > replace it entirely with a prove funds system.
>> >
>> > I know in particular luke-jr is of this opinion, and Greg Maxwell in
>> > https://github.com/bitcoin/bitcoin/pull/16440#issuecomment-568194168
>> > leans towards this opinion as well, it seems.
>> >
>> > =============
>> > 2. Use a transaction rather than a new format; make the first input's
>> > txid the message hash to ensure the tx cannot be broadcasted. This has
>> > the benefit of being able to provide to an existing hardware wallet
>> > without making any modifications to its firmware.
>> >
>> > I think Mark Friedenbach and Johnson Lau are of this opinion, except
>> > Johnson Lau also suggests that the signature hash is modified, see
>> > https://github.com/bitcoin/bips/pull/725#issuecomment-420040430 --
>> > which defeats the benefit above since now hw wallets can no longer
>> > sign.
>> >
>> > Prusnak (I think he works at Trezor; apologies if I am mistaken) is
>> > against this idea, and proposes (3) below:
>> > https://github.com/bitcoin/bips/pull/725#issuecomment-420210488
>> >
>> > =============
>> > 3. Use Trezor style
>> >
>> > See https://github.com/trezor/trezor-mcu/issues/169
>> >
>> > This has the benefit of already being adopted (which clearly BIP-322
>> > is failing hard at right now), but has the drawback that we can no
>> > longer do *generic* signing; we are stuck with the exact same
>> > limitations as in the legacy system, which we kinda wanted to fix in
>> > the updated version.
>> >
>> > =============
>> > 4. Introduce OP_MESSAGEONLY
>> >
>> > Quoting Johnson Lau at
>> > https://github.com/bitcoin/bips/pull/725#issuecomment-420421058 :
>> > """
>> > OP_MESSAGEONLY means the script following the code would never be
>> > valid. For example, a scriptPubKey:
>> >
>> > OP_IF OP_MESSAGEONLY <key_m> OP_ELSE <key_s> OP_ENDIF OP_CHECKSIG
>> >
>> > For messaging purpose, OP_MESSAGEONLY is considered as OP_NOP and is
>> > ignored. A message could be signed with either key_m or key_s.
>> >
>> > For spending, only key_s is valid.
>> >
>> > I don't think it is a big problem to consume a op_code. If this is a
>> > real concern, I could modify it as follow: in message system,
>> > OP_RETURN will pop the top stack. If top stack is msg in hex, it is
>> > ignored. Otherwise, the script fails.
>> > """
>> >
>> > =============
>> > 5. Some other solution
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev@lists•linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2020-03-25 6:41 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-04 6:23 [bitcoin-dev] RFC: Kicking BIP-322 (message signing) into motion Karl-Johan Alm
2020-03-04 7:03 ` Karl-Johan Alm
2020-03-04 14:35 ` Luke Dashjr
2020-03-04 14:43 ` Greg Sanders
2020-03-25 6:31 ` Karl-Johan Alm
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox