rich1.0Pieter Wuille [ARCHIVE] (npub1tj…jtl6r)https://yabu.me/npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6rnjumphttps://yabu.me📅 Original date posted:2018-06-22 📝 Original message:On Thu, Jun 21, 2018 at 12:56 PM, Peter D. Gray via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> 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