📅 Original date posted:2016-08-18
📝 Original message:Hi
> The main benefit is that you don't need "standard" to solve problem, but
> use natural tools in given environment and programming stack. Build a
> "standard" on top of URI protocol is a huge limitation, which does not
> give any advantage.
Standards can help an ecosystem to grow, can help to sustain a good user
experience.
The hardware wallet vendors have used "natural tools" and look where we
are. We have *native* plugins in Electrum, Copay, etc. for different
hardware wallets. Mostly the plugins are in the code base of the wallet,
which makes it – in theory – impossible to change from the perspective
of the hardware wallet vendor (there is no control of the deployment if
there are bugs in the plugins code).
The plugins functions overlap significant.
I think this is a bad design for security critical applications.
What I want as hardware wallet user:
* I'd like to have a trusted application (layer) where I'm sure I'm
using software provided through my hardware wallet vendor.
What I want as hardware wallet vendor:
* I'd like to be able to provide and update a software layer (app) to my
customer with the ability to provide code signatures and security
updates anytime. I do want to control the user experience.
> We already see issues with dead simple "bitcoin uri" standard, it barely
> works in most of bitcoin apps. Think of vague definitions of parameters
> or ability to send payment requests over it. HW API would be complicated
> by an order of magnitude and I have serious concerns that it will be
> helpful for anything. So why complicate things.
As far as I know most bitcoin wallets do support the bitcoin:// URI
scheme quite well.
I agree that BIP70 is a mess (including the bitcoin:// additions).
The proposed URI scheme would be completely different. The only
similarity is using the URI scheme as transport layer (which is the
proposed long term inter-app communication layer by Apple and Google).
>> How would the library approach work on mobile platforms? Would USB be
> the only supported hardware communication layer?
>
> Interprocess communication/libraries/dependencies on Android are not
> bound to specific transport anyhow. Such library could be used by any
> android app, and the library would implement proper transports for
> various supported vendors. USB for Trezor, NFC for something different
> etc. If the point is "make life of app developers easier", let's do this
> and do not define artifical "standards".
So you propose having one library that would support multiple vendors?
What if new vendors add a new transport layer (lets assume NFC or
Bluetooth), wouldn't that result in every possible consumer of that
library (all wallets) need to update before the new vendors transport
layer could be used, resulting in a huge deployment process probably
require many month until it can be used?
What if there is a critical security issue in the library? How would the
deployment plan looks like?
I really think we should remove the "hardware communication layer" from
wallets and move it towards the hardware vendor app.
What about iOS? Should we just leave that platform unsupported with
hardware wallets?
</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/20160818/ca1a24d9/attachment.sig>;
Jonas Schnelli [ARCHIVE] /
npub1nf…3dtxs
2023-06-07 17:52:51
in reply to nevent1q…zydk
Author Public Key
npub1nfrrurat393mqymf3s26pujyn5vujlem3pzcukr5p9d4qpklngxq43dtxsPublished at
2023-06-07 17:52:51Event JSON
{
"id": "37d77aaaa473003b3aa248d87a9a6cebcdf4968d3ee17ff3da06b2f72e589036",
"pubkey": "9a463e0fab8963b013698c15a0f2449d19c97f3b88458e5874095b5006df9a0c",
"created_at": 1686160371,
"kind": 1,
"tags": [
[
"e",
"6e7f7cb2c3110cb7289a3abd667304a3b4e6f9ba4e2581c492d7b93c214a5ea1",
"",
"root"
],
[
"e",
"d71e61ade472b36098d4a795326d257ec0eecad53e12d9156d439f03cb7ee094",
"",
"reply"
],
[
"p",
"32c1d9c27dfd0e394e66612d9d585c61a027adc8ad69aeb89a4a5f455080448c"
]
],
"content": "📅 Original date posted:2016-08-18\n📝 Original message:Hi\n\n\u003e The main benefit is that you don't need \"standard\" to solve problem, but\n\u003e use natural tools in given environment and programming stack. Build a\n\u003e \"standard\" on top of URI protocol is a huge limitation, which does not\n\u003e give any advantage.\n\nStandards can help an ecosystem to grow, can help to sustain a good user\nexperience.\n\nThe hardware wallet vendors have used \"natural tools\" and look where we\nare. We have *native* plugins in Electrum, Copay, etc. for different\nhardware wallets. Mostly the plugins are in the code base of the wallet,\nwhich makes it – in theory – impossible to change from the perspective\nof the hardware wallet vendor (there is no control of the deployment if\nthere are bugs in the plugins code).\nThe plugins functions overlap significant.\n\nI think this is a bad design for security critical applications.\n\nWhat I want as hardware wallet user:\n* I'd like to have a trusted application (layer) where I'm sure I'm\nusing software provided through my hardware wallet vendor.\n\nWhat I want as hardware wallet vendor:\n* I'd like to be able to provide and update a software layer (app) to my\ncustomer with the ability to provide code signatures and security\nupdates anytime. I do want to control the user experience.\n\n\n\u003e We already see issues with dead simple \"bitcoin uri\" standard, it barely\n\u003e works in most of bitcoin apps. Think of vague definitions of parameters\n\u003e or ability to send payment requests over it. HW API would be complicated\n\u003e by an order of magnitude and I have serious concerns that it will be\n\u003e helpful for anything. So why complicate things.\n\nAs far as I know most bitcoin wallets do support the bitcoin:// URI\nscheme quite well.\nI agree that BIP70 is a mess (including the bitcoin:// additions).\n\nThe proposed URI scheme would be completely different. The only\nsimilarity is using the URI scheme as transport layer (which is the\nproposed long term inter-app communication layer by Apple and Google).\n\n\u003e\u003e How would the library approach work on mobile platforms? Would USB be\n\u003e the only supported hardware communication layer?\n\u003e \n\u003e Interprocess communication/libraries/dependencies on Android are not\n\u003e bound to specific transport anyhow. Such library could be used by any\n\u003e android app, and the library would implement proper transports for\n\u003e various supported vendors. USB for Trezor, NFC for something different\n\u003e etc. If the point is \"make life of app developers easier\", let's do this\n\u003e and do not define artifical \"standards\".\n\nSo you propose having one library that would support multiple vendors?\nWhat if new vendors add a new transport layer (lets assume NFC or\nBluetooth), wouldn't that result in every possible consumer of that\nlibrary (all wallets) need to update before the new vendors transport\nlayer could be used, resulting in a huge deployment process probably\nrequire many month until it can be used?\n\nWhat if there is a critical security issue in the library? How would the\ndeployment plan looks like?\n\nI really think we should remove the \"hardware communication layer\" from\nwallets and move it towards the hardware vendor app.\n\nWhat about iOS? Should we just leave that platform unsupported with\nhardware wallets?\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/20160818/ca1a24d9/attachment.sig\u003e",
"sig": "9a79876c21185385ba000112d0f0f30a2c73f645f2d6d33603cf8006c182a5ccabd9015980a611d69813a6315467d2dcaebe2fb921fc6d7ab4e7afd17c31001f"
}