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
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jgarzik@bitpay.com>) id 1YLvgj-0004Fq-Ai
for bitcoin-development@lists.sourceforge.net;
Thu, 12 Feb 2015 15:28:21 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of bitpay.com
designates 209.85.214.174 as permitted sender)
client-ip=209.85.214.174; envelope-from=jgarzik@bitpay.com;
helo=mail-ob0-f174.google.com;
Received: from mail-ob0-f174.google.com ([209.85.214.174])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YLvgh-00079y-6i
for bitcoin-development@lists.sourceforge.net;
Thu, 12 Feb 2015 15:28:21 +0000
Received: by mail-ob0-f174.google.com with SMTP id wo20so10436351obc.5
for <bitcoin-development@lists.sourceforge.net>;
Thu, 12 Feb 2015 07:28:13 -0800 (PST)
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:from:date
:message-id:subject:to:cc:content-type;
bh=CRV7q91j/+UwzYJOXCmRm/udmTJcZnkjK7Pg6f89k04=;
b=BNrfQKOPSPT4vPO7vF7voCiUfCC33ejgodIwFD6DWszneqtJpyO0l5t3A1E6+UlWEf
FTTFWyrC5MrTxv2f8dqkgh7qEzvFlU5EwHcugSsrmVJYovUfGNdOBEPSI2Gkbr5503gs
BRNiXOTnOBYlt/ht+sCqIkte1DpB1VyjRTaTHr0fcFdUiHoVU2X1pXrCmsb5XBY3nZaO
JEPn7h51bGV0LoIisLsF/CRAXzodLOluIPhrjOLCR8zFoaH+uJyWjJoXAgveebNWiwCM
W6wgAMyeXuFc4YmNixMOvHxtrbxL+1AwJdQ84raVr3zrh3hMnIa3c+K/nMug5u5ON7FG
NXXw==
X-Gm-Message-State: ALoCoQkI3QUYTmbPni8nrnJKdbINONPYZvKfHD1mXZHdpaoAxpgPQPp5trdSqnfWFTRSV+y8lV98
X-Received: by 10.202.225.130 with SMTP id y124mr2967257oig.58.1423754893610;
Thu, 12 Feb 2015 07:28:13 -0800 (PST)
MIME-Version: 1.0
Received: by 10.202.219.10 with HTTP; Thu, 12 Feb 2015 07:27:53 -0800 (PST)
In-Reply-To: <CANEZrP2uVT_UqJbzyQcEbiS78T68Jj2cH7OGXv5QtYiCwArDdA@mail.gmail.com>
References: <20150212064719.GA6563@savin.petertodd.org>
<CANEZrP2uVT_UqJbzyQcEbiS78T68Jj2cH7OGXv5QtYiCwArDdA@mail.gmail.com>
From: Jeff Garzik <jgarzik@bitpay.com>
Date: Thu, 12 Feb 2015 10:27:53 -0500
Message-ID: <CAJHLa0PkzG44JpuQoHVLUU8SR55LaJf5AwG=a7AjK2u7TAveOQ@mail.gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.6 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1YLvgh-00079y-6i
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
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, 12 Feb 2015 15:28:21 -0000
Repeating past statements, it is acknowledged that Peter's scorched
earth replace-by-fee proposal is aptly named, and would be widely
anti-social on the current network.
At a high level, we can see that this thread is contentious because
this covers _what we want bitcoin to be_, and that is an opinion
(versus engineering fact), and it varies from person to person.
However, hope is the denial of reality...instead we should walk
forward with our eyes open[1]. My interest in bitcoin originates from
the science fiction concept of "credits"[2], a universal money that
transcends national borders and even planets. That is what I hoped
bitcoin would be. "universal payments" is both a laudable goal and a
shopworn bitcoin marketing slogan.
The fundamental engineering truths diverge from that misty goal:
Bitcoin is a settlement system, by design.
The process of consensus "settles" upon a timeline of transactions,
and this process -- by design -- is necessarily far from instant.
Alt-coins that madly attempt 10-second block times etc. are simply a
vain attempt to paper over this fundamental design attribute:
consensus takes time.
As such, the blockchain can never support All The Transactions, even
if block size increases beyond 20MB. Further layers are -- by design
-- necessary if we want to achieve the goal of a decentralized payment
network capable of supporting full global traffic.
Bitcoin payments are like IP packets -- one way, irreversible. For
larger value transfers this attaches attendent risk of loss -- as
we've seen in the field time & again. The world's citizens en masse
will not speak to each other with bitcoin (IP packets), but rather
with multiple layers (HTTP/TCP/IP) that enable safe and secure value
transfer or added features such as instant transactions.
This opinion is not a conspiracy to "put the bankers back in charge"
-- it is a simple acknowledgement of bitcoin's design. The consensus
system settles on a timeline.
Bitcoin transactions are, by definition, not instant.
Zero confirmation transactions are, by definition, not secure.
Proposals such as Oleg's are _necessary_ to fully build out the
bitcoin system. Avoid short-sighted, short-term thinking that views
the lowest layer (one-way value xfer) at the most optimal layer at
which free persons will transact freely & instantly across planet
Earth.
It is foolish to think the entire world will connect directly to the
P2P block network and broadcast all the morning coffees to all the
miners. That's not how the system works. It is a settlement layer.
We _must_ build decentralized layered solutions on top of bitcoin,
rather than stuffing everything into bitcoin itself.
[1] http://www.goodreads.com/quotes/35199-hope-is-the-denial-of-reality-it-is-the-carrot
[2] http://garzikrants.blogspot.com/2013/06/shadowrun-and-bitcoins-roots.html
On Thu, Feb 12, 2015 at 6:58 AM, Mike Hearn <mike@plan99.net> wrote:
> I know you will ignore this as usual, but the entire replace-by-fee folly is
> based on your fundamental misunderstanding of miner incentives.
>
> Miners are not incentivised to earn the most money in the next block
> possible. They are incentivised to maximise their return on investment.
> Making Bitcoin much less useful reduces demand for the bitcoins they are
> mining, reducing coinbase and fee income in future blocks. Quite possibly,
> to the point where those miners are then making a loss.
>
> Your "scorched earth" plan is aptly named, as it's guaranteed to make
> unconfirmed payments useless. If enough miners do it they will simply break
> Bitcoin to the point where it's no longer an interesting payments system for
> lots of people. Then miners who have equipment to pay off will be really
> screwed, not to mention payment processors and all the investors in them.
>
> I'm sure you can confuse a few miners into thinking your ideas are a
> super-duper way to maximise their income, and in the process might
> facilitate a pile of payment fraud. But they aren't. This one is about as
> sensible as your "let's never increase the block size" and "let's kill SPV
> clients" crusades - badly thought out and bad for Bitcoin.
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
|
