IRC meeting summary for 2015-11-12

Overview

Logs

Main topics

  • transaction priority for 0.12
  • Opt-in replace-by-fee
  • Versionbits
  • Chain limits

transaction priority for 0.12

background

Each transaction is assigned a priority, determined by the age, size, and number of inputs. Which currently makes some transactions free.
This currently has a large amount of code, which makes it harder to maintain, and is not that optimal since you can’t expect miners to include 0-fee transactions.

meeting comments

Most people seem fine with removing priority in the mempool, but people should be notified ahead of time this is coming.
sdaftuar proposed a staggered approach, setting the default value for priority to 0, and remove it entirely in the next release.
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.
Most wallet-software outside of bitcoin-core don’t implement priority calculations.
As fee estimation becomes more important and many wallet providers use the bitcoin-core fee estimation, improvements on that are welcome.
Luke-Jr doesn’t agree with removing priority, particularly with changing the mining code to use the priority a transaction has when it enters the mempool.
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.

While most agree with the proposal to remove the current priority, there’s still much debate on whether it needs to be replaced for 0.13, and if so, how.

meeting conclusion

Review “Improve usage of fee estimation code” BlueMatt will mail the developer mailinglist announcing the changes. ( https://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg02790.html )

Opt-in replace-by-fee

background

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.
This allows for things like spending “stuck” transactions, adding more recipients to a transaction in order to prevent chaining, etc.

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.
The sender can choose to opt-in to replace-by-fee by changing an input in the nSequence field.

meeting comments

Peter Todd wrote some tools to use replace-by-fee. link
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.
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 “always” toggle it should be a separate pull-request.

meeting conclusion

review and merge nSequence-based Full-RBF opt-in
Peter Todd will write a mail to the list to explain how it works and how people can not accept opt-in transactions.

Versionbits

jonasschnelli> background

BIP 9
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.
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).
This way softforks can be deployed simultaneous and independent of each other.

meeting comments

There are 2 different implementations. One from Codeshark and one from Rusty
jtimon thinks both implementations are more complicated than they need to be.
There needs to be a minor revision namely a starting time for proposals.
In general we’d like to get this in soon, but existing softforks need to complete first.

meeting conclusion

CodeShark adds a starting time to versionbits.

Chain limits

background

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. Miners ideally take the whole chain into account instead of just every single transaction (although that’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. This is commonly known as child-pays-for-parent.
Since you can make these chains very big it’s possible to clog up the mempool this way.
With the recent malleability attacks, anyone who made transactions going multiple layers deep would’ve already encountered huge problems doing this (beautifully explained in let’s talk bitcoin #258 from 13:50 onwards)
Proposal and github link.

meeting comments

Wumpus doesn’t feel comfortable with merging it because there’s some controversy from companies who exceed the limits (or could be/want to).
jgarzik does feel comfortable with it, and many think it should be merged as it’s easy to revert if needed.
There’s little choice as it’s not safe from attacks without limits.
We should communicate the replace-by-fee sendmany alternative to long chains (adding new recipients on existing non-confirmed transactions), although it won’t show up in users wallet yet and block-explorers probably aren’t ready to display it correctly.
Emphasis on the fact it’s a change in default values, not a consensus change, however default values have a lot of power.
The final limits are 25 transactions and 101kb total size for both ancestor and descendant packages.

meeting conclusion

jgarzik will merge the pull-request.
Morcos will mail the list once it’s merged.

Participants

BlueMatt        Matt Corallo  
petertodd       Peter Todd  
morcos          Alex Morcos  
jgarzik         Jeff Garzik  
gmaxwell        Gregory Maxwell  
wumpus          Wladimir J. van der Laan  
Luke-Jr         Luke Dashjr  
jtimon          Jorge Timón  
btcdrak         btcdrak  
phantomcircuit  Patrick Strateman  
sipa            Pieter Wuille  
CodeShark       Eric Lombrozo  
sdaftuar        Suhas Daftuar  
jg_taxi         jg_taxi  
gavinandresen   Gavin Andresen  
cfields         Cory Fields  
bsm1175321      Bob McElrath

Comic relief

19:53	sipa	new topic?  
19:53	wumpus	any other topics?  
19:53	petertodd	<crickets>  
19:53	jgarzik	did we cover jonas while I was in the taxi?  
19:54	sdaftuar	?  
19:54	jtimon	?  
19:54	CodeShark	not sure I want to know  
19:54	jgarzik  	proposal for new GUI maintainer  
19:54	CodeShark	sounds kinky, though  
19:54	petertodd	CodeShark: GUI's are pretty kinky  

19:56	BlueMatt	ok, end meeting?  
19:56	btcdrak	if we can remember the command this week :-)  
19:56	wumpus	#meetingend  
19:56	gmaxwell	#destroymeeting  
19:56	wumpus	#endmeeting  
19:56	Luke-Jr	#endmeeting  
19:56	lightningbot	Meeting ended Thu Nov 12 19:56:42 2015 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)    
19:56	BlueMatt	#magicmeetbotincantation  
19:57	petertodd	#DoWhatIMean

Credits

This summary was originally compiled by Stefan Gilis aka “G1lius” and posted to the bitcoin-discuss mailing list with the disclaimer, “Please bear in mind I’m not a developer so some things might be incorrect or plain wrong.” and placed copyright in the Public Domain.