I want to pitch a use-case that might have been ignored in this discussion: I don't think this protocol is only useful for hardware wallets. Technically any website that wants to request public keys/signatures and offload the responsibility for managing keys and signing to the user would also find this valuable. I hope we can move forward with a protocol that suits both the hardware people, and the people who find signing transactions in browsers unsettling. Maybe we the focus should move away from only servicing hardware, and asking if the motivation is better captured by "allow users pick their own ECDSA implementation, hardware or software", then working out what we need to get us there. On 08/18/2016 12:23 PM, Nicolas Bacca via bitcoin-dev wrote: > On Thu, Aug 18, 2016 at 11:49 AM, Jonas Schnelli via bitcoin-dev > > wrote: > > Hi > > > I have some experience with hardware wallet development and its > > integration and I know it's a mess. But it is too early to > define such > > rigid standards yet. Also, TREZOR concept (device as a server > and the > > primary source of workflow management) goes directly against your > > proposal of wallet software as an workflow manager. So it is > clear NACK > > for me. > > The current question – as already mentioned – is we ACK to work > together > on a signing protocol or if we NACK this before we even have started. > > > ACK for Ledger. What's necessary to sign a transaction is well known, > I don't see how driving any hardware wallet from the wallet itself or > from a third party daemon implementing that URL scheme would make any > difference, other than providing better devices interoperability, as > well as easier maintenance and update paths for the wallets. > > -- > Nicolas Bacca | CTO, Ledger > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev