*One of my biggest fears about using any wallet is the "whoops, cosmic ray
flipped a bit while producing receiving address; SFYL!" possibility. For
high value cold storage, I always generate my addresses on two independent
machines using two different pieces of software. Am I nuts for doing that?*
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
It would be nice if the detached signer and the normal wallet could both
verify the correctness of generated addresses before you cause coins to be
sent there.
e.g. the hardware wallet could give its master public key to Bitcoin Core
and you can thereafter generate your receiving addresses on Core
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, TREZ
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 wa
On Thu, Aug 18, 2016 at 11:35 AM, Jonas Schnelli
wrote:
> I agree that BIP70 is a mess (including the bitcoin:// additions). The
> proposed URI scheme would be completely different.
This reminds me https://xkcd.com/927/
I have some experience with hardware wallet development and its integratio
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
> 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?
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
"standar
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
On Tue, Aug 16, 2016 at 7:14 PM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> The other serious problem - and this is a problem with smartcards in
> general
> anyway - is that without Bitcoin-specific logic you're just signing
> blindly; we
> recently saw the proble
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.
Currentl
Hi Dana
>> 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).
>
> Hi everybody, just thought I’d throw my opinion in here.
>
> The URI scheme is a nice idea, but
> On Aug 17, 2016, at 15:24, Jonas Schnelli via bitcoin-dev
> wrote:
>
> 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
> directl
On Wed, Aug 17, 2016 at 9:24 AM, Jonas Schnelli via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> 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).
>
I'd also
On Wed, Aug 17, 2016 at 2:14 AM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> I'm not aware of any ECC-enabled smart-cards that can sign the specific
> curve
> that Bitcoin uses, not to mention the fact that those smartcards generally
> only
> speak higher level p
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 multipl
Hi all,
Thanks again Jonas for starting this!
I worked on a similar proposal a while back (never posted), approaching
the same problem as if a merchant's website accepted xpubs/public keys,
created multi-signature addresses, and wanted the user to easily sign
offline instead of using some javascr
On 08/16/2016 12:22 PM, Luke Dashjr via bitcoin-dev wrote:
> It would be best if the hardware protocol were standardised, so the user
> doesn't need a plugin of *any* sort... I notice some hardware wallets have
> begun to implement (or reuse) Trezor's interface, so that would seem a good
> place
On Wed, Aug 17, 2016 at 09:36:02AM +1000, Aiqin Li via bitcoin-dev wrote:
> Out of curiosity, what is the technical reason a normal ECC-enabled
> smart-card cannot be used for the hardware signing component of a wallet
> app? (Since if it can, its standardization must have been discussed.)
>
> Deb
Out of curiosity, what is the technical reason a normal ECC-enabled
smart-card cannot be used for the hardware signing component of a wallet
app? (Since if it can, its standardization must have been discussed.)
Debian wiki gives a list of such cards with related opensource software
to access t
On Tuesday, August 16, 2016 2:10:04 PM Jonas Schnelli via bitcoin-dev wrote:
> The BIP describes two approaches how to communicate (pipe and
> URI-scheme) with the signing-devices app, although, in my opinion, all
> major platform do support the URI approach (maybe we could drop the pipe
> approach
Hello Jonas,
thanks for your efforts of writing the draft for the standard.
First, this only describes detached signing. A wallet also needs to
connect with a hardware wallet at some time to learn the xpubs
controlled by the hardware. Do you plan to have this in a separate
standard or should th
On 16/08/16 17:13, Jonas Schnelli wrote:
> I'm aware of this approach but I don't think this makes sense long term.
> We need a better way on the protocol level to validate inputs amounts
> (where segwit is a first step towards this).
So you basically rephrased what I am saying but in another word
> I think it does not make sense to try to get this standardized for
> current Bitcoin transactions. They are just too complex.
>
> What might be interesting is to have something similar for Segwit and
> Lightning transactions.
>
> * TREZOR performs extended validation of the inputs, when all of
I think it does not make sense to try to get this standardized for
current Bitcoin transactions. They are just too complex.
What might be interesting is to have something similar for Segwit and
Lightning transactions.
* TREZOR performs extended validation of the inputs, when all of
prev-txs are s
Hi
Unfortunately, there is no standard in how desktop- or mobile-wallets
can interact with a hardware device resulting in wallet vendors adding
plugins with proprietary code for non-standardized interfaces.
I started a BIP (extreme draft, feel free to improve language, grammar
and content) to add
26 matches
Mail list logo
