IRC meeting summary for 2016-07-21
Notes / short topics
- 0.13 has been branched of master since a couple of days.
- Jeremyrubin has been working on refactoring checkqueue.h including some nice improvements. Cfields has been working on optimizing the sigcache and proposes to work together to come up with a good representative bench for testing improvements.
- Currently the wallet code is preventing to create outputs below dust by using txminRelayFee. When this was bumped last year in PR#6793 some transactions couldn’t be relayed anymore causing some stress to users. NicolasDorier is working on avoiding such problems in the future in PR#8356.
- Remove ISM
- sigops max size, and the sigops per byte limit
The Bitcoin Core team is working towards the 0.13.0 release (full schedule) and RC1 is available since 2016-07-20.
RC1 got some feedback noticing that when encrypting the wallet, it uses the same HD seed, which means the HD seed has been unencrypted on the disk when the wallet was created. Jonasschnelli is working on a fix to create a new HD seed after encrypting the wallet.
A common complaint is the lack of a way to export the HD seed. Jonasschnelli has a pull request which is easy to review and has a low impact that exports the seed to dumpwallet. Importing is a different issue with much more impact as the wallet currently doesn’t support multiple seeds. This is a feature for 0.14.
Luke-jr notes the new default policy of using blockmaxweight isn’t performing as well as using blockmaxsize in the current environment. He made a pull request to change this. This is a pretty large change and requires some more discussion.
- review PR #8206
Before BIP9 softforks where done by the isSuperMajority (ISM) mechanism, meaning when 95% of the last 1000 blocks had a version number higher than X the fork was deployed. BIP68, BIP112 and BIP113 where simultaneously deployed using BIP9.
NicolasDorier made a pull request to remove ISM and hard code softforks made by ISM in regtest.
Gmaxwell wanted to remove ISM in 0.13, but didn’t want to introduce a conflict with the segwit merge so he held it off.
Discussion quickly sidetracks into refactoring-related issues.
- review PR#8391
- Remove ISM before refactoring it’s code
sigops max size, and the sigops per byte limit
To prevent a signature operations (SIGOPS) attack developers introduced a bytespersigop option to limit the amount of sigops in a transaction we relay and mine. This was discussed in the 2015-11-05 meeting.
There have been complaints that this limit has made some bare multisig outputs difficult to spend.
There are two proposed solutions for this: one by sipa and one by f139975. Sipa feels the latter makes it needlessly more complicated, but apart from that isn’t strongly against it.
Luke-jr argues the reason the limit was introduced was to filter spam and allowing high sigops transactions but with high fees is sending an implicit endorsement to needlessly use lots of sigops. Gmaxwell disagrees and states he wouldn’t have supported the limit for filtering reasons. Currently to bypass the limit they bloat their transactions to get more sigops in, PR #8365 would fix this, we can think about better policies in the long run later, sdaftuar argues.
Some discussion ensues whether these transactions should be viewed as spam or not.
Take a look at PR #8364 and #8365
|wumpus||Wladimir van der Laan|
This summary was compiled without input from any of the participants in the discussion, so any errors are the fault of the summary author and not the discussion participants.