← Back to Bitcoin Improvement Proposals
BIPinformational

BIP125: rephrase rule 2 for clarity

It's been reported that the double negative in rule 2 is confusing people (including myself, on re-read). This PR revises out both negatives and, I believe, significantly improves clarity. For reference, this document was based on the implementation in Bitcoin Core 0.12.0, which includes [these lines](https://github.com/bitcoin/bitcoin/blob/v0.12.0/src/main.cpp#L1134): ```cpp for (unsigned int j = 0; j < tx.vin.size(); j++) { // We don't want to accept

No reviews
harding·Updated Dec 14, 2018·0 reviews·0 attestations·View source
Collections:BIPs — Merged

Specification

It's been reported that the double negative in rule 2 is confusing people (including myself, on re-read). This PR revises out both negatives and, I believe, significantly improves clarity.

For reference, this document was based on the implementation in Bitcoin Core 0.12.0, which includes these lines:

            for (unsigned int j = 0; j < tx.vin.size(); j++)
            {
                // We don't want to accept replacements that require low
                // feerate junk to be mined first. Ideally we'd keep track of
                // the ancestor feerates and make the decision based on that,
                // but for now requiring all new inputs to be confirmed works.
                if (!setConflictsParents.count(tx.vin[j].prevout.hash))
                {
                    // Rather than check the UTXO set - potentially expensive -
                    // it's cheaper to just check if the new input refers to a
                    // tx that's in the mempool.
                    if (pool.mapTx.find(tx.vin[j].prevout.hash) != pool.mapTx.end())
                        return state.DoS(0, error("AcceptToMemoryPool: replacement %s adds unconfirmed input, idx %d",
                                                  hash.ToString(), j),
                                         REJECT_NONSTANDARD, "replacement-adds-unconfirmed");
              }

Changing this was suggested by @jnewbery, who also reviewed the code in master with me (which is the same but is moved to validation.cpp).

CC: @petertodd

Request to BIP editor @luke-jr: I think your usually policy is to merge policy-acceptable changes to BIPs solely based on the requests of their authors. As a co-author, I request this be left open for at least one week (December 13th) to give @petertodd a chance to comment if he wants.

Discussion (0 threads)

Loading discussions...