From: Christophe Biocca <christophe.biocca@gmail•com>
To: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
Date: Wed, 23 Apr 2014 12:04:13 -0400 [thread overview]
Message-ID: <CANOOu=85-6p-v8ZWPC=zGAY9TdjgR1WK_fOOJYnyFJMj+dvHUQ@mail.gmail.com> (raw)
In-Reply-To: <CAE28kUQqFJUJSiSV4PSF2QK04D3GuL1n2EF46Yo3o_-LYsgSTA@mail.gmail.com>
It's not necessary that this "coinbase retribution" be either
profitable or risk-free for this scheme to work. I think we should
separate out the different layers of the proposal:
1. Attacking the coinbase instead of orphaning allows for 100 blocks'
time for a consensus to be reached, rather than 10 minutes. This
allows for human verification/intervention if needed (orphaning
decisions would almost always need to be automated, due to the short
timeframe). This is a useful insight, and I don't think it's been
brought up before.
2. The original specification of how it's done (redistribution, no
cost to voting) does seem exploitable. This can be fixed by reducing
the incentive (burning instead of redistributing) and/or adding a risk
to the orphaning attempts (a vote that fails destroys X bitcoins'
worth from each voting block's own coinbase). The incentives can be
tailored to mirror those of orphaning a block, to reduce the risk of
abuse. Then the only difference from orphaning are 1) More limited
rewriting of history (only the coinbase, vs all transactions in the
block), and 2) More time to coordinate a response.
3. This proposal may be used for things other than punishing
double-spend pools. In fact it might be used to punish miners for
doing anything a significant percentage of hashpower dislikes (large
OP_RETURNs, large blocks, gambling transactions, transactions banned
by a government). But we can make the threshold higher than 51%, so
that this doesn't turn into a significant risk (if 75% of hashpower is
willing to enforce a rule, we're already likely to see it enforced
through orphaning).
On Wed, Apr 23, 2014 at 11:38 AM, Alex Mizrahi <alex.mizrahi@gmail•com> wrote:
>
>>
>> And it still would. Non-collusive miners cast votes based on the outcome
>> of their own attempts to double spend.
>
>
> Individually rational strategy is to vote for coinbase reallocation on every
> block.
>
> Yes, in that case nobody will get reward. It is similar to prisoner's
> dilemma: equilibrium has worst pay-off.
> In practice that would mean that simple game-theoretic models are no longer
> applicable, as they lead to absurd results.
>
>>
>> I'm using it in the same sense Satoshi used it. Honest miners work to
>> prevent double spends. That's the entire justification for their existence.
>> Miners that are deliberately trying to double spend are worse than useless.
>
>
> Miners work to get rewards.
> It absolutely doesn't matter whether they are deliberately trying to
> double-spend or not: they won't be able to double-spend without a collusion.
>
> ------------------------------------------------------------------------------
> 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-23 16:04 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 [this message]
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
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=85-6p-v8ZWPC=zGAY9TdjgR1WK_fOOJYnyFJMj+dvHUQ@mail.gmail.com' \
--to=christophe.biocca@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/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