Meeting summaries: 2016-03-03

.gitignore

@@ -1,2 +1,3 @@
 _site
 .sass-cache
+.jekyll-metadata

_posts/en/meetings/2016-03-03-meeting.md

@@ -0,0 +1,341 @@
+---
+title: IRC meeting summary for 2016-03-03
+permalink: /en/meetings/2016/03/03/
+name: 2016-03-03-meeting
+type: meetings
+layout: page
+lang: en
+version: 1
+---
+
+- [Link to this week logs](http://bitcoinstats.com/irc/bitcoin-core-dev/logs/2016/03/03#l1457031985.0)
+- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-03-03-19.06.html)
+
+---
+
+- * contents
+{:toc}
+
+## VersionBits (BIP9) soft fork logic
+
+*Background: [BIP9][] is a mechanism for deploying soft forks that
+replaces the IsSuperMajority() mechanism used to deploy BIPs
+[34][BIP34], [66][BIP66], and [65][BIP65].  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](https://github.com/bitcoin/bitcoin/issues/7633) 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][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 yeas; 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][#7600] 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 talking 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.
+
+## Comedic relief
+
+{% highlight text %}
+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
+{% endhighlight %}
+
+## Participants
+
+| IRC nick   | Name/Nym            |
+|------------|---------------------|
+| btcdrak    | [BtcDrak][]         |
+| cfields    | [Cory Fields][]     |
+| CodeShark  | [Eric Lombrozo][]   |
+| gmaxwell   | [Gregory Maxwell][] |
+| Luke-Jr    | [Luke Dashjr][]     |
+| morcos     | [Alex Morcos][]     |
+| paveljanik | [Pavel Janik][]     |
+| petertodd  | [Peter Todd][]      |
+| sdaftuar   | [Suhas Daftuar][]   |
+| sipa       | [Pieter Wuille][]   |
+
+## 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.
+
+
+
+
+[Gregory Maxwell]: https://github.com/gmaxwell
+[Luke Dashjr]: https://github.com/luke-jr
+[Peter Todd]: https://github.com/petertodd
+[Suhas Daftuar]: https://github.com/sdaftuar
+[Pieter Wuille]: https://github.com/sipa
+[Eric Lombrozo]: https://github.com/codeshark
+[BtcDrak]: https://github.com/btcdrak
+[Cory Fields]: https://github.com/theuni
+[Alex Morcos]: https://github.com/morcos
+[Pavel Janik]: https://github.com/paveljanik
+
+[BIP9]: https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki
+[BIP34]: https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki
+[BIP65]: https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki
+[BIP66]: https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki
+[BIP133]: https://github.com/bitcoin/bips/blob/master/bip-0133.mediawiki
+
+[#7575]: https://github.com/bitcoin/bitcoin/pull/7575
+[#7594]: https://github.com/bitcoin/bitcoin/pull/7594
+[#7598]: https://github.com/bitcoin/bitcoin/pull/7598
+[#7600]: https://github.com/bitcoin/bitcoin/pull/7600