From: Christophe Biocca <christophe.biocca@gmail•com>
To: Peter Todd <pete@petertodd•org>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
Date: Thu, 24 Apr 2014 10:47:35 -0400 [thread overview]
Message-ID: <CANOOu=8XLdS-v-xULrv8Y5XukapCafTLDGa0M0q_W1speb2Ykg@mail.gmail.com> (raw)
In-Reply-To: <CANEZrP0Qmmrs5dzQ8N6FGL1K3W0A0XWBqtkPTFOgU_rXDvc+sQ@mail.gmail.com>
Actually Peter, coinbase confiscations are a much worse mechanism for
enforcement of widespread censorship rules than simple orphaning. They
lose their power when the transaction miners are punished for can
build up over time without losing their usefulness:
Assume a world where 75% of the hashpower is coerced into
stealing/burning the coinbases of miners who allow transactions to and
from a particular set of addresses (the actual rule isn't that
important). Then the following would be a rational behaviour from the
remaining 25%:
- Mine according to the enforced rules most of the time.
- Accept banned transactions paying you with an output (no real
miners' fees) and keep them in an ever-accumulating pool.
- When there's so much of those to make it worth your while, mine a
block filled with them.
If miners don't orphan your block, you made money. They can't
retaliate further, because you can publish the block anonymously, not
tying it to your previous identity. Hell, some of the 75% might be
able to do the same right under the authorities' noses (it would be
really hard to spot by an external observer).
Note that I, banned user, can submit to all these non-enforcing miners
at once (with a different fee txout for each). I get a severe
degradation of service, especially if I'm part of an extremely small
minority, but ultimately as long as a single miner can accumulate
enough transactions with enough fees, I'll eventually get through.
Of course, in such a dystopian future, orphaning would be the
enforcement mechanism. It would be stupid to rely on coinbase
reallocation/burning to do this task when the existing tools work so
much better.
What's interesting is that this mechanism is especially tailored to
blocking time sensitive transactions (that need to be confirmed
now/soon, or are worthless), such that their total out-of-band fees
can't build up over time. Double spending is one such category. I'm at
a loss to come up with something else, but maybe someone has a good
example?
On Thu, Apr 24, 2014 at 10:09 AM, Mike Hearn <mike@plan99•net> wrote:
>> Like I said before, that leads to the obvious next step of
>> deleting/stealing their coinbases if they don't identify themselves.
>
>
> And as I said before, that's a huge leap. A majority of miners deciding
> double spending needs tougher enforcement doesn't imply they also think all
> miners should identify themselves. Those are unrelated things.
>
> This kind of totally unsupported "obvious next step" argument can be applied
> to any proposal in any walk of life. We developed SPV clients? The obvious
> next step is that miners have to stop being anonymous. We developed floating
> fees? The obvious next step is that miners have to stop being anonymous. The
> prior arguments sound absurd exactly because they're not obvious or even
> logical - same as this.
>
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
next prev parent reply other threads:[~2014-04-24 14:47 UTC|newest]
Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-23 7:55 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
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 [this message]
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='CANOOu=8XLdS-v-xULrv8Y5XukapCafTLDGa0M0q_W1speb2Ykg@mail.gmail.com' \
--to=christophe.biocca@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=pete@petertodd$(echo .)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