IRC meeting summary for 2016-03-03

• Link to this week logs
• Meeting minutes by meetbot

VersionBits (BIP9) soft fork logic

Background: BIP9 is a mechanism for deploying soft forks that replaces the IsSuperMajority() mechanism used to deploy BIPs 34, 66, and 65. The older method requires soft forks be rolled out sequentially, as a miner signaling that they’re ready to enforce soft fork number 3 must also signal that they’re willing to enforce soft forks number 2 and 1. Because of this, we currently wait for soft fork number 1 to be fully enforced before attempting soft fork number 2, and we wait for 2 to be fully enforced before attempting soft fork number 3. This can create delays and contention over which soft fork to perform next. VersionBits allows miners to signal readiness to enforce any set of up to 29 different soft forks as well as providing a few other nice features such as greater predictability for enforcement times.

Discussion today centered around Pull Request (PR) #7575 and a few recent changes to the BIP so that, “as long as the start/end times of [soft fork] deployments are non-overlapping, the [block header version] bits [used by miners to signal readiness to enforce] are never ambiguous. [This means there] is no need for dependency tracking between different deployments, [they] just [need to] choose start/end times sanely” (Pieter Wuille). Several participants voiced their happiness regarding this.

On a different BIP9 issue, Gregory Maxwell said, “I continue to be a little concerned that the activation threshold may be too high considering the low variance triggering mechanism, and activation delay. But I see nothing to do about that except try it and see if our first versionbits fork attempt fails to activate in a reasonable time.” The activation threshold for VersionBits is 95%, the same as used with IsSuperMajority(), but VersionBits is measured over 2,016 blocks rather than 1,000 blocks and it’s measured only once per 2,016 blocks rather than every block as with IsSuperMajority(). This means that a small miner who produces less than 5% of the blocks could prevent the fork from triggering even if every other miner but them signaled readiness just because that small miner got “lucky” during that period and produced more than 5% of the blocks.

Pieter Wuille replied to Maxwell’s concern, saying “We can reduce the threshold if needed; increasing [it] is harder, as it may cause the warning to not fire.”

Conversation continued about how to optimize Bitcoin Core’s regression test (regtest) mode for testing long chains of 4,032 blocks such as those measured by versionbits.

Final action items for this discussion:

• Pieter Wuille will push a few changes to PR #7575
• All consensus protocol developers are encouraged to review #7575 and BIP9 as these will likely see deployment soon for one or more of the pending soft forks.

Transaction backlog

Background: during the several days prior to the meeting, it was widely reported that many nodes’ memory pools contained an above-normal number of unconfirmed transactions. Although significant changes to the system state are worth investigating in any case, the recent release of Bitcoin Core 0.12.0 with its major changes to memory pool policy may make investigating this more important than usual.

[Editor’s note: this discussion rambled a bit without any official change in topic even to the point where the meeting chair said, “okay, we’re going on a tangent.” I’ve split it into subsections to hopefully improve clarity, but this takes some elements significantly out of linear order.]

Regarding the current status, Maxwell says, “Right now there has been an increase in transactions with fees over 1 satoshi per byte. The months-standing background spam load of around a gigabyte below that [fee per byte level] seems largely unchanged to me.”

Luke Dashjr asked, “has anyone looked into whether the new transactions are real or spam?” Maxwell replied, “Some people have; Peter Todd was tweeting some analysis that strongly supported the later.”

Peter Todd added, “Yeah, they look like long chains where eventually everything goes back to the sender, apparently. But no formal write ups [of this analysis] exist yet.”

Alex Morcos said that “it looks to me like the backlog is diminishing”.

Opt-in Replace-by-Fee (RBF) use

Peter Todd noted that the GreenAddress.it (GA.it) wallet “has RBF code in their GitHub repo”. Maxwell agreed, “GA.it has been working on that; I think he was off in a design rathole on how to best support updating [a transaction] with additional outputs. FWIW, with the new proposal for Schnorr aggregate signatures, updating for more outputs will be much more attractive.”

The Schnorr aggregate signature proposal will allow multiple inputs to the same transaction to share a signature field if they all use similar enough scripts (which would be expected if they were all spent by the same wallet). Since signatures are the largest single part of typical transactions, the ability to combine multiple signatures together with no loss in security significantly compresses transactions. Since the fee paid in Replace By Fee (RBF) transactions in based on transaction size, this compression will make RBF even more efficient at saving money than it is today compared to sending separate transactions.

-paytxfee semantics change

Background: roughly 24 hours prior to the meeting, developer Mike Gogulski opened an issue in the Bitcoin Core repository reporting that the behavior of the -paytxfee configuration option had changed with the release of Bitcoin Core 0.12.0

“So what I think happened,” wrote Pieter Wuille, “is that at some point we switched the mining code to be per byte instead of per kilobyte. Later [a] global [variable] was introduced which implicitly retained the behavior of ‘rounding up to 1,000 bytes for fee calculation’ even though the rest of the code was updated to be per byte, Only now, with the global [variable] going away, we actually get the accurate change.”

Since transactions sizes were previously rounded up when this configuration option was used but are now being calculated precisely, the fee paid per byte is now lower than users of the -paytxfee flag expected. Note that this semantics change only affected users that set this option manually.

Alex Morcos brought up that the -maxsigcachesize base unit was also changed; it’s now in megabytes. He suggested, “a checklist on changing behavior of any options or RPC calls […] I’m not sure how many people would catch all these warnings in the two-foot-thick binder of release notes, but it’s still good to have them.”

FeeFilter

Background: Alex Morcos’s recently-proposed draft BIP133 suggests adding a new message to the P2P protocol that allows a node to tell its peers that it only wants to receive notifications about new transactions if those transactions pay a transaction fee per byte above a certain level. The node requesting this filtering out of low fee transactions can choose whatever fee per byte level it wants. Since nodes today have no way to tell their peers that they’re not going to process low-fee transactions, it is believed that the introduction of this message will reduce the amount of wasted traffic on the network.

Discussion was extremely brief. Morcos said, “It reduces transaction send and receive bandwidth by around 40+%”. Maxwell replied, “that’s fantastic” and also said “feefilter is awesome”.

Dashjr suggested that feefilter “needs some kind of ‘mode’ for things like ‘how do we measure size’ etc, but [that’s] not a huge deal.” Morcos felt differently, “I’m basically of the mindset that we don’t introduce complication until we need it.” Maxwell agreed, “We will not run out of message types, so we could introduce a modefilter later”.

Thinking long term, Maxwell added, “I expect the way relay works to change substantially in the next couple years; so we should probably not overdesign here.”

The action item for feefilter is more review and testing.

Child Pays For Parent (CPFP) mining

Background: Suhas Daftuar has an Work-In-Progress (WIP) pull request that helps miners create more profitable blocks by considering the combined fee rate of unconfirmed transactions plus their child transactions. This is useful not just for improving miner profitability but also for allowing users to effectively add fees to transactions that are already in miner memory pools by creating child transactions with high fee rates, which is commonly called Child [transaction] Pays For Parent [transaction] (CPFP).

Daftuar reports, “I’ve been running [the code] live for the last two days. [I’ve been] comparing the exiting mining algorithm to the new one [approximately] every 128 transactions or so. [When] looking at the last call to the CreateNewBlock() [function] before a block is found, I see a [significant] increase in the fee/block on the last 144 data points.”

Maxwell explains why a non-trivial profitability increase is expected, “I believe it should be making some pretty significant differences in selection from what I’ve seen. A number of users of OTHERBRAND [sic] wallet that has no fee estimation and always spends unconfirmed change seem to frequently produce chains of very low fee, very high fee (after realizing they needed more fee from the first tx).”

A discussion regarding the method used to test the increase in profitability explained that the test is likely counting some transactions multiple times, so the exact increase in fee captured per block is likely less than the test indicated. Still, one can safely assume that miners will be happy to run code that increases their potential profitability, all other things being equal.

Daftuar then reported on the costs of the new code in terms of performance. “So there are three areas of performance to consider:

1. “The additional work of the mempool to keep the index [of related transactions and their fees]

2. “The part of CreateNewBlock() before TestBlockValidity() is called

3. “The time TestBlockValidity takes ([which is] much larger than the rest of CreateNewBlock(), which is why I think it makes sense to split it out)”

Technical discussion continued with Daftuar providing numbers from his testing. Results and test methodology can be found in PRs #7594 and #7600. In one case, this new code seems to speed up a mining-related process, and in at least one other case the slowdown seems to be insignificant.

Action item: “[get] people into working on review for CPFP [PRs] #7594, #7598, and #7600.”

Postscript: in the post-meeting discussion, Maxwell suggested to Daftuar “if CPFP appears to be moderately stable, we might consider asking a moderately large miner to run it (in parallel to other stuff); it would have most of it’s usability benefit for the network if only one moderately larger miner was running it. […] The only reason I suggest it is because there are at least a few users whose delays could be avoided by [running] it.” Daftuar seemed agreeable and indicated he would work with Maxwell to find a miner to conduct that live test.

Segregated Witness (segwit) status

Background: several developers are working on a soft fork to introduce segregated witness onto Bitcoin mainnet, with initial testing being performed on a special testnet. Segregated witness allows transaction signature data to be stored outside of the data hashed to produce transaction identifiers, removing all known forms of third-party malleability, allowing full nodes to compile the current UTXO set without downloading all signatures, and laying the groundwork for fraud proofs that can allow lightweight (SPV) clients to help enforce more of the consensus rules. The segwit soft fork also allows miners to substitute 1 byte of block space with 4 bytes of segwit data, increasing transaction capacity for wallets that use segwit.

Eric Lombrozo started by saying, “we had a [chain] fork a few days ago”. Wuille replied, “I haven’t had time to investigate; my hope is that it was caused by miners running older versions of the [segwit] code and not something else”. Lombrozo acknowledged “that’s the most probable - but we haven’t narrowed down the conditional that actually caused it.”

Wuille said, “I was planning on doing a segnet4 very soon, but we’d need to understand what’s causing this first.”

Morcos asked, “is there anyone stuck on the short fork” and Lombrozo replied, “I think there might be still a few”. Cory Fields said “I’d be interested in taking a look there”.

Maxwell suggested a debug tool: “[it] might be useful if regtest networks put their git build info in their version numbers. [This would be] awful for privacy, but [it] would be useful here.”

Action item was that several people would work on identifying the cause of the fork.

Conclusion

The meeting concluded at its scheduled end time with some items still left on the agenda. Some immediate post-meeting discussion has been integrated into this summary.

Comic relief

gmaxwell:  okay, we're going on a tangent.
sipa:      going on a tangent is a sin
morcos:    oh no
CodeShark: no trig puns
sipa:      I co-sign that

Participants

Disclaimers

Quotes taken from the discussion had their capitalization, punctuation, and spelling modified to produce consistent sentences. Bracketed words and fragments, as well as background narratives and explanatory exposition, were added by the author of this summary and may have accidentally changed the meaning of some sentences; if you believe any quote was taken out of context, please contact us and the mistake will be rectified.

This summary was compiled without input from any of the participants in the discussion, so any errors are the fault of the summary author and not the discussion participants.