From: matejcik <jan.matejek@satoshilabs•com>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP 174 thoughts
Date: Tue, 19 Jun 2018 16:20:03 +0200 [thread overview]
Message-ID: <5b6b9d44-8e6c-2799-438e-d311e221bb57@satoshilabs.com> (raw)
In-Reply-To: <CAPg+sBhGMxXatsyCAqeboQKH8ASSFAfiXzxyXR9UrNFnah5PPw@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 3783 bytes --]
Hello,
First of all, we'd like to apologize for such a late feedback, since
there is a PR for this already. We've come up with a few more notes on
this, so we are introducing those in this message and replying on
Pieter's points in another one.
1) Why isn't the global type 0x03 (BIP-32 path) per-input? How do we
know, which BIP-32 path goes to which input? The only idea that comes to
my mind is that we should match the input's scriptPubKey's pubkey to
this 0x03's key (the public key).
If our understanding is correct, the BIP-32 path is global to save space
in case two inputs share the same BIP-32 path? How often does that
happen? And in case it does, doesn't it mean an address reuse which is
discouraged?
Also, we believe that if the public key is to be used as "spent to by an
output" it should be in an output section. If the public key is to be
used to sign an input, it should be in the input section. Again, how
often are those the same? We understand creating another section might
be cumbersome, but it'd significantly increase clarity to have global,
input and output section.
Alternately, we could keep “spend to” public keys in the global section,
and put the input public keys to the per-input sections. This is less
clear, but doesn’t introduce another section. A question to consider is,
will there be more per-output data? If yes, it might make sense to have
an output section.
2) The global items 0x01 (redeem script) and 0x02 (witness script) are
somewhat confusing. Let's consider only the redeem script (0x01) to make
it simple. The value description says: "A redeem script that will be
needed to sign a Pay-To-Script-Hash input or is spent to by an output.".
Does this mean that the record includes both input's redeem script
(because we need to sign it), but also a redeem script for the output
(to verify we are sending to a correct P2SH)? To mix those two seems
really confusing.
Yet again, adding a new output section would make this more readable. We
would include the input’s redeem script in the input section and the
output’s redeem script again in the output section, because they’ll most
likely differ anyway.
The rationale says that the scripts are global to avoid duplication.
However, how often is this the case? The scripts include a hash of some
OP codes and the recipient's public key for example. So a) how often are
two scripts equal to justify this? b) if they're the same, doesn't it
yet again signalize address reuse?
3) The sighash type 0x03 says the sighash is only a recommendation. That
seems rather ambiguous. If the field is specified shouldn't it be binding?
4) Is it a good idea to skip records which types we are unaware of? We
can't come up with a reasonable example, but intuitively this seems as a
potential security issue. We think we should consider introducing a
flag, which would define if the record is "optional". In case the signer
encounters a record it doesn't recognize and such flag is not set, it
aborts the procedure. If we assume the set model we could change the
structure to <type><optional flag><length>{data}. We are not keen on
this, but we wanted to include this idea to see what you think.
-----------
In general, the standard is trying to be very space-conservative,
however is that really necessary? We would argue for clarity and ease of
use over space constraints. We think more straightforward approach is
desired, although more space demanding. What are the arguments to make
this as small as possible? If we understand correctly, this format is
not intended for blockchain nor for persistent storage, so size doesn’t
matter nearly as much.
Thank you,
Tomas Susanka
Jan Matejek
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2018-06-19 14:25 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-15 23:34 Pieter Wuille
2018-06-16 15:00 ` Peter D. Gray
2018-06-19 9:38 ` Jonas Schnelli
2018-06-19 14:20 ` matejcik [this message]
2018-06-19 15:20 ` Jonas Schnelli
2018-06-21 20:28 ` Peter D. Gray
2018-06-19 17:16 ` Pieter Wuille
2018-06-21 11:29 ` matejcik
2018-06-21 17:39 ` Pieter Wuille
2018-06-21 11:44 ` Tomas Susanka
2018-06-19 14:22 ` matejcik
2018-06-21 0:39 ` Achow101
2018-06-21 14:32 ` Tomas Susanka
2018-06-21 15:40 ` Greg Sanders
2018-06-21 19:56 ` Peter D. Gray
2018-06-21 21:39 ` Gregory Maxwell
2018-06-22 19:10 ` Pieter Wuille
2018-06-22 22:28 ` Achow101
2018-06-23 17:00 ` William Casarin
2018-06-23 20:33 ` Andrew Chow
2018-06-24 8:19 ` Andrea
2018-06-24 8:28 ` Andrew Chow
2018-06-24 9:00 ` Andrea
2018-06-23 18:27 ` Peter D. Gray
2018-06-25 19:47 ` Tomas Susanka
2018-06-25 20:10 ` Jonas Schnelli
2018-06-25 20:30 ` Achow101
2018-06-26 15:33 ` matejcik
2018-06-26 16:58 ` William Casarin
2018-06-26 17:11 ` Marek Palatinus
2018-06-27 14:11 ` matejcik
2018-06-26 20:30 ` Pieter Wuille
2018-06-27 14:04 ` matejcik
2018-06-27 15:06 ` Pieter Wuille
2018-06-29 9:53 ` matejcik
2018-06-29 19:12 ` Achow101
2018-06-29 20:31 ` Peter D. Gray
2018-07-04 13:19 ` matejcik
2018-07-04 18:35 ` Achow101
2018-07-05 17:23 ` Jason Les
2018-07-04 19:09 ` Pieter Wuille
2018-07-05 11:52 ` matejcik
2018-07-05 22:06 ` Pieter Wuille
2018-07-10 12:10 ` matejcik
2018-07-11 18:27 ` Pieter Wuille
2018-07-11 20:05 ` Gregory Maxwell
2018-07-11 20:54 ` [bitcoin-dev] BIP 174 thoughts on graphics vv01f
2018-06-26 21:56 ` [bitcoin-dev] BIP 174 thoughts Achow101
2018-06-27 6:09 ` William Casarin
2018-06-27 13:39 ` Andrea
2018-06-27 17:55 ` Achow101
2018-06-28 20:42 ` Rodolfo Novak
2018-07-05 19:20 ` William Casarin
2018-07-06 18:59 ` Achow101
2018-06-20 0:39 Jason Les
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=5b6b9d44-8e6c-2799-438e-d311e221bb57@satoshilabs.com \
--to=jan.matejek@satoshilabs$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/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