Re: [bitcoin-dev] BIP 174 thoughts
Hi all, After reading the comments here about BIP 174, I would like to propose the following changes: - Moving redeemScripts, witnessScripts, and BIP 32 derivation paths to per-input and per-output data I think that by moving these three fields into input and output specific maps, the format will be easier to read and simpler for signers to parse. Instead of having to be able to parse entire scripts and extract pubkeys, the signer can simply look at which pubkeys are provided in the inputs and sign the input based upon the presence of a pubkey for which the signer has a privkey. A neat trick that fits well with this model is that a plain pubkey (one that is not part of a BIP 32 derivation) can still be put in a BIP 32 derivation path field where the value is just the fingerprint of the pubkey itself. This would indicate that no derivation needs to be done from the master key, and the master key is just the specified key itself. Additionally, by having the redeemScript and witnessScript readily available in the input, signers do not need to construct a map to find a redeemScript or witnessScript and can instead just look directly in the input data. There is also no need to include the hashes of these scripts, so the key is just the type. This also allows us to enforce the requirement for only one redeemScript and one witnessScript per input easily by continuing to follow the generic rule of unique keys. By using input specific and output specific fields, there is no need for the input index and the input count types as all inputs will be accounted for. - Finalized scriptSig and scriptWitness fields To determine whether two PSBTs are the same, we can compare the unsigned transaction. To ensure that the unsigned transactions are the same for two PSBTs with data for the same tx, we cannot put scriptSigs or scriptWitnesses into it. Thus for each input, two new fields have been added to store the finalized scriptSig and finalized scriptWitness. - Mandatory sighash The sighash type field will be changed from a recommendation to a requirement. Signatures will need to use the specified sighash type for that input. If a Signer cannot sign for a particular sighash type, it must not add a partial signature. - Encoding I have decided that PSBTs should either be in binary or encoded as a Base64 string. For the latter, several Bitcoin clients already support Base64 encoding of data (for signed messages) so this will not add any extra dependencies like Z85 would. A draft of the revised BIP can be found here: https://github.com/achow101/bips/blob/bip174-rev/bip-0174.mediawiki If these changes are satisfactory, I will open a PR to the BIPs repo to update the BIP tomorrow. I will also create test vectors and update the implementation PR'ed to Core. Andrew ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP 174 thoughts
On Thu, Jun 21, 2018 at 12:56 PM, Peter D. Gray via bitcoin-dev wrote: > I have personally implemented this spec on an embedded micro, as > the signer and finalizer roles, and written multiple parsers for > it as well. There is nothing wrong with it, and it perfectly meets > my needs as a hardware wallet. This is awesome to hear. We need to hear from people who have comments or issues they encounter while implementing, but also cases where things are fine as is. > So, there is a good proposal already spec'ed and implemented by > multiple parties. Andrew has been very patiently shepherding the PR > for over six months already. > > PSBT is something we need, and has been missing from the ecosystem > for a long time. Let's push this out and start talking about future > versions after we learn from this one. I understand you find the suggestions being brought up in this thread to be bikeshedding over details, and I certainly agree that "changing X will gratuitously cause us more work" is a good reason not to make breaking changes to minutiae. However, at least abstractly speaking, it would be highly unfortunate if the fact that someone implemented a draft specification results in a vested interest against changes which may materially improve the standard. In practice, the process surrounding BIPs' production readiness is not nearly as clear as it could be, and there are plenty of BIPs actually deployed in production which are still marked as draft. So in reality, truth is that this thread is "late", and also why I started the discussion by asking what the state of implementations was. As a result, the discussion should be "which changes are worth the hassle", and not "what other ideas can we throw in" - and some of the things brought up are certainly the latter. So to get back to the question what changes are worth the hassle - I believe the per-input derivation paths suggested by matejcik may be one. As is written right now, I believe BIP174 requires Signers to pretty much always parse or template match the scripts involved. This means it is relatively hard to implement a Signer which is compatible with many types of scripts - including ones that haven't been considered yet. However, if derivation paths are per-input, a signer can just produce partial signatures for all keys it has the master for. As long as the Finalizer understands the script type, this would mean that Signers will work with any script. My guess is that this would be especially relevant to devices where the Signer implementation is hard to change, like when it is implemented in a hardware signer directly. What do you think? Cheers, -- Pieter ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
