{"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-21\n📝 Original message:On 19.6.2018 19:16, Pieter Wuille wrote:\n\u003e\u003e 1) Why isn't the global type 0x03 (BIP-32 path) per-input? How do we\n\u003e\u003e know, which BIP-32 path goes to which input? The only idea that comes to\n\u003e\u003e my mind is that we should match the input's scriptPubKey's pubkey to\n\u003e\u003e this 0x03's key (the public key).\n\u003e \n\u003e\u003e If our understanding is correct, the BIP-32 path is global to save space\n\u003e\u003e in case two inputs share the same BIP-32 path? How often does that\n\u003e\u003e happen? And in case it does, doesn't it mean an address reuse which is\n\u003e\u003e discouraged?\n\u003e \n\u003e Yes, the reason is address reuse. It may be discouraged, but it still\n\u003e happens in practice (and unfortunately it's very hard to prevent\n\u003e people from sending to the same address twice).\n\u003e \n\u003e It's certainly possible to make them per-input (and even per-output as\n\u003e suggested below), but I don't think it gains you much. At least when a\n\u003e signer supports any kind of multisig, it needs to match up public keys\n\u003e with derivation paths. If several can be provided, looking them up\n\u003e from a global table or a per-input table shouldn't fundamentally\n\u003e change anything.\n\nSo here’s a thing I’m still confused about.\n\nImagine two cases, for a naive Signer:\n- either all data is global\n- or most data is per input.\n\nNow, the general signing flow is this:\n1. Pre-serialize the transaction\n2. Prepare the current input - fill out scriptPubKey (or equivalent for\nsegwit)\n3. find a secret key\n4. output public key + signature\n\nStep (3) is the main issue here.\n\nIn the case of everything per-input, the naive Signer can do this:\n1. (in the global section) pre-serialize the transaction\n2. (in each input) find and fill out scriptPubKey from the provided UTXO\n3. (for a given BIP32 path) check if the master fingerprint matches\nmine, if yes, derive secret key, output pubkey, signature\n4. goto 3 (more keys per input), goto 2 (next input)\n\nNote that this flow works perfectly for multisig; it’s going to be the\njob of a Finalizer to build the final scriptSig, but each input can have\nmultiple partial signatures -- and, interestingly, the naive Signer\ndoesn’t even need to know about multisig.\n\nA less naive Signer will want to check things, maybe derive a scriptSig\nitself and check if it matches the given hash, etc., but it can do this\nall in place. You go linearly through the signing flow and place a\ncouple strategic assertions along the way.\n\nHowever, if the data is global, as is now, it gets more complicated:\n1. (in the global section) pre-serialize the transaction, prefill lookup\ntables\n2. (for a given BIP32 path) check if mine, then derive public key and\nstore in a dictionary\n3. (for each input) find _and parse_ scriptPubKey, extract (PK or)\nscript hash\n4. lookup redeem script based on script-hash; if not found, goto 2; if\nfound, parse out public key\n5. lookup public key in the BIP32 dictionary; if not found, goto 2\n6. output pubkey, signature\n\nIn addition to being more steps and lookups, it requires the Signer to\nunderstand the redeem script. A strict Signer will want that anyway, but\nin the first case, the Signer can regenerate the scripts and compare\nspecificaly the ones it's working with; here, you need to parse them\neven before you know what you're comparing to.\n\nIs there something I’m missing? Because as I see it, there is literally\nno advantage to the more complicated flow; that’s why we assumed that\nthe format is space-saving, because saving space was the only reason we\ncould imagine.\n\n\u003e If we go down this route, if a field is marked as mandatory, can you\n\u003e still act as a combiner for it? Future extensions should always\n\u003e maintain the invariant that a simple combiner which just merges all\n\u003e the fields and deduplicates should always be correct, I think. So such\n\u003e a mandatory field should only apply to signers?\n\n(...)\n\n\u003e However, perhaps we do want to enforce at-most one UTXO per input. If\n\u003e there are more potential extensions like this, perhaps a key-value\n\u003e model is better, as it's much easier to enforce no duplicate keys than\n\u003e it is to add field-specific logic to combiners (especially for\n\u003e extensions they don't know about yet).\n\nIn general, you seem to focus a lot on the role of Combiners, esp.\nsimple Combiners. To me, that doesn’t look like a significant role. As I\nenvision it, a Combiner really doesn’t need to do anything more\ncomplicated than merge and deduplicate records, simply based on the\nuniqueness of the whole record.\nIt’s the Finalizer’s job to reconstruct and validate the result. Also\nISTM if something messes up the PSBT (such as including multiple\nconflicting fields anywhere), it’s OK to leave it to Finalizer to fail.\n\nAre the Combiners supposed to be separate from Finalizers? (Is there a\nrisk of a Combiner passing along a bad PSBT, Finalizer rejecting it, and\nthe other parties not finding out?)\n\n\n\u003e If we go with the \"not put signatures/witnesses inside the transaction\n\u003e until all of them are finalized\" suggestion, perhaps the number of\n\u003e inputs field can be dropped. There would be always one exactly for\n\u003e each input (but some may have the \"final script/witness\" field and\n\u003e others won't).\n\nStrongly agree with this. A guarantee that number of inputs in the\ntransaction corresponds to number of input fields for PBST looks cleaner\nthan specifying it separately. This way we can also drop the \"input index\".\n\n\n\u003e Right now, the BIP32 fields are of the form \u003cmaster\n\u003e fingerprint\u003e\u003cchildidx\u003e\u003cchildidx\u003e\u003cchildidx\u003e...\n\u003e \n\u003e Instead, I suggest fields of the form \u003cmaster pubkey\u003e\u003cmaster\n\u003e chaincode\u003e\u003cchildidx\u003e\u003cchildidx\u003e\u003cchildidx\u003e...\n\u003e \n\u003e The fingerprint in this case is identical to the first 32 bit of the\n\u003e Hash160 of \u003cmaster pubkey\u003e, so certainly no information is lost by\n\u003e making this change.\n\u003e \n\u003e This may be advantageous for three reasons:\n\u003e * It permits signers to have ~thousands of master keys (at which point\n\u003e 32-bit fingerprints would start having reasonable chance for\n\u003e collisions, meaning multiple derivation attempts would be needed to\n\u003e figure out which one to use).\n\u003e * It permits signers to index their master keys by whatever they like\n\u003e (for example, SHA256 rather than Hash160 or prefix thereof)\u003e * It permits signers who don't store a chaincode at all, and just\n\u003e protect a single private key.\n\nI like this last usecase a lot, but perhaps that's a role for a\n\"sub-Creator\"? see below.\n\nAlso, is there a reason to publish the chain code, wouldn't just the\npublic key be sufficient to accomplish all three usecases you list?\nI sort of dislike the notion that you need to give all this information\nto a possibly untrusted Creator.\n\n\nAn aside to this in particular, I’ve been thinking about the requirement\nto share derivation paths and public keys with the Creator. The spec\nassumes that this will happen; you’re talking about providing full\nxpub+chaincode too. At least, the Creator must prefill BIP32 paths and\nmaster key fingerprints. Possibly also prefill public keys in the redeem\nscripts?\n\nThis might not be an improvement proposal, but a point worth being\nraised and maybe explained in the spec. Perhaps the original Creator\ndoesn’t have access to this data, and delegates this to some\n“sub-Creators”  - I imagine a coordinator sending a PSBT to signing\nparties, each of which acts as a sub-Creator (fills out derivation paths\nand public keys) and a Signer (forwarding to a HWW). Some of the\ndiscussion even suggests some sort of generic “key derivation field”\nwith arbitrary contents - fingerprint + bip32 path? xpub + chain code?\nderivation points? encrypted xprv?\n\nthank you for your comments\n\nregards\nm.\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/20180621/92c941f5/attachment-0001.sig\u003e"}