IRC meeting summary for 2015-12-03



Main topics

  • BIP68-related pull requests
  • Eviction and onions
  • BIP for opt-in RBF

Short topics/notes

A lot of developers where traveling to the scaling bitcoin conference (videos), so this is again a shorter, and it’ll likely be the same next week (as a lot of developers stay in Hong Kong for the developer meetup after the conference).

Also a reminder to anyone that’s running a full node to update their node to core 11.2 or 10.4, or any other node that supports BIP65 CLTV, to accommodate for the upcoming softfork. Not updating will mean you’ll be trusting miners to produce valid blocks. 85% of miners advertise they support CLTV transactions and the softfork will activate when 95% is reached, currently (time of writing) +/- 30% of nodes is updated.


BIP 68 Consensus-enforced transaction replacement signaled via sequence numbers , and current implementation.
BIP 68 changes the meaning of the previously unused sequence number field to a relative locktime.

meeting comments

There is a pull-request for a small correction in the comments of the code.
There’s been work on optimizing CreateNewBlock (which does what it says). Morcos and sdaftuar are looking at two approaches, one of which will refactor the BIP68 implementation significantly.
As the refactoring would be better done before BIP68 gets merged, it would be good to know which approach is better.

meeting conclusion

Look into the CreateNewBlock optimization approaches.

Eviction and onions


Starting with Tor version it is possible to create hidden services programmatically. Bitcoin will now automatically create a hidden service to listen on if Tor is running.

meeting comments

Localhost peers are never evicted; so as soon as you show up on a hidden service someone can prevent anyone else from connecting to you trivially.
Pull-request #7082 addresses this problem by using latency to detect actual local peers.
You can also use whitelists to distinguish between real localhost connections and tor localhost connections, but that might break existing software.
wumpus notes we should encourage using the whitelist for special peers in the long term.

meeting conclusion

Take a look at Pull-request #7082

BIP for opt-in RBF


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 the nSequence field of all inputs.
This is a mempool policy for the upcoming 0.12 release. There’s a good FAQ-ish post on reddit about it.

meeting comments

Question is if opt-in RBF should have a BIP or not.
It is just policy code, however standardness has been covered before in BIPs.
sdaftuar notes it’s unfortunate that the only documentation for what wallet writers should do is in a single mailing list post.
harding volunteers to write the BIP.

meeting conclusion

harding will write the BIP in coordination with petertodd.


wumpus          Wladimir J. van der Laan  
morcos          Alex Morcos  
btcdrak         btcdrak  
sipa  	        Pieter Wuille  
gmaxwell        Gregory Maxwell  
cfields         Cory Fields   
jonasschnelli  	Jonas Schnelli  
Diablo-D3  	    Patrick McFarland  
sdaftuar        Suhas Daftuar  
harding         David A. Harding  
jcorgan         Johnathan Corgan   

Comic relief

19:26	cfields	sec, i'll like the mail thread  
19:26	sipa	cfields: you'll "like" it, is it on facebook?  
19:27	wumpus	twitter has 'likes' now too :')  


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.