IRC meeting summary for 2015-11-05

Log

• link to this week logs
• Meeting minutes by meetbot

Main topics

• Sigcache performance
• Performance goals for 0.12
• transaction priority
• sigops flooding attack
• chain limits

Short topics/notes

Note: cfields, mcelrath and BlueMatt (and maybe more) missed the meeting because of daylight saving time.

Closing date for proposals for the scaling bitcoin workshop is the 9th.

Check to see if there are any other commits for the 0.11.2 RC. As soon as 6948 and 6825 are merged it seems good to go.
We need to move fairly quick as there are already miners voting for CLTV (F2Pool). Also testnet is CLTV locked already and is constantly forking.
0.11.2 RC1 has been released as of today: https://bitcoin.org/bin/bitcoin-core-0.11.2/test/

Most of the mempool-limiting analysis assumed child-pays-for-parent, however that isn’t ready for 0.12 yet, so we should think about possible abuses in context of the existing mining algorithm.

Because of time-constrains opt-in replace-by-fee has been deferred to next weeks meeting, but most people seem to want it in 0.12. sdaftuar makes a note that we need to make clear to users what they need to do if they don’t want to accept opt-in transactions.

Sigcache performance

background

The signature cache, which is in place to increase performance (by not having to check the signature multiple times), and to mitigate some attacks currently has a default limit of 50 000 signatures.
Sipa has a pull-request which proposes to:
Change the limit from number of entries to megabytes
Change the default to 40MB, which corresponds to 500 000 signatures
Store salted hashes instead of full entries
Remove entries that have been validated in a block

meeting comments

Sipa did benchmarks for various signature cache sizes on hitrate in blocks (how many of the cached signatures are in the block).
The maximum sigcache size was 68MB, resulting in a 3% miss-rate. Some blocks though have extremely high miss rates (60%) while others have none. Likely caused by miners running different policies.
Gmaxwell proposed to always run script verification for mempool transactions, even if these transactions get rejected into the mempool by the clients policy.
The result of that is that even a 300MB sigcache size only gets down to 15% misses. So there’s too much crap being relayed to keep any reasonable sized cache.
Gmaxwell points out downsides to not checking any rejected transactions, namely: there are some DOS attacks possible, and you increase your misrate if you set a policy which is more restrictive than the typical network, which might result in a race to the bottom.

meeting conclusion

Sipa continues his work and seeks out other strategies

Performance goals for 0.12

background

Bitcoin-core 0.12 is scheduled for release December 1st.

meeting comments

Everybody likes to include secp256k1 ASAP, as it has a very large performance increase.
Some people would like to include the sigcache pull-request, BIP30, modifyNewCoins and a createNewBlock rewrite if it’s ready.
Wumpus advises against merging last-minute performance improvements for 0.12.

meeting conclusion

Mentioned pull-requests should be reviewed, prioritizing CreateNewBlock

transaction priority

background

Each transaction is assigned a priority, determined by the age, size, and number of inputs. Which makes some transactions free.

meeting comments

Sipa thinks we should get rid of the current priority completely and replace it with a function that modifies fee or size of a transaction.
There’s a pull-request available that optimizes the current transaction priority, thereby avoiding the political debate that goes with changing the definition of transaction priority.
Luke-jr thinks the old policy should remain possible.

meeting conclusion

Check to see if PR #6357 is safe and efficient enough.

sigops flooding attack

background

The number of ECDSA signature-checking operations or sigops is currently limited to 20 000 per block. This in order to prevent miners creating blocks that take ages to verify as those operations are time-consuming.
You could however construct transactions that have a very high sigops count and since most miners don’t take into account the sigops count they end up with very small blocks because the sigop limit is reached.
This attack is described here.

meeting comments

Suggestion to take the number of sigops relative to the maximum blocksize into account with the total size. Meaning a 10k sigops transaction would currently be viewed as 500kB in size (for that single transaction, not towards the block).
That suggestion would be easy to change in the mining code, but more invasive to try and plug that into everything that looks at feerate.
This would also open up attacks on the mempool if these transactions are not evicted by mempool limiting.
Luke-jr has a bytes-per-sigop limit, that filters out these attack transactions.

meeting conclusion

More analysis should be done, people seem fine with the general direction of fixing it.

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 from 13:50 onwards)
Proposal and github link.

meeting comments

sdaftuar’s analysis shows that 40% of blocks contain a chain that exceeds the proposed limits. Even a small bump doesn’t make the problem go away.
Possible sources of these chains: a service paying the fees on other transactions (child-pays-for-parent), an iOS wallet that gladly spends unconfirmed change. A business confirms they use child-pays-for-parent when they receive bitcoins from an unspent chain.
It is possible that these long chains are delivered to miners directly, in which case they wouldn’t be affected by the proposed relay limits (and by malleability).
Since this is a problem that needs to be addressed, people seem fine with merging it anyway, communicating in advance to let businesses think about how this affects them.

meeting conclusion

Merge “Policy: Lower default limits for tx chains”
Morcos will mail the developer mailing list after it’s merged.

Participants

morcos          Alex Morcos  
gmaxwell        Gregory Maxwell  
wumpus          Wladimir J. van der Laan  
sipa            Pieter Wuille  
jgarzik         Jeff Garzik  
Luke-Jr         Luke Dashjr  
phantomcircuit  Patrick Strateman  
sdaftuar        Suhas Daftuar  
btcdrak         btcdrak  
jouke           ??Jouke Hofman??  
jtimon          Jorge Timón  
jonasschnelli   Jonas Schnelli  

Comic relief

20:01	wumpus		#meetingend   
20:01	wumpus		#meetingstop    
20:01	gmaxwell   Thanks all.   
20:01	btcdrak		#exitmeeting  
20:01	gmaxwell	   #nomeetingnonono  
20:01	btcdrak		#meedingexit  
20:01	wumpus		#endmeeting   
20:01	lightningbot  Meeting ended Thu Nov 5 20:01:29 2015 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot .
20:01	btcdrak		#rekt

Credits

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.