📅 Original date posted:2016-08-18
📝 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.
I think this is easily solvable. The required data to verify and sign a
(standard) bitcoin transaction (including P2WSH multi-sig) is manageable.
IMO what a signing devices requires in order to sign a (standard)
transaction:
-> serialized tx
-> serialized tx of the inputs
-> scriptPubKey of the inputs
-> inputs redeem-Scripts
-> input amounts
-> position of the change output any maybe its keypath
-> cosigners pubkeys for inputs and changeaddress
This seems to be manageable for a 1 round communication?
Or do I miss something?
> 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.
I think multiple rounds would still be possible with a clever design.
Although I could imaging that >95% of the users transaction would
require only a single "shot".
Whats the benefits of the multiple rounds communication? Would a single
round result in to many data transported?
Passing a 300kb chunk (assuming a large transaction) over a URI scheme
requires a couple of milliseconds on standard Smartphones or PCs.
> 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).
The URI-based API allows transmitting data of multiple megabytes while
there is no need for...
* dependencies of any form (library, etc.)
* library support for a particular language
* platform that supports the dependencies of the library (like USBHID,
not supported by iOS)
Can you elaborate what benefits you would get from the library approach
and how the library API would be different form the proposed URI-scheme?
How would the library approach work on mobile platforms? Would USB be
the only supported hardware communication layer?
Thanks
--
</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/5ae29972/attachment.sig>;
Jonas Schnelli [ARCHIVE] /
npub1nf…3dtxs
2023-06-07 17:52:50
in reply to nevent1q…vpsv
Author Public Key
npub1nfrrurat393mqymf3s26pujyn5vujlem3pzcukr5p9d4qpklngxq43dtxsPublished at
2023-06-07 17:52:50Event JSON
{
"id": "79ba2c8ef9e8535baedefbaf12f418d1bc829a6d15e85a7f94b2126db0764ad2",
"pubkey": "9a463e0fab8963b013698c15a0f2449d19c97f3b88458e5874095b5006df9a0c",
"created_at": 1686160370,
"kind": 1,
"tags": [
[
"e",
"6e7f7cb2c3110cb7289a3abd667304a3b4e6f9ba4e2581c492d7b93c214a5ea1",
"",
"root"
],
[
"e",
"eec1541da6bc79147b17892dc384bfa76b81a576f5abb18643d3c38c385adc0e",
"",
"reply"
],
[
"p",
"32c1d9c27dfd0e394e66612d9d585c61a027adc8ad69aeb89a4a5f455080448c"
]
],
"content": "📅 Original date posted:2016-08-18\n📝 Original message:Hi\n\n\u003e I fundamentally disagree with the concept of driving signing workflow by\n\u003e the wallet software. Wallet software does not know in advance all data\n\u003e necessary for the signer to do the job. As Jochen mentioned above,\n\u003e Segwit vs Non-segwit use cases are a good example, but there may be many.\n\nI think this is easily solvable. The required data to verify and sign a\n(standard) bitcoin transaction (including P2WSH multi-sig) is manageable.\n\nIMO what a signing devices requires in order to sign a (standard)\ntransaction:\n-\u003e serialized tx\n-\u003e serialized tx of the inputs\n-\u003e scriptPubKey of the inputs\n-\u003e inputs redeem-Scripts\n-\u003e input amounts\n-\u003e position of the change output any maybe its keypath\n-\u003e cosigners pubkeys for inputs and changeaddress\n\nThis seems to be manageable for a 1 round communication?\nOr do I miss something?\n\n\n\u003e Currently the TREZOR protocol works like device is a server and wallet\n\u003e is a client calling methods on it. It's like: \"Sign this for me,\n\u003e please\", \"Ok, give me this information\", \"Here it is\", \"Now I need this\n\u003e another piece\".... \"There is the signature\". Wallet does not know in\n\u003e advance what will go next, and it is for sake of simplicity. I'm quite\n\u003e happy with the protocol so far.\n\nI think multiple rounds would still be possible with a clever design.\nAlthough I could imaging that \u003e95% of the users transaction would\nrequire only a single \"shot\".\n\nWhats the benefits of the multiple rounds communication? Would a single\nround result in to many data transported?\n\nPassing a 300kb chunk (assuming a large transaction) over a URI scheme\nrequires a couple of milliseconds on standard Smartphones or PCs.\n\n\u003e Considering the difference in between current hardware, I really don't\n\u003e think it is possible to find any minimal URI-based API good enough for\n\u003e communicating with all vendors. What I see more likely is some 3rd party\n\u003e libraries (JS, C++, Python, ...) defining high-level API and\n\u003e implementing hardware-specific protocols and transports as plugins. That\n\u003e way vendors are not limited by strict standard and application\n\u003e developers and services can integrate wide range of hardware wallets\n\u003e easily. However, this can be done already and we do not need any\n\u003e standardization process (yet).\n\nThe URI-based API allows transmitting data of multiple megabytes while\nthere is no need for...\n* dependencies of any form (library, etc.)\n* library support for a particular language\n* platform that supports the dependencies of the library (like USBHID,\nnot supported by iOS)\n\nCan you elaborate what benefits you would get from the library approach\nand how the library API would be different form the proposed URI-scheme?\n\nHow would the library approach work on mobile platforms? Would USB be\nthe only supported hardware communication layer?\n\nThanks\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/5ae29972/attachment.sig\u003e",
"sig": "53a4e77920152401a0bd4b7588811526933a62c9b6d6e7fe40c6a7611e153836518949e3b80109b76df33030f65ba1b11eb2ebe45333ee8d221e3f8eb43b7c49"
}