Topic: Bitcoin dev IRC meeting in layman's terms (2015-12-03) (Read 349 times)

Once again my attempt to summarize and explain the weekly bitcoin developer meeting in layman's terms.  
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



Comic relief