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

[G1lius .]

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/000010.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.


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


Main topics discussed where:

transaction priority
dealing with mempool eviction
Sequence numbers


**Short topics/notes**

Opt-in replace by fee ( https://github.com/bitcoin/bitcoin/pull/6871 )
needs some extra testing, but otherwise seems ready to go. Some wallet
developers are onboard and actively participating, for example
GreenAddress.


**transaction priority**

- 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

If we don't stop support for priority in transaction creation we also need
a mempool area for priority, or those transactions will always get evicted.

If we develop a better framework to support these kind of metrics we can
add it back.
Plan is to remove the priority transaction creation from the wallet, not
the mining part.



- meeting conclusion

Creation of priority transactions should be removed from the wallet.


**dealing with mempool eviction**

- background

When a transaction is relayed across the network it is held by the nodes in
memory, until it gets into a block. All these transactions that sit in
memory are called the memorypool or mempool for short.
Like we could see during the spam-attack if there's a big back-log of
transactions that couldn't make it in the blockchain this mempool can get
pretty big resulting in nodes crashing.

To stop this from happening devs created a mechanism to reject and/or
remove transactions from the mempool.


- meeting comments

Current problem: when a wallet transaction is rejected by the mempool, the
wallet considers the resulting transaction as "conflicting" and will
happily respend the inputs.
sipa proposes to make the wallet only treat a transaction as conflicting if
it has non-existing inputs.
It should however consider it respendable at some time later on.
You could add a way to manually remove transactions, or tag is as removed,
or archive it.
You could also do something separate that marks the transaction as
respendable, as removal gives the impression the transaction can't be mined
in the future.
Options that are wanted: a "respend with higher fee" option and an option
to forget about a transaction completely, we need a minimum viable idea for
0.12 though.


- meeting conclusion

Given the tight deadline for 0.12 we detect actual conflict instead of
mempool eviction and leave the coins immediately respendable.

**Sequence numbers**

- background

BIP 68 ( https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki )
repurposes some of the unused nSequence field to a relative locktime,
meaning locking inputs until a certain time or blockheight has passed.


- meeting comments

We need to wait for BIP113 to be deployed as standardness so BIP 68 (
https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki ), 112 (
https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki ) and 113 (
https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki ) can go in
a softfork.
There's upcoming projects that already use sequence numbers.
Merging BIP68 would make BIP112 easier to review and would stop the need to
rebase all the time.
If we feel the 68/112 are sufficiently reviewed and mature they could go in
as standardness rules.
The BIP text doesn't seem to reflect what's written in the code.


- meeting conclusion

Check BIP68 to match the implementation (
https://github.com/bitcoin/bitcoin/pull/6312 )



**Participants**

    sipa                  Pieter Wuille
    gmaxwell           Gregory Maxwell
    morcos             Alex Morcos
    jtimon               Jorge Timón
    wumpus             Wladimir J. van der Laan
    btcdrak              btcdrak
    jgarzik               Jeff Garzik
    petertodd           Peter Todd
    Luke-Jr              Luke Dashjr
    BlueMatt            Matt Corallo
    jonasschnelli      Jonas Schnelli
    CodeShark          Eric Lombrozo
    sdaftuar              Suhas Daftuar
    gavinand1esen     Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-discuss/attachments/20151123/37a4b19c/attachment.html>