summaryrefslogtreecommitdiff
path: root/17/16f437182805cfba754ac972b865fe2117bd9a
blob: b4802c2fe2c4a05a9159e40c220819d790a7978c (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
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
Return-Path: <washington.sanchez@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 22EB1113F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  8 Sep 2015 15:10:58 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f177.google.com (mail-ig0-f177.google.com
	[209.85.213.177])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A0FDD1F8
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  8 Sep 2015 15:10:57 +0000 (UTC)
Received: by igcrk20 with SMTP id rk20so76619527igc.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 08 Sep 2015 08:10:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=wEM7T3/JQ7Pd9iBNmbOKTdgU0gYH6al0VEkMP3bPKbA=;
	b=QbeKRNvG424xjnMXGiyoyQB/EgK6PFVt89G2EoQeuekeWGquxmcF4SCfB2FujIhvZH
	WmBYMxCFA/nJ2dRt0Q81IUbyAC2Trp3HPMXBh6IkAx+r4yXyEznozc5FQOMN6kkdQn7o
	IOeMOtoyZdjReXKZwuKscps/kuZvA8MFC0fGXaK57FYBK7JkvwsF1T7dt0deE+zLrh2S
	7pnd4Rt5LxrFYEUFD29sMUpeyO6EqDkh7GIEhMNXHuzTQRhToPSExrL4JsKN/8NpJddL
	6cJoXCZ8UKn24ZiO+y8LQyGf0aE6pYSn7mj72deQGngSlclujfzUDbwFzr6edshgpuy9
	YqUw==
MIME-Version: 1.0
X-Received: by 10.50.39.80 with SMTP id n16mr22323117igk.44.1441725054983;
	Tue, 08 Sep 2015 08:10:54 -0700 (PDT)
Received: by 10.107.178.12 with HTTP; Tue, 8 Sep 2015 08:10:54 -0700 (PDT)
In-Reply-To: <CALqxMTFQhFusR5jkEMvRdxDVLZPzWSW5hUHpXoON-K-+xJjpNA@mail.gmail.com>
References: <CAG0bcYzzg4yeQvd27PZu5Fqv1ULS3cKeQHaRZ2zPcM3OASw1cg@mail.gmail.com>
	<CADJgMztJx1cBFhNOwMgBHJGPmBNPqsTdQbCCjFBmDBSBfTMMUg@mail.gmail.com>
	<CAAre=yRawFU_WMdE+ReemscYD33ez1PF6VhU2FmWo2fAEcw_Xw@mail.gmail.com>
	<CALqxMTERUFEFgJ4quz2dWLRw9fD3DkBp-6RO4cuvdBGV2MSyhw@mail.gmail.com>
	<CAG0bcYzBCsg9xNLGmu4S=PEPjtbd2iBLH52ryswbkRM23OqquA@mail.gmail.com>
	<CALqxMTFQhFusR5jkEMvRdxDVLZPzWSW5hUHpXoON-K-+xJjpNA@mail.gmail.com>
Date: Wed, 9 Sep 2015 01:10:54 +1000
Message-ID: <CAG0bcYw=k_z82buUQ_kApmPgSenNy6FEsdXotLaS4Gn-kZbrKg@mail.gmail.com>
From: Washington Sanchez <washington.sanchez@gmail.com>
To: Adam Back <adam@cypherspace.org>
Content-Type: multipart/alternative; boundary=e89a8f83a259c42c01051f3dc53a
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Dynamic limit to the block size - BIP draft
	discussion
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Sep 2015 15:10:58 -0000

--e89a8f83a259c42c01051f3dc53a
Content-Type: text/plain; charset=UTF-8

1) It's not really clear to me how that would work, but assuming it does
then it will go into a basket of attacks that are possible but unlikely due
to the economic disincentives to do so.

2) That said, is the Achilles heal of this proposal the lack of a mechanism
to lower the block size?

3) Let me put it another way, I've read that both Gavin and yourself are
favorable to a dynamic limit on the block size. In your view, what is
missing from this proposal, or what variables should be adjusted, to get
the rules to a place where you and other Core developers would seriously
consider it?

On Wed, Sep 9, 2015 at 12:18 AM, Adam Back <adam@cypherspace.org> wrote:

> > A selfish mining attack would have to be performed for at least 2000
> blocks over a period of 4 weeks in order to achieve a meager 10% increase
> in the block size.
>
> You seem to be analysing a different attack - I mean that if someone
> has enough hashrate to do a selfish mining attack, then setting up a
> system that has no means to reduce block-size risks that at a point
> where there is excess block-size they can use that free transaction
> space to amplify selfish mining instead of collecting transaction
> fees.
>
> Adam
>



-- 
-------------------------------------------
*Dr Washington Y. Sanchez <http://onename.com/drwasho>*
Co-founder, OB1 <http://ob1.io>
Core developer of OpenBazaar <https://openbazaar.org>
@drwasho <https://twitter.com/drwasho>

--e89a8f83a259c42c01051f3dc53a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><br></div>1) It&#39;s not really clear to me how that=
 would work, but assuming it does then it will go into a basket of attacks =
that are possible but unlikely due to the economic disincentives to do so.<=
div><br></div><div>2) That said, is the Achilles heal of this proposal the =
lack of a mechanism to lower the block size?=C2=A0</div><div><br></div><div=
>3) Let me put it another way, I&#39;ve read that both Gavin and yourself a=
re favorable to a dynamic limit on the block size. In your view, what is mi=
ssing from this proposal, or what variables should be adjusted, to get the =
rules to a place where you and other Core developers would seriously consid=
er it?</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"=
>On Wed, Sep 9, 2015 at 12:18 AM, Adam Back <span dir=3D"ltr">&lt;<a href=
=3D"mailto:adam@cypherspace.org" target=3D"_blank">adam@cypherspace.org</a>=
&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">&gt; =
A selfish mining attack would have to be performed for at least 2000 blocks=
 over a period of 4 weeks in order to achieve a meager 10% increase in the =
block size.<br>
<br>
</span>You seem to be analysing a different attack - I mean that if someone=
<br>
has enough hashrate to do a selfish mining attack, then setting up a<br>
system that has no means to reduce block-size risks that at a point<br>
where there is excess block-size they can use that free transaction<br>
space to amplify selfish mining instead of collecting transaction<br>
fees.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Adam<br>
</font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- <b=
r><div class=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><di=
v><div>-------------------------------------------</div><div><b><a href=3D"=
http://onename.com/drwasho" target=3D"_blank">Dr Washington Y. Sanchez</a><=
/b></div><div>Co-founder, <a href=3D"http://ob1.io" target=3D"_blank">OB1</=
a></div><div>Core developer of <a href=3D"https://openbazaar.org" target=3D=
"_blank">OpenBazaar</a></div><div><a href=3D"https://twitter.com/drwasho" t=
arget=3D"_blank">@drwasho</a></div></div><div><br></div></div></div></div><=
/div>
</div>

--e89a8f83a259c42c01051f3dc53a--