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 DisclaimerPlease 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 commentsSipa 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 commentsEverybody 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 conclusionMentioned pull-requests should be reviewed, prioritizing
CreateNewBlock transaction priority- backgroundEach transaction is assigned a priority, determined by the age, size, and number of inputs. Which makes some transactions free.
- meeting commentsSipa 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 conclusionCheck to see if
PR #6357 is safe and efficient enough.
sigops flooding attack- backgroundThe 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 commentsSuggestion 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 conclusionMore 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 commentssdaftuar'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 conclusionMerge
"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
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
