public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Mike Hearn <mike@plan99.net>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
Date: Thu, 24 Apr 2014 02:25:02 -0700	[thread overview]
Message-ID: <CAAS2fgQFx7-0vZ2AR3RnLORZZCqjBFHyUBqj688Jrz8OuMYPKA@mail.gmail.com> (raw)
In-Reply-To: <CANEZrP3vT6Q72X6PrcDQ8_fDeF90WmV4-M045Ac=kJY+PhuAdg@mail.gmail.com>

On Thu, Apr 24, 2014 at 1:39 AM, Mike Hearn <mike@plan99.net> wrote:
> It absolutely is!
> https://bitcointalk.org/index.php?topic=60937.0

May I direct your attention to the third post in that thread?

Luke attempting to ret-con the enforcement flag into a vote didn't
make it one, and certantly wouldn't make it a fair, just, or sane
method of one. And so much for the effectiveness— you didn't implement
it for years even after it was deployed.

And yes, you can take any decision system and draw comparisons to
voting and call it a vote but that doesn't mean is serves the same
role or was intended for that purpose.

> 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

Yes, you can reorg out the blocks and actually remove them, but I
understood that you were _not_ proposing that quite specifically. But
instead proposed without reorging taking txouts that were previously
assigned to one party and simply assigning them to others.

> 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.

I don't think thats the root of the the disagreement at all. I think
all sorts of changes are interesting, especially ones that increase
flexibility or fix bugs but less so ones that would impose significant
changes on parties without their consent especially things that look
like taking someone's coins and assigning them to someone else.

I think the root is that you believe that the miners are, should be,
or even could be trustworthy in ways that I do not,  and as a result
you expect to be able to extract the performance of a trusted
centralized system out of them that I do not. Bitcoin is a system
where the incentives are well enough aligned that you appear to only
need a small amount of altruism to make it reliable. ... and even
summoning that altruism is a challenge— as miners hand over control of
their hash-power to centralized pools (some known to have behaved
poorly in the past), etc.

I would like that performance if it came at no cost: But proposals
that miners conspiring to blacklist transactions/blocks produced by
other people is something with a risk of a worse violation of the
system's promises than some disagreement of the ordering of
unconfirmed transactions.  Pretty much immediately after your post
Peter Todd— in his trouble making manner— went and posted on reddit
proposing the mechanism be used to claw back mining income from a
hardware vendor accused of violating its agreements on the amount of
self mining / mining on customers hardware.  While Peter's suggestion
was no doubt intentionally trouble making— I'm not clear on where the
line is here: Harm from reordering pretty much non-existent currently
and is highly speculative, while the harm to miners by hardware
vendors who've promised to not compete with their own customers or use
their equipment is not at all speculative and very salient to miners.

This especially in light of the fact that the system already has an
equitable method to decide what order transactions should be in... but
instead you propose an additional complex heuristic system where based
on some unspecified collusion some majority of miners take a
minorities coins and assign them to themselves.

Unlike reorginization this form of wealth transferal has no collateral
damage meaning that a majority cabal can use it to deprive a minority
outsider of some or all income without risking disrupting the network,
it would also lay the groundwork for additional forms of censorship
which I believe would be at odds with the purpose and architecture of
the system... and, as I noted above, it wouldn't actually prevent
theft, it would just mean that no single block could make its theft
services available to all comers (or even any of the public at all).
The simple mechenism of allowing only only a small number of paid
reordering transactions per block would prevent forming a quorum on
the decision to revoke the coinbase, and you'd even get additional
income from the probe transactions without even helping any real
double spends at all. The incentives seem very hard to analyze.



  reply	other threads:[~2014-04-24  9:25 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
2014-04-24  9:25             ` Gregory Maxwell [this message]
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=CAAS2fgQFx7-0vZ2AR3RnLORZZCqjBFHyUBqj688Jrz8OuMYPKA@mail.gmail.com \
    --to=gmaxwell@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=mike@plan99.net \
    /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