Re: [bitcoin-dev] Status updates for BIP 9, 68, 112, and 113

[Btc Drak via bitcoin-dev]

Fine by me to update BIP68 and BIP112 to Final status. The forks have
activated.

On Fri, Jul 15, 2016 at 4:30 PM, Luke Dashjr  wrote:

> Daniel Cousens opened the issue a few weeks ago, that BIP 9 should
> progress to
> Accepted stage. However, as an informational BIP, it is not entirely clear
> on
> whether it falls in the Draft/Accepted/Final classification of proposals
> requiring implementation, or the Draft/Active classification like process
> BIPs. Background of this discussion is at:
> https://github.com/bitcoin/bips/pull/413
> (Discussion on the GitHub BIPs repo is *NOT* recommended, hence bringing
> this
> topic to the mailing list)
>
> Reviewing the criteria for status changes, my opinion is that:
> - BIPs 68, 112, 113, and 141 are themselves implementations of BIP 9
> -- therefore, BIP 9 falls under the Draft/Accepted/Final class
> - BIPs 68, 112, and 113 have been deployed to the network successfully
> -- therefore, BIP 9 has satisfied the conditions of not only Accepted
> status,
>but also Final status
> -- therefore, BIPs 68, 112, and 113 also ought to be Final status
>
> If there are no objections, I plan to update the status to Final for BIPs
> 9,
> 68, 112, and 113 in one month. Since all four BIPs are currently Draft, I
> also
> need at least one author from each BIP to sign-off on promoting them to
> (and
> beyond) Accepted.
>
> BIP   9: Pieter Wuille 
>  Peter Todd 
>  Greg Maxwell 
>  Rusty Russell 
>
> BIP  68: Mark Friedenbach 
>  BtcDrak 
>  Nicolas Dorier 
>  kinoshitajona 
>
> BIP 112: BtcDrak 
>  Mark Friedenbach 
>  Eric Lombrozo 
>
> BIP 113: Thomas Kerin 
>  Mark Friedenbach 
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Status updates for BIP 9, 68, 112, and 113

[Luke Dashjr via bitcoin-dev]

On Friday, July 15, 2016 4:46:57 PM Wladimir J. van der Laan wrote:
> On Fri, Jul 15, 2016 at 03:52:37PM +, Luke Dashjr wrote:
> > On Friday, July 15, 2016 3:46:28 PM Wladimir J. van der Laan wrote:
> > > I'm not sure why it is labeled as only "Informational" in the first
> > > place, as BIP9 is part of the consensus logic.
> > 
> > Only by proxy/inclusion from another BIP, such as 68, 112, and 113. In
> > other words, BIP 9 is informational in that it advises how other BIPs
> > might deploy themselves.
> 
> It's a bit of grey area, as indeed, only the BIPs that are actual softforks
> are consensus changes - which employ this mechanism for deployment. But I
> think such an important deployment mechanism, which is supposed to be used
> by all softforks from now onwards, shouldn't just be an informational BIP.

As things stand right now, none of the Authors have commented on changing the 
type. It has been a month, and I am prepared to change the status to Final or 
Active; but I am unclear if your comments were an objection to changing the 
status or not.

Last call: Does anyone mind if I update BIP 9 to Final status?

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hardware Wallet Standard

[Nicolas Bacca via bitcoin-dev]

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

Re: [bitcoin-dev] Hardware Wallet Standard

[Jonas Schnelli via bitcoin-dev]

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.

I'm not saying that the draft proposal I made is the way to go, I'm
happy to NACK it myself in favor of a better proposal.

I strongly recommend to work together on a standard that will have one
central winner: the end user.





signature.asc
Description: OpenPGP digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hardware Wallet Standard

[Marek Palatinus via bitcoin-dev]

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 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.

slush
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hardware Wallet Standard

[Jonas Schnelli via bitcoin-dev]

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?





signature.asc
Description: OpenPGP digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hardware Wallet Standard

[Marek Palatinus via bitcoin-dev]

> 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
"standard" on top of URI protocol is a huge limitation, which does not give
any advantage.

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.

> 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".

slush


On Thu, Aug 18, 2016 at 8:54 AM, Jonas Schnelli 
wrote:

> 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
> --
> 
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hardware Wallet Standard

[Jonas Schnelli via bitcoin-dev]

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
--




signature.asc
Description: OpenPGP digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev