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 so some things might be incorrect or plain wrong.   
There are no decisions being made in these meetings, but since a fair amount of devs are present it's a good representation. 
Copyright: Public domain


link to this week logs 
Meeting minutes by meetbot



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.   


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 softfork that will activate today. Not updating will mean you'll be trusting miners to produce valid blocks.

As expected a shorter meeting today as well, since a lot of developers are still traveling.


BIP 68 semantic change

- 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.   
When a block is created miners include a timestamp. This timestamp has to be between the median of the previous 11 blocks and the network-adjusted time +2 hours. So this timestamp can vary a decent amount from the real time. 
With the introduction of lock-time transactions, that are only valid after a certain time, miners are incentivised to lie about the time in order to include time-locked transactions (and their fees) that wouldn't otherwise be valid. 
BIP113 enables the usage of GetMedianTimePast (the median of the previous 11 blocks) from the prior block in lock-time transactions to combat this behavior. Users can compensate for this by adding 1 hour (6 blocks) to their lock times.


- meeting comments

It would make sense to just always use MedianTimePast for BIP68, regardless of BIP113, although BIP 113 is still needed to change the semantics of nLockTime. Implementation by Morcos.     
BIP 68 would nullify the CreateNewBlock performance increase recently made in #6898, discussion about a fix are made in #7176, discussion and commits for a fix of the new approach (always using MedianTimePast) are on #7187   
There's some possible issues with the GUI display of currently locked transactions. If a block gets orphaned and a confirmed input becomes unconfirmed it might make a previous acceptable transaction be evicted by the mempool and you might want to inform the user it is locked (as opposed to not visible). 
Morcos proposes to leave this issue and clean it up after the softfork, as it doesn't seem important enough to be backported. UI/Wallet changes are usually separated from the softfork changes anyway.   
In this line of thought morcos poses the question of whether there's been some thought and/or objections to loosen the current behaviour of the mempool to only contain transactions valid for the next block.
btcdrak mentions ajtowns wrote some python demos for BIP68+CSV which will be useful for testers. 



- meeting conclusion

Take a look at the BIP68 approach of #7184   
Take a look at the CreateNewBlock performance fix for the above aproach at #7187



Participants