IRC meeting summary for 2015-12-03
- BIP68-related pull requests
- Eviction and onions
- BIP for opt-in RBF
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
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.
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.
Look into the CreateNewBlock optimization approaches.
Eviction and onions
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.
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.
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.
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.
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
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.