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

Mon Nov 16 19:09:31 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-November/000008.html
)

*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.
The dev IRC and mailinglist are for bitcoin development purposes. If you
have not contributed actual code to a bitcoin-implementation, this is
probably not the place you want to reach out to. There are many places to
discuss things that the developers read.

link to this week logs (
http://bitcoinstats.com/irc/bitcoin-dev/logs/2015/11/12#l1447354830.0 )
Meeting minutes by meetbot (
http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-11-12-19.01.html
)

Main topics discussed where:

transaction priority for 0.12
Opt-in replace-by-fee
Versionbits
Chain limits

**transaction priority for 0.12**

- background

Each transaction is assigned a priority, determined by the age, size, and
number of inputs. Which currently makes some transactions free.
This currently has a large amount of code, which makes it harder to
maintain, and is not that optimal since you can't expect miners to include
0-fee transactions.

- meeting comments

Most people seem fine with removing priority in the mempool, but people
should be notified ahead of time this is coming.
sdaftuar proposed a staggered approach, setting the default value for
priority to 0, and remove it entirely in the next release.
petertodd notes there will be a natural staggered process since not
everyone will upgrade to 0.12 instantly and some implementations might not
remove priority at all.
Most wallet-software outside of bitcoin-core don't implement priority
calculations.
As fee estimation becomes more important and many wallet providers use the
bitcoin-core fee estimation, improvements on that are welcome.
Luke-Jr doesn't agree with removing priority, particularly with changing
the mining code to use the priority a transaction has when it enters the
mempool.
Sipa has the idea to add a small fraction of bitcoin days destroyed divided
by the average UTXO age to the fee, so that non-spam-attack transactions
are viewed as if they have a larger fee.

While most agree with the proposal to remove the current priority, there's
still much debate on whether it needs to be replaced for 0.13, and if so,
how.

- meeting conclusion

Review "Improve usage of fee estimation code" (
https://github.com/bitcoin/bitcoin/pull/6134 )
BlueMatt will mail the developer mailinglist announcing the changes. (
https://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg02790.html
)

**Opt-in replace-by-fee**

- 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 an input in
the nSequence field.

- meeting comments

Peter Todd wrote some tools to use replace-by-fee. link:
https://github.com/petertodd/replace-by-fee-tools
It would be nice to have opt-in per output instead of the whole
transaction, however that would be very hard to implement and would have
some privacy concerns.
Luke-Jr would like to see an option to toggle between first-seen-safe/full
RBF and never/opt-in/always. Since there are possibly some objections with
the "always" toggle it should be a separate pull-request.

- meeting conclusion

review and merge nSequence-based Full-RBF opt-in (
https://github.com/bitcoin/bitcoin/pull/6871 )
Peter Todd will write a mail to the list to explain how it works and how
people can not accept opt-in transactions.

**Versionbits**

- background

BIP 9 ( https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki )
Currently softforks have been done by the isSuperMajority mechanism,
meaning when 95% of the last X blocks has a version number higher than Y
the fork is deployed.
A new way of doing this is currently being worked on and that uses all bits
of the version number, appropriately being called versionbits. So instead
of a fork happening when the version is larger than (for example)
00000000011 (3), a fork happens when (for example) the 3rd bit is up (so
00100000011).
This way softforks can be deployed simultaneous and independent of each
other.

- meeting comments

There are 2 different implementations. One from Codeshark (
https://github.com/bitcoin/bitcoin/pull/6816 ) and one from Rusty (
https://github.com/bitcoin/bitcoin/compare/master...rustyrussell:bip-9-versionbits
)
jtimon thinks both implementations are more complicated than they need to
be.
There needs to be a minor revision namely a starting time for proposals.
In general we'd like to get this in soon, but existing softforks need to
complete first.

- meeting conclusion

CodeShark adds a starting time to versionbits.

**Chain limits**

- background

Chain in this context means connected transactions. When you send a
transaction that depends on another transaction that has yet to be
confirmed we talk about a chain of transactions.
Miners ideally take the whole chain into account instead of just every
single transaction (although that's not widely implemented afaik). So while
a single transaction might not have a sufficient fee, a depending
transaction could have a high enough fee to make it worthwhile to mine both.
This is commonly known as child-pays-for-parent.
Since you can make these chains very big it's possible to clog up the
mempool this way.
With the recent malleability attacks, anyone who made transactions going
multiple layers deep would've already encountered huge problems doing this
beautifully explained in let's talk bitcoin #258 (
https://letstalkbitcoin.com/blog/post/lets-talk-bitcoin-258-liquidity-and-malleability
) from 13:50 onwards
proposal:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011401.html
and github: https://github.com/bitcoin/bitcoin/pull/6771 link.

- meeting comments

Wumpus doesn't feel comfortable with merging it because there's some
controversy from companies who exceed the limits (or could be/want to).
jgarzik does feel comfortable with it, and many think it should be merged
as it's easy to revert if needed.
There's little choice as it's not safe from attacks without limits.
We should communicate the replace-by-fee sendmany alternative to long
chains (adding new recipients on existing non-confirmed transactions),
although it won't show up in users wallet yet and block-explorers probably
aren't ready to display it correctly.
Emphasis on the fact it's a change in default values, not a consensus
change, however default values have a lot of power.
The final limits are 25 transactions and 101kb total size for both ancestor
and descendant packages.

- meeting conclusion

jgarzik will merge the pull-request.
Morcos will mail the list once it's merged.

**Participants**

    BlueMatt    Matt Corallo
    petertodd   Peter Todd
    morcos      Alex Morcos
    jgarzik     Jeff Garzik
    gmaxwell    Gregory Maxwell
    wumpus      Wladimir J. van der Laan
    Luke-Jr     Luke Dashjr
    jtimon      Jorge Timón
    btcdrak     btcdrak
    phantomcircuit  Patrick Strateman
    sipa        Pieter Wuille
    CodeShark   Eric Lombrozo
    sdaftuar    Suhas Daftuar
    jg_taxi     jg_taxi
    gavinandresen  Gavin Andresen
    cfields     Cory Fields
    bsm1175321  Bob McElrath

**Comic relief**

    19:53 sipa new topic?
    19:53 wumpus any other topics?
    19:53 petertodd <crickets>
    19:53 jgarzik did we cover jonas while I was in the taxi?
    19:54 sdaftuar ?
    19:54 jtimon ?
    19:54 CodeShark not sure I want to know
    19:54 jgarzik   proposal for new GUI maintainer
    19:54 CodeShark sounds kinky, though
    19:54 petertodd CodeShark: GUI's are pretty kinky

    19:56 BlueMatt ok, end meeting?
    19:56 btcdrak if we can remember the command this week :-)
    19:56 wumpus #meetingend
    19:56 gmaxwell #destroymeeting
    19:56 wumpus #endmeeting
    19:56 Luke-Jr #endmeeting
    19:56 lightningbot Meeting ended Thu Nov 12 19:56:42 2015 UTC.
Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
    19:56 BlueMatt #magicmeetbotincantation
    19:57 petertodd #DoWhatIMean
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-discuss/attachments/20151116/37ad0de5/attachment.html>