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

2016-08-16 Thread Luke Dashjr via bitcoin-dev
On Wednesday, August 17, 2016 3:02:53 AM Johnson Lau via bitcoin-dev wrote: > To completely replicate the original behaviour, one may use: > "DEPTH TOALTSTACK IFDUP DEPTH FROMALTSTACK NUMNOTEQUAL IF 2DROP {if script} > ELSE DROP {else script} ENDIF" This is much uglier than expected. IMO if

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

2016-08-16 Thread Johnson Lau via bitcoin-dev
> On August 16, 2016 at 8:27 PM Russell O'Connor via bitcoin-dev > wrote: > > Okay. > > I'm not really opposed to this BIP, but I am worried that fighting script > malleability is a battle that can never be won; even leaving one avenue of >

Re: [bitcoin-dev] Hardware Wallet Standard

2016-08-16 Thread Thomas Kerin via bitcoin-dev
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

Re: [bitcoin-dev] Hardware Wallet Standard

2016-08-16 Thread Thomas Daede via bitcoin-dev
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 >

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

2016-08-16 Thread Gregory Maxwell via bitcoin-dev
On Tue, Aug 16, 2016 at 10:52 PM, Russell O'Connor via bitcoin-dev wrote: > I see. > > But is it really necessary to soft fork over this issue? Why not just make > it a relay rule? Miners are already incentivized to modify transactions to > drop excess

Re: [bitcoin-dev] Hardware Wallet Standard

2016-08-16 Thread Peter Todd via bitcoin-dev
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.) > >

Re: [bitcoin-dev] Hardware Wallet Standard

2016-08-16 Thread Aiqin Li via bitcoin-dev
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

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

2016-08-16 Thread Russell O'Connor via bitcoin-dev
I see. But is it really necessary to soft fork over this issue? Why not just make it a relay rule? Miners are already incentivized to modify transactions to drop excess witness data and/or prioritize (versions of) transactions based on their cost. If a miner wants to mine a block with excess

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

2016-08-16 Thread Russell O'Connor via bitcoin-dev
On Tue, Aug 16, 2016 at 6:30 PM, Pieter Wuille wrote: > On Aug 17, 2016 00:23, "Russell O'Connor via bitcoin-dev" < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > If one's goal is to mess with an transaction to prevent it from being > mined, it is more effective

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

2016-08-16 Thread Pieter Wuille via bitcoin-dev
On Aug 17, 2016 00:36, "Russell O'Connor" wrote: > Can I already do something similar with replace by fee, or are there limits on that? BIP125 and mempool eviction both require the replacing transaction to have higher fee, to compensate for the cost of relaying the

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

2016-08-16 Thread Pieter Wuille via bitcoin-dev
On Aug 17, 2016 00:23, "Russell O'Connor via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > If one's goal is to mess with an transaction to prevent it from being mined, it is more effective to just not relay the transaction rather than to mess with the witness. Given two

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

2016-08-16 Thread Russell O'Connor via bitcoin-dev
On Tue, Aug 16, 2016 at 3:43 PM, Peter Todd via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Tue, Aug 16, 2016 at 07:37:19PM +, Luke Dashjr via bitcoin-dev > wrote: > > On Tuesday, August 16, 2016 5:53:08 PM Johnson Lau via bitcoin-dev wrote: > > > A new BIP is prepared to

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

2016-08-16 Thread Joseph Poon via bitcoin-dev
I agree this is an interesting area of transaction malleability to still consider in the future, and minimization of these areas of malleability with regards to its impact on the p2p network should be easy to resolve and (hopefully) well-understood by script writers in the future. On Tue, Aug 16,

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

2016-08-16 Thread Luke Dashjr via bitcoin-dev
On Tuesday, August 16, 2016 5:53:08 PM Johnson Lau via bitcoin-dev wrote: > A new BIP is prepared to deal with OP_IF and OP_NOTIF malleability in > P2WSH: > https://github.com/jl2012/bips/blob/minimalif/bip-minimalif.mediawiki > https://github.com/bitcoin/bitcoin/pull/8526 I am not sure this

Re: [bitcoin-dev] Hardware Wallet Standard

2016-08-16 Thread Luke Dashjr via bitcoin-dev
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 >

Re: [bitcoin-dev] Hardware Wallet Standard

2016-08-16 Thread Jochen Hoenicke via bitcoin-dev
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

Re: [bitcoin-dev] New BIP: Low S values signatures

2016-08-16 Thread Johnson Lau via bitcoin-dev
> On August 16, 2016 at 6:20 AM Luke Dashjr wrote: > > > On Tuesday, August 16, 2016 10:10:01 AM Johnson Lau via bitcoin-dev wrote: > > Specification > > > > Every signature passed to OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG, > > or OP_CHECKMULTISIGVERIFY, to which

[bitcoin-dev] Hardware Wallet Standard

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

Re: [bitcoin-dev] New BIP: Low S values signatures

2016-08-16 Thread Luke Dashjr via bitcoin-dev
On Tuesday, August 16, 2016 10:10:01 AM Johnson Lau via bitcoin-dev wrote: > Specification > > Every signature passed to OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG, > or OP_CHECKMULTISIGVERIFY, to which ECDSA verification is applied, Not 20-byte witness v0 programs? > These operators all

[bitcoin-dev] New BIP: Low S values signatures

2016-08-16 Thread Johnson Lau via bitcoin-dev
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 As discussed in the 11 Aug 2016 IRC meeting (https://bitcoincore.org/en/meetings/2016/08/11/#softfork-to-make-low-s-required), a new BIP with implementation is prepared to make low S value signature as a consensus rule: