IRC meeting summary for 2015-10-15
- Main topics
- Mempool limiting
- sendheaders BIP
- dev/discuss list policy
- Comic relief
- Mempool limiting
- sendheaders BIP
- dev/discuss list policy
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 are trying to find a way to limit this mempool, so a mechanism to reject and/or remove transactions from the mempool. The hard part here is to make it so nodes can’t be attacked by abusing this mechanism.
So far the devs are going with TheBlueMatt’s proposal of throwing away the cheapest txn and setting the min relay fee to it
While testing, sipa encountered transactions that took 200ms to be accepted into the mempool.
As it’s the first time he has benchmarked this and the pull-request shouldn’t make an impact on these times it likely doesn’t have anything to do with this. However, such times are bad either way.
The average time in sipa’s tests is 4ms. (After the meeting Morcos did some benchmarking and confirmed it was not specific to this PR, and pointed out the outliers come from CheckInputs and HaveInputs (as you might guess, having to do with checking the inputs)
Question on why we should revert the minrelay (minimum fee for nodes to relay a transaction) back to 1000 (it has been set to 5000 to quick-fix the mempool issues), sipa thinks it should be floating as well or the dust limit becomes ineffective.
Review PR 6722 Limit mempool by throwing away the cheapest txn and setting min relay fee to it
Morcos/sipa will do some more benchmarks and comment on the PR ( morcos’ benchmark results )
send headers BIP
Copy/paste from the BIP:
Since the introduction of “headers-first” downloading of blocks in 0.10, blocks will not be processed unless they are able to connect to a (valid) headers chain. Consequently, block relay generally works as follows:
- A node (N) announces the new tip with an “inv” message, containing the block hash
- A peer (P) responds to the “inv” with a “getheaders” message (to request headers up to the new tip) and a “getdata” message for the new tip itself
- N responds with a “headers” message (with the header for the new block along with any preceding headers unknown to P) and a “block” message containing the new block
However, in the case where a new block is being announced that builds on the tip, it would be generally more efficient if the node N just announced the block header for the new block, rather than just the block hash, and saved the peer from generating and transmitting the getheaders message (and the required block locator).
Question on how to move forward. How to let the nodes know you want the blockheader instead of the blockhash.
- Extend the version message.
- Have an “options” message that can send flags.
- Send a “sendheaders” message early when connecting so the way peers want their block announcement is immediately known.
- Send a “sendheaders” message at any time, changing the way peers want their block announcement from hashes to headers.
No one likes to extend the version message further.
There’s no strong advantage to have an “options” message over a “sendheaders” message.
Having the message being sent early on might be too constraining. Possible usecase from morcos: “its entirely possible some future optimization may say, i want to send sendheaders to these peers b/c they announce a lot of new stuff to me and not these others b/c they don’t”.
Most people like this to be enable-only, so no message to get back to receiving blockhashes. Which is how the BIP was drafted.
sdaftuar does a pull-request for the BIP to get a number assigned and proceeds with the BIP as drafted.
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.
copy/paste from IRC, since I don’t know what this specifically means:
CodeShark: so right now it’s just a unit that implements the versionbits logic but does not demonstrate its usage
I thought it would be better to actually integrate in a separate PR, but I can add a demonstration
sipa: separate commit, same PR - i think we need something that’s mergable as a whole, to be able to see whether the whole thing easily backports
Codeshark (who’s implementing versionbits) had some more remarks but no one present had seemed to reviewed it, so not much use in discussing things further.
review versionbits implementation
dev/discuss list policy
The bitcoin-dev mailing list is intended for technical discussions only. There’s things that don’t belong there but need to be discussed anyway.
Now this is done in bitcoin-dev, but the volume of this is getting too big.
There’s recently also an influx of really inappropriate posts, level kindergarden.
For the things that don’t belong on bitcoin-dev, but need to be discussed anyway there’s a new list being created namely bitcoin-discuss as well as clear policies and moderation for both.
Bitcoin-discuss was created, but the admin password wasn’t distributed to jgarzik who’s willing to guide the moderation.
Seperate moderation-proposals have been done meanwhile.
People just want it to move on.
Since none of the people who proposed a moderation-scheme are present we’ll let them discuss it among each other and post their decisions publicly.
CheckLockTimeVerify (CLTV) repurposes the nSequence field (nSequence are 4 bytes intended for sequencing time-locked transactions, but this never got used). However, there’s no way use these values in a bitcoin script.
CheckSequenceVerify (CSV) makes this field accessible to bitcoin scripts.
EDIT: Turns out this is not entirely correct as it is relative locktime that repurposes the nSequence field.
CLTV is pretty much done.
Check to see maaku moving one of the bits to allow for other implementations to have better granularity has any objections.
As long as we’re using as few bits as possible the exact semantics are less important for most people.
sipa points out a possible bug that influences the wallet.
CSV is not on target for the end of of the month, although a lot of work and progress has been made.
- Review and ACK/NACK of 6312 BIP-68: Mempool-only sequence number constraint verification
- Review and ACK/NACK of 6566 BIP-113: Mempool-only median time-past as endpoint for lock-time calculations
wumpus Wladimir J. van der Laan sipa Pieter Wuille btcdrak btcdrak gmaxwell Gregory Maxwell morcos Alex Morcos maaku Mark Friedenbach CodeShark Eric Lombrozo BlueMatt Matt Corallo sdaftuar Suhas Daftuar warren Warren Togami GreenIsMyPepper Joseph Poon davec Dave Collins cfields Cory Fields jonasschnelli Jonas Schnelli
19:21 sdaftuar it sounds like everyone is ok with the BIP as drafted then?
19:21 wumpus yes
19:21 gmaxwell I think so.
19:22 davec yes
19:22 sipa well, the only person with concerns was cfields, who doesn’t seem to be here :)
19:22 gmaxwell sipa: he can raise concerns later too!
19:22 cfields dammit!
19:22 sipa cfields: too late!
19:22 gmaxwell ha
19:23 cfields did i really miss my third one of these in a row?
This summary was originally compiled by Stefan Gilis aka “G1lius” and posted to the bitcoin-dev 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.