{"type":"rich","version":"1.0","title":"matejcik [ARCHIVE] wrote","author_name":"matejcik [ARCHIVE] (npub18g…sgac3)","author_url":"https://yabu.me/npub18g04tf4qudcsna6qfcrm55s39axx3ymrunr65gxen4rctm0zv24sasgac3","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 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"}