From: Peter Todd <pete@petertodd•org>
To: Alex Mizrahi <alex.mizrahi@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 11:28:18 -0400 [thread overview]
Message-ID: <20140423152818.GF19430@savin> (raw)
In-Reply-To: <CAE28kUQ9WOnHuFR6WYeU6rep3b74zDweTPxffF0L6FjZObXE6A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3435 bytes --]
On Wed, Apr 23, 2014 at 06:04:00PM +0300, Alex Mizrahi wrote:
> This is outright ridiculous.
>
> Zero-confirmation double-spending is a small problem, and possible
> solutions are known. (E.g. trusted third party + multi-sig addresses for
> small-value transactions.)
Also replace-by-fee scorched earth.
> On the other hand, protocol changes like described above might have
> game-theoretical implications which are non-trivial and hard to understand.
To put it mildly. :) Beyond the obvious issues with adding mechanisms
for miners to vote on what blacklists they wish to apply, it's
interesting to consider how trying to make zeroconf transactions secure
directly is quite close to changing the block interval. Like the
blocksize that's a fundemental economic parameter of the system - how
low-latency and well connected you must be to be allowed to mine. Even
in a scheme where the punishment for allowing a double-spend was somehow
applied perfectly fairly, you'd still be favoring large well-connected
miners in a very similar way to reducing the block interval.
> The above approach works as long as the majority of hashpower is honest,
> > defined to mean, working to stop double spending. This is the same security
> > property as described in the white paper, thus this introduces no new
> > security assumptions.
> >
>
> No. Bitcoin should work if miners are merely individually rational, i.e.
> they try to maximize their pay-offs without colluding with others.
It's worth noting that the academic efforts studying Bitcoin are
spending quite a bit of effort focused on the incentive compatibility of
various mechanisms in the protocol: https://github.com/citp/bitcoin-sok/issues/5
There's solid consensus in the academic community that Bitcoin can't
just depend on notions of "honesty" to work.
> I guess word "honest" might have different meanings, that can be a source
> of confusing.
> 1. Honest -- not trying to destroy bitcoin
> 2. Honest -- following rules which are not required by the protocol
What exactly those rules are is up for debate too. Right now if, say,
just 5% of Bitcoin miners were willing to accept Colored Coin
transactions you could still use Colored Coins. The other 95% may want
to block said transactions, but there's huge practical difficulties in
organizing a reorg and ensuring that everyone co-operates; miners have
strong incentives to defect if the consensus isn't assured as any miners
attempting to reorg are wasting their hashing power if it doesn't
succeed.
OTOH with a voting scheme the cost to propose that a specific block or a
transaction be blacklisted is much lower. In Mike's proposed scheme to
not just blacklist, but actually take coinbases it's downright
profitable. Rather than being a last resort option, it'll be easy for
miners to propose various things be blacklisted, if the vote goes
through, great, if it doesn't, no harm done. Obviously that makes
blacklists into a much more useful tool and greatly changes the
political landscape around them.
Remember, if you're operating a publicly known pool, and there's a
voting mechanism available to you to blacklist specific blocks, how are
you going to resist pressure from your local authorities to do just when
there's no cost to you to do so?
--
'peter'[:-1]@petertodd.org
0000000000000000278031f86c71265f6eaf1fe9ce6cc831dc4f956676a7a7f7
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]
next prev parent reply other threads:[~2014-04-23 15:28 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 [this message]
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=20140423152818.GF19430@savin \
--to=pete@petertodd$(echo .)org \
--cc=alex.mizrahi@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