From: Mike Hearn <mike@plan99•net>
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: Thu, 24 Apr 2014 09:58:42 +0200 [thread overview]
Message-ID: <CANEZrP0j0KoLUB+SE+W3fL8vTKay0niqoeQ38RKnU9cyGgvvYw@mail.gmail.com> (raw)
In-Reply-To: <CAE28kUSLXG0y350gMiwnv0CoOHUorMgLup9TG77Mjj+BJcuowA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3330 bytes --]
On Thu, Apr 24, 2014 at 12:06 AM, Alex Mizrahi <alex.mizrahi@gmail•com>wrote:
>
> Different approaches have different trade-offs, and thus different areas
> of applicability.
>
> Proof-of-work's inherent disadvantage is that it takes some time until
> transaction becomes practically irreversible. On the other hand, it has
> advantages like neutrality, censorship-resistance, high degree of security,
> etc.
>
Sure, they have different tradeoffs. My assertion is this: the costs and
disadvantages that come with building what is in effect an entirely
parallel and separate system for stopping double spends, are much much
worse than making simple tweaks to strengthen the mechanism we already have.
Put another way, the cost/benefit ratio of this proposal seems much better
to me than the alternatives.
> In this case you get benefits of both approaches.
>
You also get the costs of both approaches, which are extremely significant.
Censorship-resistance is irrelevant when one buys a cup of coffee with his
> pocket money, isn't it?
That's like saying banks can't censor you because you can always withdraw
all your money in cash. But in practice:
1. That's a huge pain in the ass so nobody does it
2. Many merchants will refuse non-trivial payments in cash and demand
bank money because it's simpler for them
Analogously, having to wait some large expiry period to extract your money
from the "double spending prevention service" (a.k.a. bitbank) is a pain in
the ass, and many merchants would refuse to take your newly double
spendable money even if theoretically they could, because it keeps their
operations much simpler if they can just assume a sale is final and can't
be reversed.
So I think such a scheme would rapidly return to the a world that looks
much like the one we have now.
> For some reason, instead of considering these hybrid solutions (which can
> also address scalability problems), you want to make PoW-based system more
> complex to be applicable for real-time transaction too.
>
The complexity overhead is trivial - we already used coinbase scriptSigs
for voting on P2SH, I'm sure it'll be used for voting on other things in
future too. So that's already in place. Counting up votes and editing the
UTXO set is the sort of patch one guy can create, it's not very big. And
it's conceptually just the same as what miners can do today by re-orging
out blocks, but with much less impact on end users and less implementation
complexity (no giant reorgs that might themselves have to split recursively
whilst they're being built).
On the other hand, building an entirely separate system, with separate
trusted companies that have trusted brand names, adding support to all the
wallets, getting all sellers on board, making everything use an extended
BIP 70 (as that's the only real way to implement it), trying to explain to
users why they're now expected to pay extra fees when they previously
didn't and then discovering that you got a choice of only a handful of
double-spend-preventers everyone could agree on with little potential for
more .... that's hugely complex and messy.
> This will, likely, weaken advantages provided by PoW
>
Why? Remember deleting coinbases with nothing more than a simple majority
is already possible in the existing protocol and always has been.
[-- Attachment #2: Type: text/html, Size: 5163 bytes --]
next prev parent reply other threads:[~2014-04-24 7:58 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 [this message]
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=CANEZrP0j0KoLUB+SE+W3fL8vTKay0niqoeQ38RKnU9cyGgvvYw@mail.gmail.com \
--to=mike@plan99$(echo .)net \
--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