Pieter Wuille [ARCHIVE] on Nostr: 📅 Original date posted:2018-06-22 📝 Original message:On Thu, Jun 21, 2018 at ...
📅 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
Published at
2023-06-07 18:13:09Event JSON
{
"id": "5b1fe421fe9fbf3314561ba471e465436416bc496d8580befa71b6ac4b87c0df",
"pubkey": "5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6",
"created_at": 1686161589,
"kind": 1,
"tags": [
[
"e",
"cde3c2f1af5ec4e3200e32c7fdbcba54b58741a9d65d38dd383e78325ee0ffcd",
"",
"root"
],
[
"e",
"f46351424515f8608d675918f68bc053397a4d9cec3b15077cd0b21b7af2c84d",
"",
"reply"
],
[
"p",
"4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73"
]
],
"content": "📅 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",
"sig": "d74a44b276605fbd9962e1018566e9dad802ba345a68f4d004833c0d2d4de245684326eb6bbb5b266fd63361397877d9601de2e622dbae25dd9fd03b87fc569d"
}