Published on: 2016-09-05T14:55:10+00:00
Suppose we have a marginal fee rate of 50 satoshis per byte. Reducing the size of the witness data by 1 byte is equivalent to a replace by fee that increases the fee by 50 satoshis. In both cases, miners get an extra potential of 50 satoshis in revenue. Replacing witness data with smaller witness data can pay for its own relay cost as much as RBF can, simply by requiring that the smaller witness be small enough to cover the same RBF threshold. BIP125 and mempool eviction both require the replacing transaction to have a higher fee, to compensate for the cost of relaying the replaced transaction(s).Johnson Lau, a member of the bitcoin-dev community, has proposed a restriction for segwit OP_IF argument as a policy. He is seeking more feedback from users of OP_IF to ACK or NACK his proposal. It is expected that Lightning network would use OP_IF frequently. Rusty, another member of the community, mentions that his current scripts use OP_IF and OP_NOTIF only after OP_EQUAL, except for one place where they use OP_EQUAL...OP_EQUAL...OP_ADD OP_IF. However, he notes that there will be no effect on the c-lightning implementation either way.The Bitcoin script validity rules are proposed to change in order to make transaction malleability related to OP_IF and OP_NOTIF impossible in pay-to-witness-script-hash (P2WSH) scripts. This would result in the argument for OP_IF and OP_NOTIF being exactly an empty vector or 0x01, or the script evaluation fails immediately. The policy has received a few concept ACKs. A BIP is prepared to deal with OP_IF and OP_NOTIF malleability in P2WSH. To ensure OP_IF and OP_NOTIF transactions created before the introduction of this BIP will still be accepted by the network, the new rules are not applied to non-segregated witness scripts. The proposed changes affect the combination of "OP_SIZE OP_IF" or "OP_DEPTH OP_IF". With this policy/softfork, you need to use "OP_SIZE OP_0NOTEQUAL OP_IF" or "OP_DEPTH OP_0NOTEQUAL OP_IF", or reconstruct your scripts. This is a softfork on top of BIP141. It is enforced as a relay policy by the reference client since the first release of BIP141. Users must not create P2WSH scripts that are incompatible with this BIP to avoid risks of fund loss.In a bitcoin-dev email, Sergio Demian Lerner raised concerns about transactions sent to IoT devices, which may be rejected if their witness program is too large for the device's implementation-imposed limit. This can result in the loss of bitcoins as the private key is stored on the device, rendering it unable to accept the cloned transaction. Lerner suggests invalidating transactions with a higher witness size than expected by the sender. The design of segwit means that resource constrained devices don't need to receive witness data to verify lite-client merkle-path proofs, which are useless for lite-clients anyway.In a discussion on the bitcoin-dev mailing list, Sergio Demian Lerner suggested that the real problem with witness data size is that it is not signed. However, Gregory Maxwell pointed out that this is not possible for the general case as you may not know the witness size in advance. Maxwell believes fees are not the problem, but rather the fact that the maximum witness size may be changed by a miner which could cause issues for devices like IoT or side-chains that have certain restrictions on transaction sizes they can accept. He proposes that if the witness size is higher than the expected size by the sender, the transaction becomes invalid.The issue at hand is that witness data size is not signed, leading to potential malleability issues and problems for systems with hard limits on the size of witness programs they can accept. A proposed solution is to soft-fork and add an opcode OP_PROGSIZE that pushes the size of the segwit program being evaluated onto the stack, which would allow scripts to take action based on the size. This would prevent an attacker from creating a clone of a transaction with a witness ECDSA signature longer than 0x50 bytes. The discussion also touches on workarounds for current behavior and the need to enforce MINIMALIF in some cases, with the suggestion to make it a relay policy first before considering a softfork.On August 17, 2016, Luke Dashjr and Johnson Lau discussed a workaround for the issue of malleability in Bitcoin transactions. The suggested code to replicate the original behavior was deemed ugly by Dashjr, who argued that it was unnecessary in most real-world use cases. He proposed simplifying the code by replacing "OP_SIZE OP_IF" with "OP_SIZE OP_0NOTEQUAL OP_IF", as OP_SIZE must return a valid MINIMALDATA number.
Updated on: 2023-08-01T18:56:33.083218+00:00