IRC meeting summary for 2015-11-19
- transaction priority
- dealing with mempool eviction
- Sequence numbers
Opt-in replace by fee needs some extra testing, but otherwise seems ready to go. Some wallet developers are onboard and actively participating, for example GreenAddress.
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.
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.
Creation of priority transactions should be removed from the wallet.
dealing with mempool eviction
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.
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.
Given the tight deadline for 0.12 we detect actual conflict instead of mempool eviction and leave the coins immediately respendable.
BIP 68 repurposes some of the unused nSequence field to a relative locktime, meaning locking inputs until a certain time or blockheight has passed.
We need to wait for BIP113 to be deployed as standardness so BIP 68, 112 and 113 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.
Check BIP68 to match the implementation
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
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.