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 <bitcoin-dev@lists.linuxfoundation.org> 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