From: Mike Hearn <mike@plan99.net>
To: Gregory Maxwell <gmaxwell@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
Date: Thu, 24 Apr 2014 10:39:41 +0200 [thread overview]
Message-ID: <CANEZrP3vT6Q72X6PrcDQ8_fDeF90WmV4-M045Ac=kJY+PhuAdg@mail.gmail.com> (raw)
In-Reply-To: <CAAS2fgQV0=QfCWhwVh6-mw=eg9MDd1E21P_7rFAnGp0P43c1Fw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2919 bytes --]
On Thu, Apr 24, 2014 at 10:19 AM, Gregory Maxwell <gmaxwell@gmail.com>wrote:
> This is not voting.
>
It absolutely is! It was widely discussed as such at the time, here is a
thread where people ask how to vote and the operator of Eclipse said he was
removing his vote for P2SH:
https://bitcointalk.org/index.php?topic=60937.0
You might not feel it's a particularly fair or representative vote, but
it's still miners saying "I support enforcement of this new rule" or "I do
not support this" where the majority of cast votes wins. Some miners have
more votes than others, but it's still a vote.
> Yes, making really distributed systems that work in a complex world is
> hard. It certantly would be /easier/ to just declare miners "trusted
> parties"
>
Miners *are* trusted parties, they are just not all trusted simultaneously.
Bitcoin can tolerate a small number of dishonest miners whilst producing a
degraded service. It cannot work if all miners are dishonest or decide to
deviate from their intended operation, like if they all produce empty
blocks. The white paper made this clear from the start, and it's also
common sense.
Allowing the majority of honest miners to keep the dishonest ones in check
is what Bitcoin is all about. I don't understand this view that a very
small change to the existing protocol is somehow terrible or impossible,
but expecting everyone to simply build an entirely new system from scratch
is easy and inevitable. I'd much prefer to just keep the existing system
working as well as it has so far, and I think that is true of most users
too.
> Temporarily censoring transactions by orphaning otherwise valid blocks
> that contain them for as long as you retain a majority is possible
No, coinbases are deletable. If some miners fork the chain and build a
longer one, the others will all switch to it and the coinbases blocks they
previously mined will never become spendable (effectively they were
"deleted" before maturity). Only if the other miners also blacklist the
majorities fork and never join it, then the majority for some reason gives
up and rejoins the minority, is what you described correct. But why would
they do that? If they're the majority then all the other nodes will follow
them. They have no incentive to throw away their fork and rejoin the
minority chain ever again.
I think the root of this disagreement is whether the block chain algorithm
left by Satoshi is somehow immutable and itself the end, or whether it's
(as I see it) just a means to an end and therefore an algorithm that can be
tweaked and improved, to get us closer to the goal.
If the end is a useful payments system, as decentralised as possible, that
prevents double spending, then this proposal is a simple enhancement of the
current system that ensures corrupt miners don't get paid by honest users
for services they didn't provide, thus discouraging a particular kind of
attack.
[-- Attachment #2: Type: text/html, Size: 4092 bytes --]
next prev parent reply other threads:[~2014-04-24 8:39 UTC|newest]
Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-23 7:55 [Bitcoin-development] Coinbase reallocation to discourage Finney attacks Mike Hearn
2014-04-23 9:57 ` Andy Parkins
2014-04-23 11:07 ` Mike Hearn
2014-04-23 11:39 ` Andy Parkins
2014-04-23 11:45 ` Mike Hearn
2014-04-23 13:21 ` Andy Parkins
2014-04-23 13:31 ` Mike Hearn
2014-04-24 9:21 ` Andy Parkins
2014-04-23 12:43 ` Christophe Biocca
2014-04-23 12:51 ` Mike Hearn
2014-04-23 14:52 ` Justus Ranvier
2014-04-23 15:07 ` Mike Hearn
2014-04-23 17:19 ` Justus Ranvier
2014-04-23 17:47 ` Gavin Andresen
2014-04-23 17:49 ` Justus Ranvier
2014-04-23 17:57 ` Mike Hearn
2014-04-23 18:04 ` Justus Ranvier
2014-04-23 18:15 ` Peter Todd
2014-04-23 18:20 ` Justus Ranvier
2014-04-23 18:37 ` Mike Hearn
2014-04-23 18:49 ` Justus Ranvier
2014-04-23 19:01 ` Drak
2014-04-23 18:58 ` Tier Nolan
2014-04-23 15:04 ` Alex Mizrahi
2014-04-23 15:09 ` Mike Hearn
2014-04-23 15:38 ` Alex Mizrahi
2014-04-23 16:04 ` Christophe Biocca
2014-04-23 16:19 ` Chris Pacia
2014-04-23 16:21 ` Mike Hearn
2014-04-23 16:33 ` Kevin
2014-04-24 11:22 ` Jorge Timón
2014-04-24 11:43 ` Mike Hearn
2014-04-24 13:57 ` Jorge Timón
2014-04-24 14:28 ` Mike Hearn
2014-04-24 15:37 ` Jorge Timón
2014-04-24 17:07 ` Justus Ranvier
2014-04-25 4:31 ` Gareth Williams
2014-04-25 10:17 ` Mike Hearn
2014-04-25 13:19 ` Gareth Williams
2014-04-25 15:28 ` Mike Hearn
2014-04-26 12:15 ` Gareth Williams
2014-04-27 1:42 ` Christophe Biocca
2014-04-27 12:53 ` Gareth Williams
2014-04-27 14:31 ` Mike Hearn
2014-04-27 23:10 ` Gareth Williams
2014-04-28 21:41 ` Adam Back
2014-04-29 14:13 ` Mike Hearn
2014-04-29 14:21 ` Gregory Maxwell
2014-04-29 14:26 ` Mike Hearn
2014-04-30 13:12 ` Gareth Williams
2014-04-30 13:55 ` Mike Hearn
2014-04-30 14:31 ` Gareth Williams
2014-04-29 19:29 ` Justus Ranvier
2014-04-30 13:00 ` Gareth Williams
2014-04-30 17:06 ` Troy Benjegerdes
2014-04-30 17:13 ` Jameson Lopp
2014-04-30 14:08 ` Gareth Williams
2014-04-23 15:28 ` Peter Todd
2014-04-23 15:34 ` Kevin
2014-04-23 15:41 ` Pieter Wuille
2014-04-23 15:55 ` Peter Todd
2014-04-23 18:57 ` Gregory Maxwell
2014-04-23 19:19 ` Mike Hearn
2014-04-23 19:47 ` Gregory Maxwell
2014-04-23 19:59 ` Mike Hearn
2014-04-23 20:24 ` Gregory Maxwell
2014-04-23 20:37 ` Mike Hearn
2014-04-23 20:44 ` Adam Ritter
2014-04-23 20:51 ` Mike Hearn
2014-04-24 15:13 ` Sergio Lerner
2014-04-24 15:34 ` Mike Hearn
2014-04-23 20:53 ` Gregory Maxwell
2014-04-23 21:23 ` Tier Nolan
2014-04-23 21:39 ` Gregory Maxwell
2014-04-23 22:26 ` Tier Nolan
2014-04-24 0:55 ` Tom Harding
[not found] ` <CAKuKjyWDniyP503XSw8=tK9XQW-T58j+VD6ajXCxz=HihN93mQ@mail.gmail.com>
2014-04-24 14:52 ` [Bitcoin-development] Fwd: " Adam Ritter
2014-04-23 20:41 ` [Bitcoin-development] " Daniel Krawisz
2014-04-23 22:06 ` Alex Mizrahi
2014-04-24 7:58 ` Mike Hearn
2014-04-24 8:19 ` Gregory Maxwell
2014-04-24 8:39 ` Mike Hearn [this message]
2014-04-24 9:25 ` Gregory Maxwell
2014-04-24 9:56 ` Mike Hearn
2014-04-24 13:44 ` Peter Todd
2014-04-24 14:09 ` Mike Hearn
2014-04-24 14:47 ` Christophe Biocca
2014-04-24 15:03 ` Peter Todd
2014-04-24 16:05 ` Christophe Biocca
2014-04-24 16:14 ` Mike Hearn
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='CANEZrP3vT6Q72X6PrcDQ8_fDeF90WmV4-M045Ac=kJY+PhuAdg@mail.gmail.com' \
--to=mike@plan99.net \
--cc=bitcoin-development@lists.sourceforge.net \
--cc=gmaxwell@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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