<div dir="ltr"><div>Once again my attempt to summarize and explain the weekly bitcoin developer meeting in layman&#39;s terms.  </div><div>Link to last weeks summarization ( <a href="http://lists.linuxfoundation.org/pipermail/bitcoin-discuss/2015-November/000008.html">http://lists.linuxfoundation.org/pipermail/bitcoin-discuss/2015-November/000008.html</a> )   </div><div><br></div><div>*Disclaimer*</div><div><br></div><div>Please bear in mind I&#39;m not a developer and I&#39;d have problems coding &quot;hello world!&quot;, so some things might be incorrect or plain wrong.  </div><div>Like any other write-up it likely contains personal biases, although I try to stay as neutral as I can.  </div><div>There are no decisions being made in these meetings, so if I say &quot;everyone agrees&quot; this means everyone present in the meeting, that&#39;s not consensus, but since a fair amount of devs are present it&#39;s a good representation.  </div><div>The dev IRC and mailinglist are for bitcoin development purposes. If you have not contributed actual code to a bitcoin-implementation, this is probably not the place you want to reach out to. There are many places to discuss things that the developers read.</div><div><br></div><div><br></div><div>link to this week logs ( <a href="http://bitcoinstats.com/irc/bitcoin-dev/logs/2015/11/12#l1447354830.0">http://bitcoinstats.com/irc/bitcoin-dev/logs/2015/11/12#l1447354830.0</a> )  </div><div>Meeting minutes by meetbot ( <a href="http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-11-12-19.01.html">http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-11-12-19.01.html</a> )  </div><div><br></div><div><br></div><div>Main topics discussed where:  </div><div>  </div><div>transaction priority for 0.12  </div><div>Opt-in replace-by-fee  </div><div>Versionbits  </div><div>Chain limits</div><div><br></div><div><br></div><div>**transaction priority for 0.12**</div><div><br></div><div>- background  </div><div><br></div><div>Each transaction is assigned a priority, determined by the age, size, and number of inputs. Which currently makes some transactions free.   </div><div>This currently has a large amount of code, which makes it harder to maintain, and is not that optimal since you can&#39;t expect miners to include 0-fee transactions.</div><div><br></div><div>- meeting comments</div><div><br></div><div>Most people seem fine with removing priority in the mempool, but people should be notified ahead of time this is coming.  </div><div>sdaftuar proposed a staggered approach, setting the default value for priority to 0, and remove it entirely in the next release.  </div><div>petertodd notes there will be a natural staggered process since not everyone will upgrade to 0.12 instantly and some implementations might not remove priority at all.  </div><div>Most wallet-software outside of bitcoin-core don&#39;t implement priority calculations.   </div><div>As fee estimation becomes more important and many wallet providers use the bitcoin-core fee estimation, improvements on that are welcome.  </div><div>Luke-Jr doesn&#39;t agree with removing priority, particularly with changing the mining code to use the priority a transaction has when it enters the mempool.  </div><div>Sipa has the idea to add a small fraction of bitcoin days destroyed divided by the average UTXO age to the fee, so that non-spam-attack transactions are viewed as if they have a larger fee.  </div><div><br></div><div>While most agree with the proposal to remove the current priority, there&#39;s still much debate on whether it needs to be replaced for 0.13, and if so, how.</div><div><br></div><div><br></div><div>- meeting conclusion  </div><div><br></div><div>Review &quot;Improve usage of fee estimation code&quot; ( <a href="https://github.com/bitcoin/bitcoin/pull/6134">https://github.com/bitcoin/bitcoin/pull/6134</a> )  </div><div>BlueMatt will mail the developer mailinglist announcing the changes. ( <a href="https://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg02790.html">https://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg02790.html</a> )  </div><div><br></div><div><br></div><div><br></div><div>**Opt-in replace-by-fee**</div><div><br></div><div>- background  </div><div><br></div><div>Currently when a node sees a transaction that spends the same output it ignores it. With replace-by-fee it replaces the current transaction in the mempool if it has a higher fee.   </div><div>This allows for things like spending &quot;stuck&quot; transactions, adding more recipients to a transaction in order to prevent chaining, etc.  </div><div><br></div><div>Since there are people that accept 0-confirmation transactions and this would make it extremely easy to double spend them, this is made opt-in.  </div><div>The sender can choose to opt-in to replace-by-fee by changing an input in the nSequence field.</div><div><br></div><div><br></div><div>- meeting comments</div><div><br></div><div>Peter Todd wrote some tools to use replace-by-fee. link: <a href="https://github.com/petertodd/replace-by-fee-tools">https://github.com/petertodd/replace-by-fee-tools</a>   </div><div>It would be nice to have opt-in per output instead of the whole transaction, however that would be very hard to implement and would have some privacy concerns.  </div><div>Luke-Jr would like to see an option to toggle between first-seen-safe/full RBF and never/opt-in/always. Since there are possibly some objections with the &quot;always&quot; toggle it should be a separate pull-request.</div><div><br></div><div><br></div><div>- meeting conclusion</div><div><br></div><div>review and merge nSequence-based Full-RBF opt-in ( <a href="https://github.com/bitcoin/bitcoin/pull/6871">https://github.com/bitcoin/bitcoin/pull/6871</a> )   </div><div>Peter Todd will write a mail to the list to explain how it works and how people can not accept opt-in transactions.  </div><div><br></div><div>**Versionbits**</div><div><br></div><div>- background</div><div><br></div><div>BIP 9 ( <a href="https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki">https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki</a> )  </div><div>Currently softforks have been done by the isSuperMajority mechanism, meaning when 95% of the last X blocks has a version number higher than Y the fork is deployed.   </div><div>A new way of doing this is currently being worked on and that uses all bits of the version number, appropriately being called versionbits. So instead of a fork happening when the version is larger than (for example) 00000000011 (3), a fork happens when (for example) the 3rd bit is up (so 00100000011).   </div><div>This way softforks can be deployed simultaneous and independent of each other. </div><div><br></div><div>- meeting comments</div><div><br></div><div>There are 2 different implementations. One from Codeshark ( <a href="https://github.com/bitcoin/bitcoin/pull/6816">https://github.com/bitcoin/bitcoin/pull/6816</a> ) and one from Rusty ( <a href="https://github.com/bitcoin/bitcoin/compare/master...rustyrussell:bip-9-versionbits">https://github.com/bitcoin/bitcoin/compare/master...rustyrussell:bip-9-versionbits</a> )   </div><div>jtimon thinks both implementations are more complicated than they need to be.  </div><div>There needs to be a minor revision namely a starting time for proposals.  </div><div>In general we&#39;d like to get this in soon, but existing softforks need to complete first.</div><div> </div><div><br></div><div>- meeting conclusion</div><div><br></div><div>CodeShark adds a starting time to versionbits.</div><div><br></div><div>**Chain limits**</div><div><br></div><div>- background</div><div><br></div><div>Chain in this context means connected transactions. When you send a transaction that depends on another transaction that has yet to be confirmed we talk about a chain of transactions. </div><div>Miners ideally take the whole chain into account instead of just every single transaction (although that&#39;s not widely implemented afaik). So while a single transaction might not have a sufficient fee, a depending transaction could have a high enough fee to make it worthwhile to mine both.</div><div>This is commonly known as child-pays-for-parent.  </div><div>Since you can make these chains very big it&#39;s possible to clog up the mempool this way.   </div><div>With the recent malleability attacks, anyone who made transactions going multiple layers deep would&#39;ve already encountered huge problems doing this beautifully explained in let&#39;s talk bitcoin #258 ( <a href="https://letstalkbitcoin.com/blog/post/lets-talk-bitcoin-258-liquidity-and-malleability">https://letstalkbitcoin.com/blog/post/lets-talk-bitcoin-258-liquidity-and-malleability</a> ) from 13:50 onwards   </div><div>proposal: <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011401.html">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011401.html</a> and github: <a href="https://github.com/bitcoin/bitcoin/pull/6771">https://github.com/bitcoin/bitcoin/pull/6771</a> link.</div><div><br></div><div>- meeting comments</div><div><br></div><div>Wumpus doesn&#39;t feel comfortable with merging it because there&#39;s some controversy from companies who exceed the limits (or could be/want to).  </div><div>jgarzik does feel comfortable with it, and many think it should be merged as it&#39;s easy to revert if needed.   </div><div>There&#39;s little choice as it&#39;s not safe from attacks without limits.    </div><div>We should communicate the replace-by-fee sendmany alternative to long chains (adding new recipients on existing non-confirmed transactions), although it won&#39;t show up in users wallet yet and block-explorers probably aren&#39;t ready to display it correctly.  </div><div>Emphasis on the fact it&#39;s a change in default values, not a consensus change, however default values have a lot of power.   </div><div>The final limits are 25 transactions and 101kb total size for both ancestor and descendant packages.  </div><div><br></div><div>  </div><div>- meeting conclusion<br></div><div><br></div><div>jgarzik will merge the pull-request.  </div><div>Morcos will mail the list once it&#39;s merged.  </div><div><br></div><div><br></div><div><br></div><div>**Participants**</div><div><br></div><div>    BlueMatt    Matt Corallo  </div><div>    petertodd   Peter Todd  </div><div>    morcos      Alex Morcos  </div><div>    jgarzik     Jeff Garzik  </div><div>    gmaxwell    Gregory Maxwell  </div><div>    wumpus      Wladimir J. van der Laan  </div><div>    Luke-Jr     Luke Dashjr  </div><div>    jtimon      Jorge Timón  </div><div>    btcdrak     btcdrak  </div><div>    phantomcircuit  Patrick Strateman  </div><div>    sipa        Pieter Wuille  </div><div>    CodeShark   Eric Lombrozo  </div><div>    sdaftuar    Suhas Daftuar  </div><div>    jg_taxi     jg_taxi  </div><div>    gavinandresen  Gavin Andresen  </div><div>    cfields     Cory Fields  </div><div>    bsm1175321  Bob McElrath   </div><div><br></div><div><br></div><div><br></div><div>**Comic relief**</div><div><br></div><div>    19:53<span class="" style="white-space:pre">        </span>sipa<span class="" style="white-space:pre">        </span>new topic?  </div><div>    19:53<span class="" style="white-space:pre">        </span>wumpus<span class="" style="white-space:pre">        </span>any other topics?  </div><div>    19:53<span class="" style="white-space:pre">        </span>petertodd<span class="" style="white-space:pre">        </span>&lt;crickets&gt;  </div><div>    19:53<span class="" style="white-space:pre">        </span>jgarzik<span class="" style="white-space:pre">        </span>did we cover jonas while I was in the taxi?  </div><div>    19:54<span class="" style="white-space:pre">        </span>sdaftuar<span class="" style="white-space:pre">        </span>?  </div><div>    19:54<span class="" style="white-space:pre">        </span>jtimon<span class="" style="white-space:pre">        </span>?  </div><div>    19:54<span class="" style="white-space:pre">        </span>CodeShark<span class="" style="white-space:pre">        </span>not sure I want to know  </div><div>    19:54<span class="" style="white-space:pre">        </span>jgarzik  <span class="" style="white-space:pre">        </span>proposal for new GUI maintainer  </div><div>    19:54<span class="" style="white-space:pre">        </span>CodeShark<span class="" style="white-space:pre">        </span>sounds kinky, though  </div><div>    19:54<span class="" style="white-space:pre">        </span>petertodd<span class="" style="white-space:pre">        </span>CodeShark: GUI&#39;s are pretty kinky  </div><div><br></div><div>    19:56<span class="" style="white-space:pre">        </span>BlueMatt<span class="" style="white-space:pre">        </span>ok, end meeting?  </div><div>    19:56<span class="" style="white-space:pre">        </span>btcdrak<span class="" style="white-space:pre">        </span>if we can remember the command this week :-)  </div><div>    19:56<span class="" style="white-space:pre">        </span>wumpus<span class="" style="white-space:pre">        </span>#meetingend  </div><div>    19:56<span class="" style="white-space:pre">        </span>gmaxwell<span class="" style="white-space:pre">        </span>#destroymeeting  </div><div>    19:56<span class="" style="white-space:pre">        </span>wumpus<span class="" style="white-space:pre">        </span>#endmeeting  </div><div>    19:56<span class="" style="white-space:pre">        </span>Luke-Jr<span class="" style="white-space:pre">        </span>#endmeeting  </div><div>    19:56<span class="" style="white-space:pre">        </span>lightningbot<span class="" style="white-space:pre">        </span>Meeting ended Thu Nov 12 19:56:42 2015 UTC. Information about MeetBot at <a href="http://wiki.debian.org/MeetBot">http://wiki.debian.org/MeetBot</a> . (v 0.1.4)    </div><div>    19:56<span class="" style="white-space:pre">        </span>BlueMatt<span class="" style="white-space:pre">        </span>#magicmeetbotincantation  </div><div>    19:57<span class="" style="white-space:pre">        </span>petertodd<span class="" style="white-space:pre">        </span>#DoWhatIMean  </div><div><br></div></div>