From: "Jorge Timón" <jtimon@monetize•io>
To: Mike Hearn <mike@plan99•net>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
Date: Thu, 24 Apr 2014 13:22:24 +0200 [thread overview]
Message-ID: <CAC1+kJNE+k4kcTj3Ap0-A=PdD1=+-k5hN4431Z99A+S7M3=BoQ@mail.gmail.com> (raw)
In-Reply-To: <CANEZrP3WBWi5h04yyQ115vXmVHupoj5MG+-8sx=2zEcCT5a9hg@mail.gmail.com>
On 4/23/14, Mike Hearn <mike@plan99•net> wrote:
>> 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
>>
>
> 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.
I thought the mechanism they used to prevent double-spends was proof of work.
Therefore dishonest miners where only those who mine on top of a block
which is not the longest valid chain they've seen.
To distinguish this definition from your own "honest miners are those
who decide on double-spends by mining the transaction they saw first"
definition I propose to give another new name to the later, instead of
changing the definition of the former.
So inside the group of honest miners we have some that decide on
transactions based on reception times and others that simply maximize
their revenue while respecting the protocol rules.
I suggest "stupid miners" and "smart miners" respectively as more
clear terms for what we're talking about here.
> Miners that are deliberately trying to double spend are worse than useless.
I completely disagree.
Miner's proof of work makes transactions irreversible. Even if zero
confirmation transactions weren't possible in a replace-by-fee
environment, that's very useful.
Even if you always had to wait for transactions to be confirmed with
some irreversible proof of work (as described in Satoshi's
whitepaper), it doesn't follow that "automatically resolves the
Bitcoin experiment as a failure". I don't understand how can you
conclude that.
But in fact 0 conf txs are possible *precisely* using replace-by-fee,
as described in the "
0 confirmation txs using replace-by-fee and game theory" thread. So
that conclusion is definitely wrong.
On your concrete proposal, it seems to me that you're trying to
prevent double-spending without relying on proof of work, which I
think it impossible in the context of a truly p2p system.
I don't think your current proposal is secure and I fear that at best
you will end up with an "invite only" transaction processing network
like Ripple.com has with their consensus algorithm and Unique Node
Lists: that's not really p2p.
--
Jorge Timón
http://freico.in/
next prev parent reply other threads:[~2014-04-24 11:22 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 [this message]
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='CAC1+kJNE+k4kcTj3Ap0-A=PdD1=+-k5hN4431Z99A+S7M3=BoQ@mail.gmail.com' \
--to=jtimon@monetize$(echo .)io \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=mike@plan99$(echo .)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