[inline responses]
On Thu, Sep 14, 2017 at 2:27 PM, Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Tue, Sep 12, 2017 at 09:10:18AM -0700, Simon Liu wrote:
> > It would be a good starting point if the current policy could be
> > clarified, so everyone is on
On Tue, Sep 12, 2017 at 09:10:18AM -0700, Simon Liu wrote:
> It would be a good starting point if the current policy could be
> clarified, so everyone is on the same page, and there is no confusion.
Collecting various commentary from here and reddit, I think current de
facto policy is something
On Tue, Sep 12, 2017 at 4:49 AM, Sergio Demian Lerner via bitcoin-dev
wrote:
> It also implies that some times a researcher works hard to investigate a
> vulnerability and later he finds out it was previously reported. It also
> means that the researcher
It would be a good starting point if the current policy could be
clarified, so everyone is on the same page, and there is no confusion.
On 09/11/2017 09:49 PM, Sergio Demian Lerner via bitcoin-dev wrote:
> Historically people have published vulnerabilities in Bitcoin only after
>>80% of the
Historically people have published vulnerabilities in Bitcoin only after
>80% of the nodes have upgraded. This seems to be the general (but not
publicly stated) policy. If you're a core developer and you know better,
please correct me.
This means that:
- a critical vulnerability, like a remote
On Mon, Sep 11, 2017 at 10:37 PM, Anthony Towns via bitcoin-dev
wrote:
> All of those things seem like they'd help not just altcoins but bitcoin
> investors/traders too, so it's not even a trade-off between classes of
> bitcoin core users. And if in the end
On Mon, Sep 11, 2017 at 10:43:52AM -0700, Daniel Stadulis wrote:
> I think it's relevant to treat different bug severity levels with different
> response plans.
That makes sense.
For comparison, Monero defines a response process that has three levels
and varies the response for each:
] a.
On Mon, Sep 11, 2017 at 07:34:33AM -0400, Alex Morcos wrote:
> I don't think I know the right answer here, but I will point out two things
> that make this a little more complicated.
> 1 - There are lots of altcoin developers and while I'm sure the majority would
> greatly appreciate the
I think it's relevant to treat different bug severity levels with different
response plans.
E.g.
Compromising UTXO custody (In CVE-2010-5141, OP_RETURN vulnerability)
Compromising UTXO state (In CVE-2013-3220, blockchain split due to Berkeley
DB -> LevelDB upgrade, CVE-2010-5139 Overflow bug,
I don't think I know the right answer here, but I will point out two things
that make this a little more complicated.
1 - There are lots of altcoin developers and while I'm sure the majority
would greatly appreciate the disclosure and would behave responsibly with
the information, I don't know
On Sun, Sep 10, 2017 at 07:02:36PM -0400, Matt Corallo via bitcoin-dev wrote:
> I believe there continues to be concern over a number of altcoins which
> are running old, unpatched forks of Bitcoin Core, making it rather
> difficult to disclose issues without putting people at risk (see, eg,
>
I don't think we should put any Bitcoin users at additional risk to help
altcoins. If they fork the code they are making maintenance their own
responsibly.
It's hard to disclose a bitcoin vulnerability considering the network is
decentralised and core can't force everyone to update. Maybe a
I believe there continues to be concern over a number of altcoins which
are running old, unpatched forks of Bitcoin Core, making it rather
difficult to disclose issues without putting people at risk (see, eg,
some of the dos issues which are preventing release of the alert key).
I'd encourage the
Hi,
Given today's presentation by Chris Jeffrey at the Breaking Bitcoin
conference, and the subsequent discussion around responsible disclosure
and industry practice, perhaps now would be a good time to discuss
"Bitcoin and CVEs" which has gone unanswered for 6 months.
14 matches
Mail list logo