summaryrefslogtreecommitdiff
path: root/10/e05a9ced66cd7dcf497907f3fa2bae656f3bc2
blob: 665658b9dcb8341f2d42a9e69e83c8d01f1a9a52 (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
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <gmaxwell@gmail.com>) id 1Wd4BD-0004WG-4A
	for bitcoin-development@lists.sourceforge.net;
	Wed, 23 Apr 2014 20:54:07 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.217.180 as permitted sender)
	client-ip=209.85.217.180; envelope-from=gmaxwell@gmail.com;
	helo=mail-lb0-f180.google.com; 
Received: from mail-lb0-f180.google.com ([209.85.217.180])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Wd4BC-0003c3-9p
	for bitcoin-development@lists.sourceforge.net;
	Wed, 23 Apr 2014 20:54:07 +0000
Received: by mail-lb0-f180.google.com with SMTP id 10so1245909lbg.39
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 23 Apr 2014 13:53:59 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.152.23.200 with SMTP id o8mr69369laf.80.1398286439521; Wed,
	23 Apr 2014 13:53:59 -0700 (PDT)
Received: by 10.112.89.68 with HTTP; Wed, 23 Apr 2014 13:53:59 -0700 (PDT)
In-Reply-To: <CAKuKjyV+FQs1goNK1uWXVg7ky4aGiROcTZ5idM3Ug2-+5bTc2w@mail.gmail.com>
References: <CANEZrP0szimdFSk23aMfO8p2Xtgfbm6kZ=x3rmdPDFUD73xHMg@mail.gmail.com>
	<CAAS2fgTS65b0mfJakEA5s3xJHuWU2BDW8MbEVgMFMNz8YAmEiA@mail.gmail.com>
	<CANEZrP15DDdfT+o5jVKMO=tGTvHYx53yzhXfaVyzq7imfwJsZQ@mail.gmail.com>
	<CAAS2fgTJpFQKeVTQsAeqe0UK-2XhrLZG4oocEHM11_spWLtrEA@mail.gmail.com>
	<CANEZrP0fUhiFeH4A1Y9sLCORpggJs3dxHz+exgpKaLQe9rgFeA@mail.gmail.com>
	<CAAS2fgR1dRFVqhTNn55dZ6FS5zDM0aHs4ROPSD37hWwzLUKfCg@mail.gmail.com>
	<CANEZrP2t09bzmDkkWK3V2GpqEt54KhFnUQ8_u9ULMqniMaOA8Q@mail.gmail.com>
	<CAKuKjyV+FQs1goNK1uWXVg7ky4aGiROcTZ5idM3Ug2-+5bTc2w@mail.gmail.com>
Date: Wed, 23 Apr 2014 13:53:59 -0700
Message-ID: <CAAS2fgRWfcxYaLRY69=LE_+sDfYLNUTcimw4cE-2Byw7QonC=w@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Adam Ritter <aritter@gmail.com>
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(gmaxwell[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: 1Wd4BC-0003c3-9p
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: Wed, 23 Apr 2014 20:54:07 -0000

On Wed, Apr 23, 2014 at 1:44 PM, Adam Ritter <aritter@gmail.com> wrote:
> Isn't a faster blockchain for transactions (maybe as a sidechain) solving
> the problem? If there would be a safe way for 0-confirmation transactions,
> the Bitcoin blockchain wouldn't even be needed.

Large scale consensus can't generally provide instantly irreversible
transactions directly: Increasing the block speed can't help past the
point where the time starts getting close to the network diameter...
you simply can't tell what a consensus of a group of nodes is until
several times the light cone that includes all of them.  And if you
start getting close to the limit you dilute the power working on the
consensus and potentially make life easier for a large attacker.

Maybe other chains with different parameters could achieve a different
tradeoff which was better suited to low value retail transactions
(e.g. where you want a soft confirmation fast). A choice of tradeoffs
could be very useful, and maybe you can practically get close enough
(e.g. would knowing you lost a zero-conf double spend within 30
seconds 90% of the time be good enough?)... but I'm not aware of any
silver bullet there which gives you something identical to what a
centralized service can give you without invoking at least a little
bit of centralization.