IRC meeting summary for 2015-12-10

Logs

• link to this week logs
• Meeting minutes by meetbot

Topics

• BIP 68 semantic change

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

morcos          Alex Morcos   
btcdrak         btcdrak  
wumpus          Wladimir J. van der Laan  
BlueMatt        Matt Corallo   
gmaxwell        Gregory Maxwell   
jonasschnelli   Jonas Schnelli   
sdaftuar        Suhas Daftuar  
gavinandresen   Gavin Andresen  
Lightsword      Lightsword

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.