Topic: Bitcoin dev IRC meeting in layman's terms (2015-11-05) (Read 497 times)

0.12 will have the wallet enabled with pruning. Pruning is already enabled in 0.11 with the -prune option when you run it.

Thanks for effort. Does anyone know if 0.12 will have finally the pruning option so we can run a node without having to download the entire blockchain and use the wallet? I know it can be done now but it requires some sort of geeky stuff and you can't even use the wallet when you do that for some reason. I need a more simple option.

I don't check this forum very often, but someone reminded me to post this here too (it's crossposted at reddit/voat/bitcoin.com/bitcoin-discuss mailing list)
I'll post the latest one in a few minutes.

Once again my attempt to summarize and explain the weekly bitcoin developer meeting in layman's terms. 
Link to last weeks summarization   


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, including this forum.


link to this week logs 
Meeting minutes by meetbot 


Main topics discussed where: 
 
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

Comic relief