Hi Dave,
> Could you tell us more about the disclosure process you followed? I'm
> surprised to see it disclosed without any apparent attempt at patching.
> I'm especially concerned given your past history of publicly revealing
> vulnerabilities before they could be quietly patched[1] and the conflict
> of interest of you using this disclosure to advocate for a policy change
> you are championing.
In defense of Peter, I don't think there is a low-hanging fruit that could have
been landed easily in Bitcoin Core. The most obvious ones could have been
a) to reduce `MAX_STANDARD_TX_WEIGHT` or b) a new rule `max_replacement_bandwidth`
or c) a new absolute-fee based penalty on bandwidth replacement cost.
All hard to integrate in a covert fashion without attracting some attention from the
community, which would certainly ask why we're changing the marginal bandwidth cost.
Potentially, impacting unfavorably some use-cases.
Certainly, Peter's report could have integrated a disclosure timeline at the
example of CVE-2018-17144 [0], which I can recommend to anyone to follow doing
security research or servicing as a security point of contact in our field.
I don't see the conflict of interest in the present disclosure ? It is public information
that Peter is championing RBFR [1]. I'm not aware of any private interest unfavorably
influencing Peter's behavior in the conduct of this security issue disclosure.
One of the established principles in infosec, it's up to software vendors to explain
why their softwares is broken or why they are "lazy" fixing issues. Assuming sufficient
technical proof has been initially communicated by the reporter.
If you're dissatisfied by Peter's conduct in the handling of this disclosure, you're welcome
to author vulnerability reports or assume the role of coordinating patching responses yourself
more often. Assuming you can be reasonably trusted here.
Finally, in matters of ethics, talking as an external observer can be cheap sometimes and it is
best to "lead-by-example", imho.
Best,
Antoine