Thoughts on "flexcap"
In December, Mark Friedenbach presented a "flexcap" proposal for a long-term solution to the block size limit: https://scalingbitcoin.org/hongkong2015/presentations/DAY2/3_tweaking_the_chain_2_friedenbach.pdf https://youtu.be/vfIs_trEhao?t=35m45s
He proposes a scheme where miners voluntarily give up part of the block reward (subsidy plus transaction fees) raise the size of the blocks they create (or, conversely, claim reward given up previously to create smaller blocks).
Rules being proposed for the 2MB hard-fork bump of Bitcoin Classic:
Edge case tests missing from current Classic regression test:
Threshold-triggering vote at or just-after the expiration date (two test cases).
Standard transactions (that will be relayed/mined) have been limited to 100,000 bytes for years.
How many signature operations or how much signature hashing can a standard transaction have? (excluding pay-to-script-hash transactions specifically designed to be expensive to validate for the moment)
Back-of-the-envelope estimates:
Lots-of-inputs, one-output transactions are most expensive to validate. A minimal input takes about 120 bytes (74 bytes for a signature plus another 40 or so); 100,000 / 120 rounded up is a max of about 850 inputs.
If each of those spends a 1-of-3 'raw' multisig unspent transaction output using the first key (so three signature operations are needed), you get about 2,500 signature operations for that 100,000 byte transaction.
Single cost metric for transactions and blocks
Building on the work of Jonas Nick, Greg Sanders and Mark Friedenbach (see video: https://youtu.be/37LiYOOevqs?t=2h16m7s slides: https://scalingbitcoin.org/hongkong2015/presentations/DAY2/3_tweaking_the_chain_3_nick.pdf for background)
The goal: create a consensus rule or rules to replace the hard-coded limits Satoshi hurriedly put into place in 2010 that reflects all we have learned since then.
Desirable properties for the rule or rules:
The consensus protocol limits on blocks are:
1 million or fewer bytes canonically-serialized size. 20,000 or fewer "sigops"
Unfortunately, Satoshi implemented those as quick fixes with zero code review and little testing (Bitcoin was not a Big Deal back then, it was the right decision at the time), and the way sigop counting is done is... well, just wrong.
Here's how Satoshi did it, as pseudo-code (see GetLegacySigOpCount in main.cpp for actual code):
For all the transactions in a block:
| I'm experimenting with a "default open" policy for email: | |
| You have my permission in advance to share or publish our email discussions, as long as everybody | |
| else involved in the discussion agrees. | |
| However, if you do share or publish the discussion, you agree to allow me to share or publish | |
| the full context of the discussion, including any past email from you that might be relevant. | |
| The intent of this policy is to save me time-- you don't have to ask me for permission to | |
| republish or share what I say to you. I just ask that you don't misrepresent what I say |
| gavin$ src/bitcoinxt/src/bitcoin-cli -testnet getpeerinfo | grep subver | |
| "subver" : "/Satoshi:0.8.6/", | |
| "subver" : "/Satoshi:0.9.3/", | |
| "subver" : "/Satoshi:0.9.99/", | |
| "subver" : "/Bitcoin XT:0.11.0B/", | |
| "subver" : "/Bitcoin XT:0.11.0C/", | |
| "subver" : "/Bitcoin XT:0.11.0B/", | |
| "subver" : "/Bitcoin XT:0.11.0C/", | |
| "subver" : "/Bitcoin XT:0.11.0C/", | |
| "subver" : "/Bitcoin XT:0.11.0D/", |
I share an office with Brett McDowell, who is the Executive Director of the FIDO Alliance, and who has lots of experience "with IETF, ISO, ITU-T, ANSI, OASIS, W3C, IEEE and the ETSI ICT Standards Board."
He's not a coder, he spends his time working on consensus, process, politics, etc-- all the stuff us coders tend to hate (but is necessary for mature real-world technologies).
I asked about his experience with standards-setting meetings-- my only experience is with the ISO standards process (which is horrible and bureaucratic and a path we do NOT want to go down)-- and our discussion made me even more pessimistic about the upcoming Montreal meeting. I'm hoping maybe we can have a little pre-meeting discussion that might make next week's meeting more productive for everybody.
A few things that came out of my discussion with Brett:
It would make sense if the first meeting was all about gathering requirements. But there needs to be somebody neutral (and trusted to be neutral) to do the gathering, and commit
| 2015-09-02 16:49:44 AcceptToMemoryPool: peer=4 /Satoshi:0.10.2/: accepted 90bc3c35b425c659a58af3c06b2556c718f8f57a720aee051c875ac94806f4a8 (poolsz 1995) | |
| 2015-09-02 16:49:44 AcceptToMemoryPool: peer=1 /Satoshi:0.8.6/: accepted 49ad4d91efe9238e9dbd1c532b54d1d2f365196be5acad7a9a322bdfc8a4ca3e (poolsz 1996) | |
| 2015-09-02 16:49:44 AcceptToMemoryPool: peer=9 /Satoshi:0.11.0/: accepted 5ffc834db9663097056a4805be85c2d43a189c6975340620e78d1c355dde8baa (poolsz 1997) | |
| 2015-09-02 16:49:45 AcceptToMemoryPool: peer=4 /Satoshi:0.10.2/: accepted 8f7eca0d741b84a0f2a5f2bd247107875334770350a3f313d14542a665d9db80 (poolsz 1998) | |
| 2015-09-02 16:49:48 AcceptToMemoryPool: peer=4 /Satoshi:0.10.2/: accepted b735577e7f1da7024d852ffc4d555348c9db7ae33549f96ca357b950f2660b8d (poolsz 1999) | |
| 2015-09-02 16:49:49 AcceptToMemoryPool: peer=1 /Satoshi:0.8.6/: accepted 68bf8db0714043b8edb43c831ee3c17d8f0491233df1d8e236b1656923dbf123 (poolsz 2000) | |
| 2015-09-02 16:49:50 mempool full, dropped 0c588e2480db121b6271410e680a009493cbd1bfeb904d0829d5c11c628ac9ec | |
| 2 |
Making the mempool use a boost::multi_index_container should help a lot.
Pre-validate transactions when first received. Benchmark: how fast are we already? Can we improve cache to get even faster?
Possible scheme: Transaction validity depends on: