đź“… Original date posted:2016-08-17
đź“ť Original message:Hi,
I fundamentally disagree with the concept of driving signing workflow by
the wallet software. Wallet software does not know in advance all data
necessary for the signer to do the job. As Jochen mentioned above, Segwit
vs Non-segwit use cases are a good example, but there may be many.
Currently the TREZOR protocol works like device is a server and wallet is a
client calling methods on it. It's like: "Sign this for me, please", "Ok,
give me this information", "Here it is", "Now I need this another
piece".... "There is the signature". Wallet does not know in advance what
will go next, and it is for sake of simplicity. I'm quite happy with the
protocol so far.
Considering the difference in between current hardware, I really don't
think it is possible to find any minimal URI-based API good enough for
communicating with all vendors. What I see more likely is some 3rd party
libraries (JS, C++, Python, ...) defining high-level API and implementing
hardware-specific protocols and transports as plugins. That way vendors are
not limited by strict standard and application developers and services can
integrate wide range of hardware wallets easily. However, this can be done
already and we do not need any standardization process (yet).
slush
On Wed, Aug 17, 2016 at 1:34 PM, Jonas Schnelli via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi Dana
>
> >> The URI scheme does not require any sorts of wallet app level
> >> configuration (where the stdio/pipe approach would require to configure
> >> some details about the used hardware wallet).
> >
> > Hi everybody, just thought I’d throw my opinion in here.
> >
> > The URI scheme is a nice idea, but this ignores the fact that hardware
> wallet vendors do most of the work on talking between the computer/mobile
> and the wallet on a lower level of communication. In the case of BitLox,
> the base protocol is Google’s ProtoBuf. The commands and transaction data
> is in a “schema” which is then encoded in different methods accessible via
> ProtoBuf (depending on the data being sent). The advantages of this
> protocol is that it can be implemented on a wide variety of platforms. (but
> that’s a whole 'nother discussion)
> >
> > The URI would be handled waaaaay up in the specific application (such as
> the mytrezor wallet software or the various standalone wallets) - nowhere
> near the actual hardware communications layer.
>
> This is maybe a question of the scope.
> The BIP I'm proposing would make a clear interface cut between
> wallet-with-unsigned-transaction and a signing-device (and maybe between
> wallet-requires-pubkey, signing-device generate some pubkeys [or
> non-hardened xpub]).
>
> The detached-signing proposal does not duplicate work. It just moves the
> current plugin design into a separate application. Plugins in security
> and privacy critical wallet software is something that should probably
> be avoided.
>
> It's intentional at a high level to allow maximum flexibility at the
> hardware interaction layer.
>
> Your protobuf example is a good use-case. You could implement your
> custom processes behind the URI scheme (which is probably way more
> efficient then writing a couple of wallet plugins where you – at the end
> – mostly don't control the deployment and the source-code).
>
> Defining a standard on the hardware interaction layer is possible, but a
> fairly different approach.
>
> </jonas>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160817/136eadac/attachment.html>;
Marek Palatinus [ARCHIVE] /
npub1xt…acz68
2023-06-07 17:52:50
in reply to nevent1q…x79g
Author Public Key
npub1xtqansnal58rjnnxvyke6kzuvxsz0twg4456awy6ff0525yqgjxqjacz68Seen on
wss://relay.nostr.bandPublished at
2023-06-07 17:52:50Event JSON
{
"id": "eec1541da6bc79147b17892dc384bfa76b81a576f5abb18643d3c38c385adc0e",
"pubkey": "32c1d9c27dfd0e394e66612d9d585c61a027adc8ad69aeb89a4a5f455080448c",
"created_at": 1686160370,
"kind": 1,
"tags": [
[
"e",
"6e7f7cb2c3110cb7289a3abd667304a3b4e6f9ba4e2581c492d7b93c214a5ea1",
"",
"root"
],
[
"e",
"fff0d875a845871bc181eb1d4d69695d4d5a9574907a8ee645da02bc44bef6c0",
"",
"reply"
],
[
"p",
"9a463e0fab8963b013698c15a0f2449d19c97f3b88458e5874095b5006df9a0c"
]
],
"content": "📅 Original date posted:2016-08-17\n📝 Original message:Hi,\n\nI fundamentally disagree with the concept of driving signing workflow by\nthe wallet software. Wallet software does not know in advance all data\nnecessary for the signer to do the job. As Jochen mentioned above, Segwit\nvs Non-segwit use cases are a good example, but there may be many.\n\nCurrently the TREZOR protocol works like device is a server and wallet is a\nclient calling methods on it. It's like: \"Sign this for me, please\", \"Ok,\ngive me this information\", \"Here it is\", \"Now I need this another\npiece\".... \"There is the signature\". Wallet does not know in advance what\nwill go next, and it is for sake of simplicity. I'm quite happy with the\nprotocol so far.\n\nConsidering the difference in between current hardware, I really don't\nthink it is possible to find any minimal URI-based API good enough for\ncommunicating with all vendors. What I see more likely is some 3rd party\nlibraries (JS, C++, Python, ...) defining high-level API and implementing\nhardware-specific protocols and transports as plugins. That way vendors are\nnot limited by strict standard and application developers and services can\nintegrate wide range of hardware wallets easily. However, this can be done\nalready and we do not need any standardization process (yet).\n\nslush\n\nOn Wed, Aug 17, 2016 at 1:34 PM, Jonas Schnelli via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Hi Dana\n\u003e\n\u003e \u003e\u003e The URI scheme does not require any sorts of wallet app level\n\u003e \u003e\u003e configuration (where the stdio/pipe approach would require to configure\n\u003e \u003e\u003e some details about the used hardware wallet).\n\u003e \u003e\n\u003e \u003e Hi everybody, just thought I’d throw my opinion in here.\n\u003e \u003e\n\u003e \u003e The URI scheme is a nice idea, but this ignores the fact that hardware\n\u003e wallet vendors do most of the work on talking between the computer/mobile\n\u003e and the wallet on a lower level of communication. In the case of BitLox,\n\u003e the base protocol is Google’s ProtoBuf. The commands and transaction data\n\u003e is in a “schema” which is then encoded in different methods accessible via\n\u003e ProtoBuf (depending on the data being sent). The advantages of this\n\u003e protocol is that it can be implemented on a wide variety of platforms. (but\n\u003e that’s a whole 'nother discussion)\n\u003e \u003e\n\u003e \u003e The URI would be handled waaaaay up in the specific application (such as\n\u003e the mytrezor wallet software or the various standalone wallets) - nowhere\n\u003e near the actual hardware communications layer.\n\u003e\n\u003e This is maybe a question of the scope.\n\u003e The BIP I'm proposing would make a clear interface cut between\n\u003e wallet-with-unsigned-transaction and a signing-device (and maybe between\n\u003e wallet-requires-pubkey, signing-device generate some pubkeys [or\n\u003e non-hardened xpub]).\n\u003e\n\u003e The detached-signing proposal does not duplicate work. It just moves the\n\u003e current plugin design into a separate application. Plugins in security\n\u003e and privacy critical wallet software is something that should probably\n\u003e be avoided.\n\u003e\n\u003e It's intentional at a high level to allow maximum flexibility at the\n\u003e hardware interaction layer.\n\u003e\n\u003e Your protobuf example is a good use-case. You could implement your\n\u003e custom processes behind the URI scheme (which is probably way more\n\u003e efficient then writing a couple of wallet plugins where you – at the end\n\u003e – mostly don't control the deployment and the source-code).\n\u003e\n\u003e Defining a standard on the hardware interaction layer is possible, but a\n\u003e fairly different approach.\n\u003e\n\u003e \u003c/jonas\u003e\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160817/136eadac/attachment.html\u003e",
"sig": "f8bcb1acc87ad5a53e3e88725d931be8dba35ccc5029114e5f58ae1d17251c199e3818e164f1fb374a37ca6b7cd72e6102aba26533a03a6c700c3d206f281bf3"
}