Link to last weeks summarization
Disclaimer
Please bear in mind I'm not a developer and I'd have problems coding "hello world!", so some things might be incorrect or plain wrong.
Like any other write-up it likely contains personal biases, although I try to stay as neutral as I can.
There are no decisions being made in these meetings, so if I say "everyone agrees" this means everyone present in the meeting, that's not consensus, but since a fair amount of devs are present it's a good representation.
link to this week logs (slightly bugged logs as you'll see)
Meeting minutes by meetbot
Main topics discussed where:
BIP68-related pull requests
Eviction and onions
BIP for opt-in RBF
Short topics/notes
Personal note: My weekly posts are being read by more people than I ever anticipated and people are expecting these to come weekly.
Next year mid-february I'll be on vacation for a month, so I won't be able to do the meetings from 2016/02/18 to 2016/03/10.
If there's anyone who's up for the challenge to take over during a week (and share the load with others) feel free to pm me.
I'm announcing well in advance, so there's more chance to find some people and to not make this a last minute thing.
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, btcd 0.12, bitcoinXT D, 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 :')
