đź“… Original date posted:2018-06-19
đź“ť Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180619/57fc30e2/attachment.sig>;
matejcik [ARCHIVE] /
npub18g…sgac3
2023-06-07 18:13:03
in reply to nevent1q…gqts
Author Public Key
npub18g04tf4qudcsna6qfcrm55s39axx3ymrunr65gxen4rctm0zv24sasgac3Published at
2023-06-07 18:13:03Event JSON
{
"id": "a2de812ff76e1804dafaae835cb2bfa2f87e517f72b1946514a2c3f4d090ec6e",
"pubkey": "3a1f55a6a0e37109f7404e07ba52112f4c689363e4c7aa20d99d4785ede262ab",
"created_at": 1686161583,
"kind": 1,
"tags": [
[
"e",
"cde3c2f1af5ec4e3200e32c7fdbcba54b58741a9d65d38dd383e78325ee0ffcd",
"",
"root"
],
[
"e",
"ed0b557d3844ce8bf674c3a0b570beb625e5d3c2aa0a3724dabb60c8683ebd09",
"",
"reply"
],
[
"p",
"9a463e0fab8963b013698c15a0f2449d19c97f3b88458e5874095b5006df9a0c"
]
],
"content": "📅 Original date posted:2018-06-19\n📝 Original message:Hello,\n\nFirst of all, we'd like to apologize for such a late feedback, since\nthere is a PR for this already. We've come up with a few more notes on\nthis, so we are introducing those in this message and replying on\nPieter's points in another one.\n\n\n1) Why isn't the global type 0x03 (BIP-32 path) per-input? How do we\nknow, which BIP-32 path goes to which input? The only idea that comes to\nmy mind is that we should match the input's scriptPubKey's pubkey to\nthis 0x03's key (the public key).\n\nIf our understanding is correct, the BIP-32 path is global to save space\nin case two inputs share the same BIP-32 path? How often does that\nhappen? And in case it does, doesn't it mean an address reuse which is\ndiscouraged?\n\nAlso, we believe that if the public key is to be used as \"spent to by an\noutput\" it should be in an output section. If the public key is to be\nused to sign an input, it should be in the input section. Again, how\noften are those the same? We understand creating another section might\nbe cumbersome, but it'd significantly increase clarity to have global,\ninput and output section.\n\nAlternately, we could keep “spend to” public keys in the global section,\nand put the input public keys to the per-input sections. This is less\nclear, but doesn’t introduce another section. A question to consider is,\nwill there be more per-output data? If yes, it might make sense to have\nan output section.\n\n\n2) The global items 0x01 (redeem script) and 0x02 (witness script) are\nsomewhat confusing. Let's consider only the redeem script (0x01) to make\nit simple. The value description says: \"A redeem script that will be\nneeded to sign a Pay-To-Script-Hash input or is spent to by an output.\".\nDoes this mean that the record includes both input's redeem script\n(because we need to sign it), but also a redeem script for the output\n(to verify we are sending to a correct P2SH)? To mix those two seems\nreally confusing.\n\nYet again, adding a new output section would make this more readable. We\nwould include the input’s redeem script in the input section and the\noutput’s redeem script again in the output section, because they’ll most\nlikely differ anyway.\n\nThe rationale says that the scripts are global to avoid duplication.\nHowever, how often is this the case? The scripts include a hash of some\nOP codes and the recipient's public key for example. So a) how often are\ntwo scripts equal to justify this? b) if they're the same, doesn't it\nyet again signalize address reuse?\n\n\n3) The sighash type 0x03 says the sighash is only a recommendation. That\nseems rather ambiguous. If the field is specified shouldn't it be binding?\n\n\n4) Is it a good idea to skip records which types we are unaware of? We\ncan't come up with a reasonable example, but intuitively this seems as a\npotential security issue. We think we should consider introducing a\nflag, which would define if the record is \"optional\". In case the signer\nencounters a record it doesn't recognize and such flag is not set, it\naborts the procedure. If we assume the set model we could change the\nstructure to \u003ctype\u003e\u003coptional flag\u003e\u003clength\u003e{data}. We are not keen on\nthis, but we wanted to include this idea to see what you think.\n\n-----------\n\nIn general, the standard is trying to be very space-conservative,\nhowever is that really necessary? We would argue for clarity and ease of\nuse over space constraints. We think more straightforward approach is\ndesired, although more space demanding. What are the arguments to make\nthis as small as possible? If we understand correctly, this format is\nnot intended for blockchain nor for persistent storage, so size doesn’t\nmatter nearly as much.\n\n\nThank you,\n\nTomas Susanka\nJan Matejek\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 819 bytes\nDesc: OpenPGP digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180619/57fc30e2/attachment.sig\u003e",
"sig": "1855981f626f4c7c906627efb69b93887c6f205ba1ca03040c64e08ed9858f7516f0592999dc0112645eefcb357ee9a7bb435b026dc2e88f6fe59140c753fe40"
}