summaryrefslogtreecommitdiff
path: root/19/1403274e904f8261dfd4f9f3306c901efd0d35
blob: 589388165b00e34b4d28f88ec3637e50be607756 (plain)
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
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <gacrux@gmail.com>) id 1WeYEa-0002fM-MX
	for bitcoin-development@lists.sourceforge.net;
	Sun, 27 Apr 2014 23:11:44 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.213.172 as permitted sender)
	client-ip=209.85.213.172; envelope-from=gacrux@gmail.com;
	helo=mail-ig0-f172.google.com; 
Received: from mail-ig0-f172.google.com ([209.85.213.172])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1WeYEZ-0006Zc-UB
	for bitcoin-development@lists.sourceforge.net;
	Sun, 27 Apr 2014 23:11:44 +0000
Received: by mail-ig0-f172.google.com with SMTP id hn18so4125597igb.11
	for <bitcoin-development@lists.sourceforge.net>;
	Sun, 27 Apr 2014 16:11:38 -0700 (PDT)
X-Received: by 10.50.85.37 with SMTP id e5mr20068651igz.43.1398640298636;
	Sun, 27 Apr 2014 16:11:38 -0700 (PDT)
Received: from [192.168.1.2] (60-240-212-53.tpgi.com.au. [60.240.212.53])
	by mx.google.com with ESMTPSA id n5sm5463855igr.0.2014.04.27.16.11.26
	for <bitcoin-development@lists.sourceforge.net>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Sun, 27 Apr 2014 16:11:37 -0700 (PDT)
User-Agent: K-9 Mail for Android
In-Reply-To: <CANEZrP2jTP+uCuXswopheJwBBmMp5ZHdqxua1sAhLF=cOnhPOg@mail.gmail.com>
References: <CANEZrP0szimdFSk23aMfO8p2Xtgfbm6kZ=x3rmdPDFUD73xHMg@mail.gmail.com>
	<CAE28kUQ9WOnHuFR6WYeU6rep3b74zDweTPxffF0L6FjZObXE6A@mail.gmail.com>
	<CANEZrP3WBWi5h04yyQ115vXmVHupoj5MG+-8sx=2zEcCT5a9hg@mail.gmail.com>
	<CAC1+kJNE+k4kcTj3Ap0-A=PdD1=+-k5hN4431Z99A+S7M3=BoQ@mail.gmail.com>
	<CANEZrP3obO9rXKcX+G7bs2dd3AqEFOsO8pCUF6orrkGeZyr9Ew@mail.gmail.com>
	<CAC1+kJPxwTm6qvh2GYT2XMJAPD5O4WHLOGBTRmchRmZ2wS4MSg@mail.gmail.com>
	<CANEZrP2PZFVvH3oJyLW80e9W_Fa4bvqQ25E7T-ZFFuG9u-q1hQ@mail.gmail.com>
	<5359E509.4080907@gmail.com>
	<CANEZrP0bKe-=T5ps0myLZjo60tv2mkm3Bw0o4e-9y7zb1h5eDg@mail.gmail.com>
	<535A60FE.10209@gmail.com>
	<CANEZrP0y45eSVgbzXYmvYy1WEQNyd=tmC2EpZgGSB28poXSzDw@mail.gmail.com>
	<535BA357.6050607@gmail.com>
	<CANOOu=_T82zuV79DWZFGK0Nomhp-Y4tqOhw6ZHhCLb2uGtdR5w@mail.gmail.com>
	<535CFDB4.1000200@gmail.com>
	<CANEZrP2jTP+uCuXswopheJwBBmMp5ZHdqxua1sAhLF=cOnhPOg@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
 charset=UTF-8
From: Gareth Williams <gacrux@gmail.com>
Date: Mon, 28 Apr 2014 09:10:43 +1000
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Message-ID: <e645bbe6-4ba4-4ecd-9a14-25386e8adbac@email.android.com>
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(gacrux[at]gmail.com)
	-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: 1WeYEZ-0006Zc-UB
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: Sun, 27 Apr 2014 23:11:44 -0000

Agreed. I'm a pragmatist, certainly not anti-change (or even anti-zero-conf.) Useful and non-controversial hard forks don't keep me awake at night :) I support your general position on zero-conf payments (that they're useful and we should make them as reliable as practical.)

But the very essence of Bitcoin, to me, is trustlessness. Satoshi's great invention isn't just another payment network - it's /ecash/. Bearer-negotiable, whoever-controls-the-private-keys-owns-it, **ecash**.

If not that, what do you think it is? :-)

I like trustless systems for purely pragmatic, cost-benefit reasons. They allow us to avoid all the costs associated with imperfect humans, while reaping the benefits of reliability and predictability :P


On 28 April 2014 12:31:05 AM AEST, Mike Hearn <mike@plan99.net> wrote:
>>
>> That moves us away from a pure trustless system built upon a small
>> democratic foundation (as something of a necessary evil in an
>imperfect
>> world where humans run our computers and use our system) and toward a
>> "democratic system".
>>
>> You don't have to agree, but I hope you can understand the point I'm
>> making :-)
>
>
>Yep, your point is well made.
>
>I don't have much more to say about this proposal specifically, but I
>think
>this whole question of what changes are OK and what would be a
>violation of
>the social contract will get discussed endlessly over the coming years.
>Put
>another way, what do Bitcoin's users expect and want - a system that
>evolves or a system that remains exactly as they found it? There will
>be
>good arguments on both sides, and the answer will probably be different
>on
>a case by case basis. But personally I'm skeptical of any argument that
>argues against change for its own sake. It has to be an argument rooted
>in
>a careful analysis of costs and benefits.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.