IRC meeting summary for 2016-09-01
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.”
- Remaining 0.13.1 issues
- nulldummy and low_s softfork proposals
Remaining 0.13.1 issues
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.
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.
nulldummy and low_s softfork proposals
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
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
- Make non-zero length invalid signatures non-standard
|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.