IRC meeting summary for 2015-12-03
Overview
Logs
- link to this week logs
- Meeting minutes by meetbot (slightly bugged logs as you’ll see)
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.
BIP68-related pull requests
background
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
background
Starting with Tor version 0.2.7.1 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
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 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.
Participants
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 :')
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.