IRC meeting summary for 2016-09-01

• Link to this week logs
• Meeting minutes by meetbot

Notes / short topics

• 0.13 deployment seems to be trouble free
• There have been issues (8532, 8425, 8429) reported with Travis. It seems to be Travis infrastructure causing some of the failures. There’s also a race condition explained by fields: “ the issue there is that the node heights are in sync, but the wallet hasn’t necessarily updated with their txs. So sync_all() followed by a balance check is racy.”

Main topics

• Remaining 0.13.1 issues
• nulldummy and low_s softfork proposals

Remaining 0.13.1 issues

background

Bitcoin Core 0.13.0 is released on 2016/08/23. The next point release 0.13.1 will probably include the segregated witness softfork activation logic, among other bugfixes and optimizations.

meeting comments

There’s a lot of pull request tagged for 0.13.1. Wumpus wonders if there are any that should be prioritized for review as some of them conflict. PR#8393 (Support for compact blocks together with segwit) is a blocker as well as a solution for the DoS issues talked about in the 2016/08/04 and 2016/08/25 meeting. Sipa is not comfortable with the previous suggestion of fully validating everything. Luke-jr and sdaftuar like the approach of the rejection cache using the witness hash instead of txid, however this requires redoing transaction relay which is a big change and has some complications like duplicating several indexes. Most people like the idea of making the feefilter mandatory, although it’s not as much of a silver bullet as some other solutions. Sipa wonders if everyone is fine with doing rejection cache only for non-witness, and heuristics for detecting invalid witness bloating for the most common transaction types, for example checking whether the witness program’s embedded script hash matches the hash of the witness script. Luke-jr thinks a mandatory feefilter will likely cause issues with diverging fee policies and ancestor feerate (Child-Pays-For-Parent), gmaxwell notes CPFP relay is already inhibited to the maximum extent that it could be by feefilter in the current form; mandatory feefilter won’t make it worse.

BlueMatt wonders if the feefilter isn’t de-anonymizing and whether we should round/randomize the amount somewhat. Gmaxwell explains it’s already doing that, but we can’t guarantee that a single node with multiple interfaces can’t be distinguished as the same node, as there are several other ways to do this.

Jeremyrubin mentions his Checkqueue Lockfree is passing tests and would like to hear what people like to see, for it to merge. BlueMatt notes this brings a performance improvement of 10-20% to checkqueue.

Gmaxwell likes to see PR #8594 (Do not add random inbound peers to addrman) backported to 0.13.1.

meeting conclusion

• Review PR #8499 (Check bad witness) and #8525 (Do not store witness txn in rejection cache)

nulldummy and low_s softfork proposals

background

A source of malleability is the ‘S’ value in the ECDSA signature which can have 2 values, a high and low value. Last year a policy was introduced to have nodes require the low-s value (talked about in the 2015-10-08 meeting). Sipa now proposes to make this a consensus rule, instead of just a policy.

This was previous discussed in the 2016/08/11 meeting

meeting comments

This topic needs revisiting as jl2012 discovered that low_s has a really strange implementation issue leaked into the semantics, which is not an issue for standardness, but for consensus we should prefer clean semantics. This can be achieved by doing the ‘only-empty-signature-in-invalid-checksig’ softfork as well. Sipa proposes to do the low_s softfork later with the empty sig rule, and only bundle nulldummy with segwit.

BlueMatt asks whether there’s ever been non-zero length invalid signatures in the chain by using OP_NOT. There’s been at least one case. BlueMatt proposes to make non-zero length invalid signatures non-standard in 0.13.1

meeting conclusion

• Make non-zero length invalid signatures non-standard

Comic relief

BlueMatt      but can be OP_NOT'd, no?
sipa          yes, but nobody sane does that
BlueMatt      sure, but /has/ anyone ever done so?
jtimon        BlueMatt: good question, petertodd has anybody done that? :p
sipa          petertodd: have you done that?
petertodd     sipa: me personally, probably not - I'm a fine arts grad :P

BlueMatt      I was informed that non-0-length invalid sigs is not nonstd
gmaxwell      It is non-standard for segwit. (unless I am on drugs.)
sipa          gmaxwell: you're on drugs

cfields       well, as a nasty short-term fix, we can just throw some sleeps in after sync. that should at least shut travis up while we work on a fix
gmaxwell      sleeps for now sound fine to me. We could all use more sleep.

Participants

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.