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

Johnson Lau via bitcoin-dev writes: > Restriction for segwit OP_IF argument as a policy has got a few concept ACK. > I would like to have more people to ACK or NACK, especially the real users of > OP_IF. I think Lightning network would use that at lot. My

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

For sake of example, suppose we have a marginal fee rate of 50 satoshis per byte. At that rate reducing the size of the witness data by 1 byte is approximately equivalent from a miner and relayer's perspective as a replace by fee that increases the fee by 50 satoshis. In both cases miners get an

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

Restriction for segwit OP_IF argument as a policy has got a few concept ACK. I would like to have more people to ACK or NACK, especially the real users of OP_IF. I think Lightning network would use that at lot. Pull request: https://github.com/bitcoin/bitcoin/pull/8526 more related discussion

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

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

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

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] New BIP: Dealing with OP_IF and OP_NOTIF malleability in P2WSH

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

> 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] New BIP: Dealing with OP_IF and OP_NOTIF malleability in P2WSH

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] New BIP: Dealing with OP_IF and OP_NOTIF malleability in P2WSH

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

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

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

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

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

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

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