Here's the conversation I had with Mike that Gregory requested a
link to:
Thanks!
Bad or hacked client devs is indeed a huge, worrying problem.
The official client is addressing this with a system called
gitian, where multiple developers all compile the same source to
the same binary and then sign the results. Multi-signatures
raise the bar for releasing hacked clients a lot. We're starting
to investigate this with bitcoinj too, but it's a lot of work.
Generally, the more people you have to involve in a
conspiracy, the less likely it is to succeed. If a few miners
started to dominate the system they have strong financial
incentives to cheat, alternatively, they may be subjected to
government pressure. Having to get the client developers
involved too makes it much harder, especially as users have to
actually upgrade.
I started a thread on the development mailing list with your
suggestion, by the way.
On Mon, Jun 25, 2012 at 1:00 AM, Daniel
Lidstrom lidstro...@gmail.com
wrote:
Hey Mike,
I put our conversation in the email for easy reference.
In the unlikely event of a miner conspiracy to print
money, is it really so much of a further stretch to think
the developers of a widely used client could also be
involved? (Well, maybe, since miners are unaccountable
and developers are not. OTOH if most users are
apathetic...) Also, isn't the advantage for lightweight
clients of SPV over the server-client model that you don't
have to trust any operator? Maybe I'm being too much of a
purist here...
Regarding errors being cheap to send and expensive to
verify, compartmentalizing them the way I suggested before
would make them individually cheaper to verify. Just
throwing around ideas: requiring the error message be
received by a quorum of peers before checking, and
dropping misbehaving or unreliable peers could help.
Also, not verifying error messages unless the peers
relaying them are willing to send all the data necessary
to do so would help. Hashcash could also be used to
balance the costs to send and to verify a given type of
error message. I like your idea to only check errors in
blocks that are split points, and the length of the split
could also be a consideration.
Can we move further conversations
to email please? SMF kind of sucks as an inbox.
Anyway, yes, your proposal makes a lot of sense,
although I think in practice this is unlikely to be an
issue. If a majority of miners did start mining on a
chain with new rules, even if SPV clients couldn't
detect the switch automatically it's very likely the
developers of those clients would notify the users out
of band in some way. For example, by pushing an update
to users that explains the new rules to them and tells
them how they can cash out of the Bitcoin economy if
they disagree with the new consensus.
If users are on the losing side of a rule change and
want to stay there (eg, maybe most non-miners want to
stay on the slower chain), then the client can just
checkpoint the first block after the rule change
occurred. Now even though there's a harder chain with
the new rules, the client will stay with the old rules
despite being blind to them. There's nothing that says
checkpoints have to be hard coded - clients could poll
the client developers every day to get new ones. So as
long as the SPV devs are on the ball, most users would
stay on the old rules even if the software can't do it
by itself.
All that said, broadcasting messages proving a block
broke the rules is a nice backstop if it can be done
without excessive complexity. There are some details to
think about. These messages would be cheap to create and
expensive to verify. There has to be something that
stops me claiming to SPV clients that every single block
is invalid and forcing them to do tons of useless work.
Perhaps only blocks that
