IRC meeting summary for 2016-07-21

Overview


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.

Main topics

  • 0.13.0
  • Remove ISM
  • sigops max size, and the sigops per byte limit

0.13.0

background

The Bitcoin Core team is working towards the 0.13.0 release (full schedule) and RC1 is available since 2016-07-20.

meeting comments

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.

meeting conclusion

Remove ISM

background

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.

meeting comments

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.

meeting conclusion

  • review PR#8391
  • Remove ISM before refactoring it’s code

sigops max size, and the sigops per byte limit

background

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.

meeting comments

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.

meeting conclusion

Take a look at PR #8364 and #8365

Comic relief

19:59	lightningbot    Meeting ended Thu Jul 21 19:59:17 2016 UTC
20:03	sipa            ok, i'm going to catch some pokemon
20:03	sipa            i mean
20:03	sipa            i'm going for a walk

Participants

IRC nick Name/Nym
sipa Pieter Wuille
gmaxwell Gregory Maxwell
wumpus Wladimir van der Laan
btcdrak BtcDrak
kanzure Bryan Bishop
cfields Cory Fields
sdaftuar Suhas Daftuar
jonasschnelli Jonas Schnelli
MarcoFalke Marco Falke
luke-jr Luke Dashjr
jtimon Jorge Timón
morcos Alex Morcos
instagibbs Gregory Sanders
jeremyrubin Jeremy Rubin
CodeShark Eric Lombrozo
NicolasDorier Nicolas Dorier
BlueMatt Matt Corallo

Disclaimer

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.