đź“… Original date posted:2016-08-17
đź“ť Original message: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>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160817/3eea9613/attachment-0001.sig>;
Jonas Schnelli [ARCHIVE] /
npub1nf…3dtxs
2023-06-07 17:52:50
in reply to nevent1q…rall
Author Public Key
npub1nfrrurat393mqymf3s26pujyn5vujlem3pzcukr5p9d4qpklngxq43dtxsPublished at
2023-06-07 17:52:50Event JSON
{
"id": "fff0d875a845871bc181eb1d4d69695d4d5a9574907a8ee645da02bc44bef6c0",
"pubkey": "9a463e0fab8963b013698c15a0f2449d19c97f3b88458e5874095b5006df9a0c",
"created_at": 1686160370,
"kind": 1,
"tags": [
[
"e",
"6e7f7cb2c3110cb7289a3abd667304a3b4e6f9ba4e2581c492d7b93c214a5ea1",
"",
"root"
],
[
"e",
"7c4134f2d6f87341f4f36166e73548271a5cbb249a4bd4624f6efc544b651e4e",
"",
"reply"
],
[
"p",
"52e94f94ac1e174297da4186b2b2817c713bdcb4bab28a9017d3c9f66ad24770"
]
],
"content": "📅 Original date posted:2016-08-17\n📝 Original message:Hi Dana\n\n\u003e\u003e The URI scheme does not require any sorts of wallet app level\n\u003e\u003e configuration (where the stdio/pipe approach would require to configure\n\u003e\u003e some details about the used hardware wallet).\n\u003e \n\u003e Hi everybody, just thought I’d throw my opinion in here.\n\u003e \n\u003e 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)\n\u003e \n\u003e 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.\n\nThis is maybe a question of the scope.\nThe BIP I'm proposing would make a clear interface cut between\nwallet-with-unsigned-transaction and a signing-device (and maybe between\nwallet-requires-pubkey, signing-device generate some pubkeys [or\nnon-hardened xpub]).\n\nThe detached-signing proposal does not duplicate work. It just moves the\ncurrent plugin design into a separate application. Plugins in security\nand privacy critical wallet software is something that should probably\nbe avoided.\n\nIt's intentional at a high level to allow maximum flexibility at the\nhardware interaction layer.\n\nYour protobuf example is a good use-case. You could implement your\ncustom processes behind the URI scheme (which is probably way more\nefficient then writing a couple of wallet plugins where you – at the end\n– mostly don't control the deployment and the source-code).\n\nDefining a standard on the hardware interaction layer is possible, but a\nfairly different approach.\n\n\u003c/jonas\u003e\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 819 bytes\nDesc: OpenPGP digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160817/3eea9613/attachment-0001.sig\u003e",
"sig": "d02d44d81b548aea74eaea959a962f5a413450bc84dfe6175ad05fce80dac4745a3abe9914f4fd19ab04cb1b1367e2a7b5bc0c937be2dd9fd94157cb47c17891"
}