[bitcoin-discuss] Bitcoin dev IRC meeting in layman's terms (2015-12-10)

G1lius . g1liusbitcoin at gmail.com
Mon Dec 14 17:14:56 UTC 2015


Once again my attempt to summarize and explain the weekly bitcoin developer
meeting in layman's terms.
Link to last weeks summarization:
http://lists.linuxfoundation.org/pipermail/bitcoin-discuss/2015-December/000036.html


*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 (
http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-12-10-19.01.log.html
)
Meeting minutes by meetbot: (
http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-12-10-19.01.html
)



**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, *client software which attempts to alter
the Bitcoin protocol without overwhelming consensus* version 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 ( https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki )
 Consensus-enforced transaction replacement signaled via sequence numbers ,
and current implementation: https://github.com/bitcoin/bitcoin/pull/6312.
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 ( https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki )
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. [mplementation ( https://github.com/bitcoin/bitcoin/pull/7184 )
by Morcos.
BIP 68 would nullify the CreateNewBlock performance increase recently made
in #6898 ( https://github.com/bitcoin/bitcoin/pull/6898 ), discussion about
a fix are made in #7176 ( https://github.com/bitcoin/bitcoin/issues/7176 ),
discussion and commits for a fix of the new approach (always using
MedianTimePast) are on #7187 ( https://github.com/bitcoin/bitcoin/pull/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 (
https://github.com/bitcoin/bitcoin/pull/7184 )
Take a look at the CreateNewBlock performance fix for the above aproach at
#7187 ( https://github.com/bitcoin/bitcoin/pull/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??
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-discuss/attachments/20151214/d5c9df04/attachment.html>


More information about the bitcoin-discuss mailing list