1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jtimon@monetize.io>) id 1WdHjd-0006BI-IO
for bitcoin-development@lists.sourceforge.net;
Thu, 24 Apr 2014 11:22:33 +0000
Received: from mail-la0-f43.google.com ([209.85.215.43])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WdHjb-00025H-80
for bitcoin-development@lists.sourceforge.net;
Thu, 24 Apr 2014 11:22:33 +0000
Received: by mail-la0-f43.google.com with SMTP id c6so1890877lan.16
for <bitcoin-development@lists.sourceforge.net>;
Thu, 24 Apr 2014 04:22:24 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type
:content-transfer-encoding;
bh=ItUysMc5MydtJjwAYtiq7BrEydpvrf86WihYTDnV2Is=;
b=eHozHLEvUrW7um9Clax2vW3bSpoeI4WV7lWdW11HmGa6fse3w74yuv90njZnn40u2K
hgITRxv8b3oPCDvoSH3rVxbfm1C9E7/UqAQpGfm6gcr7KSuBezhBU/YVCXYVEOCduo8H
aKEKVpt+F5AstYwF5KdCNkFS6JvAGzb1jLk8uh8QunNOuqr10VjoSf2dOC2IlkbcSGGG
Xe1JJpBWTp+XiQh0yR773aLrT8qzjRxvQNPmIsaqjUd5Sp36hMRFwDUtBL/8s7a2GeD4
qcVGjKWPFgFiG4RSU5ini/XWrgWc0FWCBl/4ptvY7t/AeOaM0swXQIM1Kz4ps2qg9h7e
zLpQ==
X-Gm-Message-State: ALoCoQlLhVKhMxbenPmkIBviBnowIIYIc0+XpPsautHGft+/FhRGe90Ns05xwcjsD8CRH9WahRkd
MIME-Version: 1.0
X-Received: by 10.152.44.234 with SMTP id h10mr41750lam.68.1398338544517; Thu,
24 Apr 2014 04:22:24 -0700 (PDT)
Received: by 10.112.185.4 with HTTP; Thu, 24 Apr 2014 04:22:24 -0700 (PDT)
X-Originating-IP: [85.59.56.59]
In-Reply-To: <CANEZrP3WBWi5h04yyQ115vXmVHupoj5MG+-8sx=2zEcCT5a9hg@mail.gmail.com>
References: <CANEZrP0szimdFSk23aMfO8p2Xtgfbm6kZ=x3rmdPDFUD73xHMg@mail.gmail.com>
<CAE28kUQ9WOnHuFR6WYeU6rep3b74zDweTPxffF0L6FjZObXE6A@mail.gmail.com>
<CANEZrP3WBWi5h04yyQ115vXmVHupoj5MG+-8sx=2zEcCT5a9hg@mail.gmail.com>
Date: Thu, 24 Apr 2014 13:22:24 +0200
Message-ID: <CAC1+kJNE+k4kcTj3Ap0-A=PdD1=+-k5hN4431Z99A+S7M3=BoQ@mail.gmail.com>
From: =?ISO-8859-1?Q?Jorge_Tim=F3n?= <jtimon@monetize.io>
To: Mike Hearn <mike@plan99.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1WdHjb-00025H-80
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Coinbase reallocation to discourage
Finney attacks
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 24 Apr 2014 11:22:33 -0000
On 4/23/14, Mike Hearn <mike@plan99.net> wrote:
>> I guess word "honest" might have different meanings, that can be a sourc=
e
>> 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 existenc=
e.
I thought the mechanism they used to prevent double-spends was proof of wor=
k.
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 useles=
s.
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.
--=20
Jorge Tim=F3n
http://freico.in/
|
