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.

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

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.