{"type":"rich","version":"1.0","title":"Pieter Wuille [ARCHIVE] wrote","author_name":"Pieter Wuille [ARCHIVE] (npub1tj…jtl6r)","author_url":"https://yabu.me/npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6r","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2018-06-22\n📝 Original message:On Thu, Jun 21, 2018 at 12:56 PM, Peter D. Gray via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e I have personally implemented this spec on an embedded micro, as\n\u003e the signer and finalizer roles, and written multiple parsers for\n\u003e it as well. There is nothing wrong with it, and it perfectly meets\n\u003e my needs as a hardware wallet.\n\nThis is awesome to hear. We need to hear from people who have comments\nor issues they encounter while implementing, but also cases where\nthings are fine as is.\n\n\u003e So, there is a good proposal already spec'ed and implemented by\n\u003e multiple parties. Andrew has been very patiently shepherding the PR\n\u003e for over six months already.\n\u003e\n\u003e PSBT is something we need, and has been missing from the ecosystem\n\u003e for a long time. Let's push this out and start talking about future\n\u003e versions after we learn from this one.\n\nI understand you find the suggestions being brought up in this thread\nto be bikeshedding over details, and I certainly agree that \"changing\nX will gratuitously cause us more work\" is a good reason not to make\nbreaking changes to minutiae. However, at least abstractly speaking,\nit would be highly unfortunate if the fact that someone implemented a\ndraft specification results in a vested interest against changes which\nmay materially improve the standard.\n\nIn practice, the process surrounding BIPs' production readiness is not\nnearly as clear as it could be, and there are plenty of BIPs actually\ndeployed in production which are still marked as draft. So in reality,\ntruth is that this thread is \"late\", and also why I started the\ndiscussion by asking what the state of implementations was. As a\nresult, the discussion should be \"which changes are worth the hassle\",\nand not \"what other ideas can we throw in\" - and some of the things\nbrought up are certainly the latter.\n\nSo to get back to the question what changes are worth the hassle - I\nbelieve the per-input derivation paths suggested by matejcik may be\none. As is written right now, I believe BIP174 requires Signers to\npretty much always parse or template match the scripts involved. This\nmeans it is relatively hard to implement a Signer which is compatible\nwith many types of scripts - including ones that haven't been\nconsidered yet. However, if derivation paths are per-input, a signer\ncan just produce partial signatures for all keys it has the master\nfor. As long as the Finalizer understands the script type, this would\nmean that Signers will work with any script. My guess is that this\nwould be especially relevant to devices where the Signer\nimplementation is hard to change, like when it is implemented in a\nhardware signer directly.\n\nWhat do you think?\n\nCheers,\n\n-- \nPieter"}