Re: [bitcoin-dev] New BIP: Dealing with OP_IF and OP_NOTIF malleability in P2WSH

2016-08-17 Thread Peter Todd via bitcoin-dev
On Wed, Aug 17, 2016 at 09:33:24PM -0300, Sergio Demian Lerner via bitcoin-dev wrote: > If I send a transaction to an IoT device (say to an OpenDime or to the old > Firmcoin), and the OpenDime must verify that the transaction has been mined > (SPV verification), then it may expect the witness

Re: [bitcoin-dev] New BIP: Dealing with OP_IF and OP_NOTIF malleability in P2WSH

2016-08-17 Thread Sergio Demian Lerner via bitcoin-dev
On Wed, Aug 17, 2016 at 9:19 PM, Gregory Maxwell wrote: > On Thu, Aug 18, 2016 at 12:11 AM, Sergio Demian Lerner via bitcoin-dev > wrote: > > I think that we're not attacking the real source of the problem: that the > > witness data

Re: [bitcoin-dev] New BIP: Dealing with OP_IF and OP_NOTIF malleability in P2WSH

2016-08-17 Thread Sergio Demian Lerner via bitcoin-dev
I think that we're not attacking the real source of the problem: that the witness data size is not signed. It may be the case that a new source of malleability is detected in witness programs later, or related to new opcodes we'll soft-fork in the future. The problem is real, as some systems

Re: [bitcoin-dev] Hardware Wallet Standard

2016-08-17 Thread Bryan Bishop via bitcoin-dev
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

Re: [bitcoin-dev] Hardware Wallet Standard

2016-08-17 Thread Marek Palatinus 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.

Re: [bitcoin-dev] Hardware Wallet Standard

2016-08-17 Thread Jonas Schnelli via bitcoin-dev
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,

Re: [bitcoin-dev] Hardware Wallet Standard

2016-08-17 Thread Dana L. Coe via bitcoin-dev
> 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

Re: [bitcoin-dev] BIP draft: HTLC transactions

2016-08-17 Thread Johnson Lau via bitcoin-dev
> On July 20, 2016 at 2:17 AM Luke Dashjr via bitcoin-dev > wrote: > > On Wednesday, July 20, 2016 5:46:54 AM Peter Todd via bitcoin-dev wrote: > > > On Tue, Jul 19, 2016 at 10:35:39PM -0600, Sean Bowe via bitcoin-dev wrote: > > > > > I'm requesting

Re: [bitcoin-dev] Hardware Wallet Standard

2016-08-17 Thread Nicolas Bacca via bitcoin-dev
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

Re: [bitcoin-dev] Hardware Wallet Standard

2016-08-17 Thread Nicolas Bacca via bitcoin-dev
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

Re: [bitcoin-dev] Hardware Wallet Standard

2016-08-17 Thread Jonas Schnelli via bitcoin-dev
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