📅 Original date posted:2016-08-17
📝 Original message:Hi all
Thanks for the response.
Jochen's points:
===============
Indeed. There are some missing points and I'd like to work this into the
BIP. Thanks for bringing this up.
Along with a support for wallet-creation with a xpub from the signing
device, we might also want to support loading multiple pubkeys into a
keypool from the device (in case someone likes to use hardened
derivation at all levels). I guess this would not be over-complex to
achieve.
Luke's points:
=============
USB / Plugin/Driver problematic
-------------------------------
I don't think it would be wise to set Trezors USB communication
(hardware interface) as "the standard". A) A USB stack/interaction in
wallets should be avoided IMO. B) This approach won't work for some
platforms (like iOS) due to technical and legal restrictions.
In my opinion, each hardware wallet has to provide custom software in
any case. We don't want to standardize how a hardware wallet has to do
backups, recovers, firmware upgrade, etc. and if we agree on that, then
hardware wallets must provide an application (mostly Chrome extensions
today) to implement theses processes.
Also diversity at the hardware interface will reduce centralized risks
for weak security/vulnerabilities.
The proposed URI scheme approach does not require any sorts of
libraries/dependencies. USB HID can be a problem for cross platform
desktop wallets as well as it won't work of one of the major mobile
platform (iOS). USB HID interaction can be restricted or disabled in non
superuser setups where I'm not aware of any restriction on URI-Scheme level.
URI scheme instead of stdio/pipe
--------------------------------
The URI scheme is not ugly. Its a modern way – implemented in almost all
platforms – how applications can interact with each other while not
directly knowing each other. Registering a URI scheme like "bitcoin://"
has some concrete advantages over just piping through stdio.
Also, the stdio/piping approach does not work for mobile platforms
(where the URI scheme works).
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).
Thomase D.'s points:
===================
Standardizing to many layers of the interaction stack (including the
hardware interaction) will very likely result in vendors not sticking to
the standard.
I agree, the URI scheme has some fragility, but at a level where we can
handle it and with the advantage of abstracting the used brand/device
for privacy and security reasons.
> The existing URI scheme, while allowing disambiguate by manufacturer,
provides no way to to enumerate available manufacturers or enabled
wallets.
Most operating systems allow to check if a certain URL-Scheme is
supported (registered), this would allow at least to check for known
major vendors (like trezor, etc.) which should solve most
multi-hardware-wallet use-cases.
The URI return scheme does work fine and with the correct set timeouts
it should result in a neat user experience.
It's the proposed way of application intercommunication in Apple iOS [1]
and Google Android [2].
Conclusion:
===========
* Non of the points convinced me that there is a better alternative to
the proposed URI scheme interaction (please tell me if I'm stubborn).
* Also, we should move the end users UX in the center of the
problems-to-solve (and not overweight the ideal
code-/API-/hardware-interaction-design while ignoring the end user
experience).
* We should try to not over-standardize the interaction with the device
itself to allow flexibility on the hardware wallet vendor side.
[1]
https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/Inter-AppCommunication/Inter-AppCommunication.html
[2] https://developer.android.com/training/basics/intents/sending.html
</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/63e4d8a4/attachment-0001.sig>;
Jonas Schnelli [ARCHIVE] /
npub1nf…3dtxs
2023-06-07 17:52:49
in reply to nevent1q…rrll
Author Public Key
npub1nfrrurat393mqymf3s26pujyn5vujlem3pzcukr5p9d4qpklngxq43dtxsPublished at
2023-06-07 17:52:49Event JSON
{
"id": "636356ed6a2f7236276b06848c663a5f0b415520ca4f191f0ad7276df1d4dc34",
"pubkey": "9a463e0fab8963b013698c15a0f2449d19c97f3b88458e5874095b5006df9a0c",
"created_at": 1686160369,
"kind": 1,
"tags": [
[
"e",
"6e7f7cb2c3110cb7289a3abd667304a3b4e6f9ba4e2581c492d7b93c214a5ea1",
"",
"root"
],
[
"e",
"aca229e760b02b1f0b74cb9492dcf4c9599231e634f9c9655c217a497d1db160",
"",
"reply"
],
[
"p",
"cd7a2cba8fb58a6131210185f2257692f56b666fb24bf9cf016ca8aaa4a4ae01"
]
],
"content": "📅 Original date posted:2016-08-17\n📝 Original message:Hi all\n\nThanks for the response.\n\n\nJochen's points:\n===============\nIndeed. There are some missing points and I'd like to work this into the\nBIP. Thanks for bringing this up.\n\nAlong with a support for wallet-creation with a xpub from the signing\ndevice, we might also want to support loading multiple pubkeys into a\nkeypool from the device (in case someone likes to use hardened\nderivation at all levels). I guess this would not be over-complex to\nachieve.\n\nLuke's points:\n=============\n\nUSB / Plugin/Driver problematic\n-------------------------------\nI don't think it would be wise to set Trezors USB communication\n(hardware interface) as \"the standard\". A) A USB stack/interaction in\nwallets should be avoided IMO. B) This approach won't work for some\nplatforms (like iOS) due to technical and legal restrictions.\n\nIn my opinion, each hardware wallet has to provide custom software in\nany case. We don't want to standardize how a hardware wallet has to do\nbackups, recovers, firmware upgrade, etc. and if we agree on that, then\nhardware wallets must provide an application (mostly Chrome extensions\ntoday) to implement theses processes.\n\nAlso diversity at the hardware interface will reduce centralized risks\nfor weak security/vulnerabilities.\n\nThe proposed URI scheme approach does not require any sorts of\nlibraries/dependencies. USB HID can be a problem for cross platform\ndesktop wallets as well as it won't work of one of the major mobile\nplatform (iOS). USB HID interaction can be restricted or disabled in non\nsuperuser setups where I'm not aware of any restriction on URI-Scheme level.\n\nURI scheme instead of stdio/pipe\n--------------------------------\nThe URI scheme is not ugly. Its a modern way – implemented in almost all\nplatforms – how applications can interact with each other while not\ndirectly knowing each other. Registering a URI scheme like \"bitcoin://\"\nhas some concrete advantages over just piping through stdio.\n\nAlso, the stdio/piping approach does not work for mobile platforms\n(where the URI scheme works).\n\nThe URI scheme does not require any sorts of wallet app level\nconfiguration (where the stdio/pipe approach would require to configure\nsome details about the used hardware wallet).\n\n\nThomase D.'s points:\n===================\nStandardizing to many layers of the interaction stack (including the\nhardware interaction) will very likely result in vendors not sticking to\nthe standard.\n\nI agree, the URI scheme has some fragility, but at a level where we can\nhandle it and with the advantage of abstracting the used brand/device\nfor privacy and security reasons.\n\n\u003e The existing URI scheme, while allowing disambiguate by manufacturer,\nprovides no way to to enumerate available manufacturers or enabled\nwallets.\n\nMost operating systems allow to check if a certain URL-Scheme is\nsupported (registered), this would allow at least to check for known\nmajor vendors (like trezor, etc.) which should solve most\nmulti-hardware-wallet use-cases.\n\nThe URI return scheme does work fine and with the correct set timeouts\nit should result in a neat user experience.\nIt's the proposed way of application intercommunication in Apple iOS [1]\nand Google Android [2].\n\nConclusion:\n===========\n* Non of the points convinced me that there is a better alternative to\nthe proposed URI scheme interaction (please tell me if I'm stubborn).\n* Also, we should move the end users UX in the center of the\nproblems-to-solve (and not overweight the ideal\ncode-/API-/hardware-interaction-design while ignoring the end user\nexperience).\n* We should try to not over-standardize the interaction with the device\nitself to allow flexibility on the hardware wallet vendor side.\n\n[1]\nhttps://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/Inter-AppCommunication/Inter-AppCommunication.html\n[2] https://developer.android.com/training/basics/intents/sending.html\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/63e4d8a4/attachment-0001.sig\u003e",
"sig": "65bee4fc239ea7b85d2d43feff2772cd70c40a97a7a28de1eedf7c4ff2fc2425d4036a8596e46a5a54485909a37f528c92dc76eb8d95bd721d68b34095dc49f8"
}