summaryrefslogtreecommitdiff
path: root/8b/5c01cc691fd31867cc6705ab7bebd400b3dd9e
blob: b7e89359ba12f8f5ce46e102b9171caa7bdf1215 (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
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
Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id E5797110F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 11 Sep 2015 18:37:36 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com
	[209.85.212.176])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 272B019F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 11 Sep 2015 18:37:36 +0000 (UTC)
Received: by wicfx3 with SMTP id fx3so67806210wic.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 11 Sep 2015 11:37:34 -0700 (PDT)
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:date
	:message-id:subject:from:to:cc:content-type;
	bh=eB7pji2mb/0IjYmLV8cwcYLyjOScqrXKG1prjLBoLH0=;
	b=KlmFqhyHW6Y80KcDbtlLKKyyS4SdaDM/YDUKWl6xD2ZviIwz/p8oiS/LVQpLLnqHjR
	cLveZk+6NUiWCIh2bILcSNMOiYS44w5o6rzEgIOiyiYm3jNg4xtw8XGEV+Rh5A9oV66a
	JyyFiYRFTH/oz4J6tPg+OI9gsWpyjLvZfSuzyW4pKb6dZJY0BSc7Q7hduRZStzlHslnf
	8C7t4IB6O9FOIc8eeo7GfeEGSksaxkMQOgKcGQjm8uYaVmZIC4rCn6h6T5/1Uyy+slfQ
	Xc23Mqu3T/Q5wuV5SNduI+LGJYuoscHNkt0fR8kR+BwUe201Tbgz9G9iSR4Rl6SvZgs1
	hexw==
X-Gm-Message-State: ALoCoQl5QH5e4Npzt5XBjG7XmjEkxcLW2mTXXw6NQkrIomMM1yqxF4wsLaQhO+lSKaYQazq7BFhK
MIME-Version: 1.0
X-Received: by 10.180.103.72 with SMTP id fu8mr8989630wib.7.1441996654475;
	Fri, 11 Sep 2015 11:37:34 -0700 (PDT)
Received: by 10.194.37.5 with HTTP; Fri, 11 Sep 2015 11:37:34 -0700 (PDT)
Received: by 10.194.37.5 with HTTP; Fri, 11 Sep 2015 11:37:34 -0700 (PDT)
In-Reply-To: <CANOOu=8jT++mX_pTHrEnryJqiw3C+J3mWKL27dEkQh=rO0q_Cg@mail.gmail.com>
References: <CAGLBAhd11-_LNJ-ba6NXmWBXz=yb+pFTmf9tHAgFW_m6S5jnfw@mail.gmail.com>
	<CABm2gDpsJdSDTyvTGNSZXX1+UyAHxTB=ODuy6bJvMj3A9BqhqQ@mail.gmail.com>
	<CANOOu=8jT++mX_pTHrEnryJqiw3C+J3mWKL27dEkQh=rO0q_Cg@mail.gmail.com>
Date: Fri, 11 Sep 2015 20:37:34 +0200
Message-ID: <CABm2gDoCecK1jk6i_bZMTRCTQUseXYugi5ntykMimzns_dxFug@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Christophe Biocca <christophe.biocca@gmail.com>
Content-Type: multipart/alternative; boundary=f46d0444e9e95b90eb051f7d026f
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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] Bitcoin Days Destroyed as block selection
	heuristic
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: Fri, 11 Sep 2015 18:37:37 -0000

--f46d0444e9e95b90eb051f7d026f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sep 11, 2015 1:18 PM, "Christophe Biocca" <christophe.biocca@gmail.com>
wrote:
>
> It's pretty obvious that Dave is suggesting an alternate tie-breaker:

I thought he was proposing a new consesnsus rule. I see, this would be just
a policy validation that everybody would be free to ignore (like the "first
seen" spend conflict tx replacement policy).

I don't see how miners would benefit from running this policy so I would
not expect them to run it in the long run (like the "first seen" spend
conflict tx replacement policy).
If miners don't use it, I don't see how users can benefit from running that
policy themselves.
They will still have to keep waiting some block confirmation to
exponentially reduce the chances of a successful double-spend attack with
each new confirmation (as explained in the bitcoin white paper).

> Mind you, that risk doesn't apply if we prefer non-empty blocks to
> empty blocks and leave it at that, or only switch if the new block
> doesn't double spend transactions in the old one, so it's a fixable
> issue.

How do you know which of 2 blocks with the same height is "newer"?

> On 11 September 2015 at 12:32, Jorge Tim=C3=B3n
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > On Sep 11, 2015 12:27 PM, "Dave Scotese via bitcoin-dev"
> > <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >>
> >> Rather than (promising to, and when they don't actually, at least
> >> pretending to) use the first-seen block, I propose that a more
sophisticated
> >> method of choosing which of two block solutions to accept.
> >
> > There's already a criterion to chose: the one with more work (in valid
> > blocks) on top of it.
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >

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

<p dir=3D"ltr"><br>
On Sep 11, 2015 1:18 PM, &quot;Christophe Biocca&quot; &lt;<a href=3D"mailt=
o:christophe.biocca@gmail.com">christophe.biocca@gmail.com</a>&gt; wrote:<b=
r>
&gt;<br>
&gt; It&#39;s pretty obvious that Dave is suggesting an alternate tie-break=
er:</p>
<p dir=3D"ltr">I thought he was proposing a new consesnsus rule. I see, thi=
s would be just a policy validation that everybody would be free to ignore =
(like the &quot;first seen&quot; spend conflict tx replacement policy).</p>
<p dir=3D"ltr">I don&#39;t see how miners would benefit from running this p=
olicy so I would not expect them to run it in the long run (like the &quot;=
first seen&quot; spend conflict tx replacement policy).<br>
If miners don&#39;t use it, I don&#39;t see how users can benefit from runn=
ing that policy themselves.<br>
They will still have to keep waiting some block confirmation to exponential=
ly reduce the chances of a successful double-spend attack with each new con=
firmation (as explained in the bitcoin white paper).</p>
<p dir=3D"ltr">&gt; Mind you, that risk doesn&#39;t apply if we prefer non-=
empty blocks to<br>
&gt; empty blocks and leave it at that, or only switch if the new block<br>
&gt; doesn&#39;t double spend transactions in the old one, so it&#39;s a fi=
xable<br>
&gt; issue.</p>
<p dir=3D"ltr">How do you know which of 2 blocks with the same height is &q=
uot;newer&quot;?</p>
<p dir=3D"ltr">&gt; On 11 September 2015 at 12:32, Jorge Tim=C3=B3n<br>
&gt; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d=
ev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt; &gt;<br>
&gt; &gt; On Sep 11, 2015 12:27 PM, &quot;Dave Scotese via bitcoin-dev&quot=
;<br>
&gt; &gt; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitc=
oin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Rather than (promising to, and when they don&#39;t actually, =
at least<br>
&gt; &gt;&gt; pretending to) use the first-seen block, I propose that a mor=
e sophisticated<br>
&gt; &gt;&gt; method of choosing which of two block solutions to accept.<br=
>
&gt; &gt;<br>
&gt; &gt; There&#39;s already a criterion to chose: the one with more work =
(in valid<br>
&gt; &gt; blocks) on top of it.<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; _______________________________________________<br>
&gt; &gt; bitcoin-dev mailing list<br>
&gt; &gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-=
dev@lists.linuxfoundation.org</a><br>
&gt; &gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bit=
coin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a=
><br>
&gt; &gt;<br>
</p>

--f46d0444e9e95b90eb051f7d026f--