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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <alex.mizrahi@gmail.com>) id 1Wd5Je-0003X8-IA
for bitcoin-development@lists.sourceforge.net;
Wed, 23 Apr 2014 22:06:54 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.192.44 as permitted sender)
client-ip=209.85.192.44; envelope-from=alex.mizrahi@gmail.com;
helo=mail-qg0-f44.google.com;
Received: from mail-qg0-f44.google.com ([209.85.192.44])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Wd5Jd-0008Pg-Og
for bitcoin-development@lists.sourceforge.net;
Wed, 23 Apr 2014 22:06:54 +0000
Received: by mail-qg0-f44.google.com with SMTP id q108so1648733qgd.17
for <bitcoin-development@lists.sourceforge.net>;
Wed, 23 Apr 2014 15:06:48 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.224.163.73 with SMTP id z9mr25155220qax.90.1398290808238;
Wed, 23 Apr 2014 15:06:48 -0700 (PDT)
Received: by 10.96.77.38 with HTTP; Wed, 23 Apr 2014 15:06:48 -0700 (PDT)
In-Reply-To: <CANEZrP15DDdfT+o5jVKMO=tGTvHYx53yzhXfaVyzq7imfwJsZQ@mail.gmail.com>
References: <CANEZrP0szimdFSk23aMfO8p2Xtgfbm6kZ=x3rmdPDFUD73xHMg@mail.gmail.com>
<CAAS2fgTS65b0mfJakEA5s3xJHuWU2BDW8MbEVgMFMNz8YAmEiA@mail.gmail.com>
<CANEZrP15DDdfT+o5jVKMO=tGTvHYx53yzhXfaVyzq7imfwJsZQ@mail.gmail.com>
Date: Thu, 24 Apr 2014 01:06:48 +0300
Message-ID: <CAE28kUSLXG0y350gMiwnv0CoOHUorMgLup9TG77Mjj+BJcuowA@mail.gmail.com>
From: Alex Mizrahi <alex.mizrahi@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=089e0158b030eaf63504f7bcf271
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [209.85.192.44 listed in list.dnswl.org]
-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
(alex.mizrahi[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-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: 1Wd5Jd-0008Pg-Og
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 22:06:54 -0000
--089e0158b030eaf63504f7bcf271
Content-Type: text/plain; charset=UTF-8
>
> These sorts of proposals are all just ways of saying block chains kind of
> suck and we should go back to using trusted third parties.
>
No.
Different approaches have different trade-offs, and thus different areas of
applicability.
Proof-of-work's inherent disadvantage is that it takes some time until
transaction becomes practically irreversible. On the other hand, it has
advantages like neutrality, censorship-resistance, high degree of security,
etc.
TTP can be very efficient, but doesn't have advantages mentioned above.
It is possible to combine several different approaches into one hybrid
systems. For example, classic Bitcoin PoW blockchain can be used for
settlements, large transactions, savings and so on. While TTP-based payment
system will be used for small-value transaction like buying coffee.
In this case you get benefits of both approaches. Censorship-resistance is
irrelevant when one buys a cup of coffee with his pocket money, isn't it?
For some reason, instead of considering these hybrid solutions (which can
also address scalability problems), you want to make PoW-based system more
complex to be applicable for real-time transaction too.
This will, likely, weaken advantages provided by PoW, and also it won't
provide any hard guarantees, and, if implemented, will undermine
development of alternative solutions.
--089e0158b030eaf63504f7bcf271
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div=
class=3D"gmail_quote">
<div>These sorts of proposals are all just ways of saying block chains kind=
of suck and we should go back to using trusted third parties.=C2=A0</div><=
/div></div></div></blockquote><div><br></div><div>No.</div><div>Different a=
pproaches have different trade-offs, and thus different areas of applicabil=
ity.<br>
</div><div><br></div><div>Proof-of-work's inherent disadvantage is that=
it takes some time until transaction becomes practically irreversible. On =
the other hand, it has advantages like neutrality, censorship-resistance, h=
igh degree of security, etc.</div>
<div><br></div><div>TTP can be very efficient, but doesn't have advanta=
ges mentioned above.</div><div><br></div><div>It is possible to combine sev=
eral different approaches into one hybrid systems. For example, classic Bit=
coin PoW blockchain can be used for settlements, large transactions, saving=
s and so on. While TTP-based payment system will be used for small-value tr=
ansaction like buying coffee.</div>
<div><br></div><div>In this case you get benefits of both approaches. Censo=
rship-resistance is irrelevant when one buys a cup of coffee with his pocke=
t money, isn't it?</div><div><br></div><div>For some reason, instead of=
considering these hybrid solutions (which can also address scalability pro=
blems), you want to make PoW-based system more complex to be applicable for=
real-time transaction too.</div>
<div><br></div><div>This will, likely, weaken advantages provided by PoW, a=
nd also it won't provide any hard guarantees, and, if implemented, will=
undermine development of alternative solutions.</div><div><br></div></div>
</div></div>
--089e0158b030eaf63504f7bcf271--
|
