From: Chris Pacia <ctpacia@gmail•com>
To: Christophe Biocca <christophe.biocca@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
Date: Wed, 23 Apr 2014 12:19:52 -0400 [thread overview]
Message-ID: <CAB+qUq4-CZ6C9hBsc9vuH=Qz61_jEQNXm=djQfLKiv1SXMBNng@mail.gmail.com> (raw)
In-Reply-To: <CANOOu=85-6p-v8ZWPC=zGAY9TdjgR1WK_fOOJYnyFJMj+dvHUQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4566 bytes --]
What is the advantage of this proposal over just orphaning the block with
double spends?
There's currently a set of rules which government what constitutes a valid
block. Miners don't build on blocks that don't accord with those rules out
of fear that a major won't follow and they will waste hashing power.
If there was a rule supported by the majority that considered blocks with
double spends (defined in some fashion) as invalid miners wouldn't build on
them for the same reason they wouldn't build on a block with a coinbase
over 25 btc, say. It seems that would accomplish the same without the other
issues.
On Apr 23, 2014 12:04 PM, "Christophe Biocca" <christophe.biocca@gmail•com>
wrote:
> 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
> >
>
>
> ------------------------------------------------------------------------------
> 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
>
[-- Attachment #2: Type: text/html, Size: 5783 bytes --]
next prev parent reply other threads:[~2014-04-23 16:19 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 [this message]
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='CAB+qUq4-CZ6C9hBsc9vuH=Qz61_jEQNXm=djQfLKiv1SXMBNng@mail.gmail.com' \
--to=ctpacia@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=christophe.biocca@gmail$(echo .)com \
/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