From: Anthony Towns <aj@erisian•com.au>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Responsible disclosure of bugs
Date: Tue, 12 Sep 2017 13:37:03 +1000 [thread overview]
Message-ID: <20170912033703.GD19080@erisian.com.au> (raw)
In-Reply-To: <CAPWm=eVCh2FYp=SpOcZFLqz1ZCq3=Z_F9Sj+EAXFvqU-8aMuTg@mail.gmail.com>
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 disclosure and would behave responsibly with the
> information, I don't know where you draw the line on who you tell and who you
> don't.
If you can't pick even a small group that's trustworthy (top five by
market cap as a start [0]? or just major bitcoin wallets / exchanges /
alt node implementations?), then it still seems better to (eventually)
disclose publically than keep it unrevealed and let it be a potential
advantage for attackers against people who haven't upgraded for other
reasons?
I find it hard to imagine bitcoin's still obscure enough that people
aren't tracking git commit logs to use them as inspiration for attacks
on bitcoin users and businesses; at best I would have thought it'd
only be a few months of development time between a fix being proposed
as a PR or committed to master and black hats having the ability to
exploit it in users who are running older nodes. (Or for that matter,
being able to be exploited by otherwise legitimate bitcoin businesses
with an agenda to push, a strong financial motive behind that agenda,
and a legal team that says they'll get away with it)
> 2- Unlike other software, I'm not sure good security for bitcoin is defined by
> constant upgrading. Obviously upgrading has an important benefit, but one of
> the security considerations for Bitcoin is knowing that your definition of the
> money hasn't changed. Much harder to know that if you change software.
Isn't that just an argument for putting more effort into backporting
fixes/workarounds? (I don't see how you do that without essentially
publically disclosing which patches have a security impact -- "oh,
gosh, this patch gets a backport, I wonder if maybe it has security
implications...")
(In so far as bitcoin is a consensus system, there can sometimes be a
positive network effect, where having other people upgrade can help your
security, even if you don't upgrade; "herd immunity" if you will. That
way a new release going out to other people helps keep you safe, even
while you continue to maintain the same definition of money by not
upgrading at all)
If altcoin maintainers are inconvenienced by tracking bitcoin-core
updates, that would be an argument for them to contribute back to their
upstream to make their own job easier; either helping with backports,
or perhaps contributing to patches like PR#8994 might help.
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 various altcoins aren't able to
keep up with security fixes, that's probably valuable information to
provide to the market...
Cheers,
aj
[0] Roughly: BCash, Litecoin, Dash, BitConnect, ZCash, Dogecoin?
I've no idea which of those might have trustworthy devs to work with,
but surely at least a couple do?
next prev parent reply other threads:[~2017-09-12 3:37 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-10 22:03 Simon Liu
2017-09-10 23:02 ` Matt Corallo
2017-09-10 23:28 ` CryptAxe
2017-09-11 2:15 ` Anthony Towns
2017-09-11 11:34 ` Alex Morcos
2017-09-11 17:43 ` Daniel Stadulis
2017-09-11 18:29 ` Gregory Maxwell
2017-09-12 4:47 ` Anthony Towns
2017-09-12 3:37 ` Anthony Towns [this message]
2017-09-12 4:49 ` Sergio Demian Lerner
2017-09-12 16:10 ` Simon Liu
2017-09-14 5:27 ` Anthony Towns
2017-09-22 2:00 ` Nathan Wilcox
2017-09-22 19:53 ` Sergio Demian Lerner
2017-09-12 17:57 ` Gregory Maxwell
2017-09-12 5:18 ` Bryan Bishop
2017-09-12 17:41 ` Gregory Maxwell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170912033703.GD19080@erisian.com.au \
--to=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox