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
|
Return-Path: <christophe.biocca@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 5A036F93
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 11 Sep 2015 19:06:45 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f177.google.com (mail-io0-f177.google.com
[209.85.223.177])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3B69C1F1
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 11 Sep 2015 19:06:44 +0000 (UTC)
Received: by iofb144 with SMTP id b144so109339874iof.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 11 Sep 2015 12:06:43 -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:content-transfer-encoding;
bh=Y5c6E1UEirsXckY8nDIkLJqN46gqfLQ+3bDYAQL3lGI=;
b=Na2g//vBZFdyssAqUjGlRjbg8hf8KOfa7wz4Wdf0UZ8f7LMlNRZE7pTQi4hjkMOgsR
lb9WnAuVs/fn0W8AUstcC3EENq4AJyasfEOrh1BVZiTKTIsfS6ByJ7EoLODRu3lTcqYt
RsjQXXpBjhPPTxO4Vmt9SohOvKSZEL6fF+Gg0X9xccb5R4jil0XNTiTSHF7YHOV+HpSR
widdQXLRdwAg4zd0w9wdutBR3/eelI6ZZaYVephb66U+PwnXEn07YwBEgo3Y4uV/1a2u
jE9ZZMnRVyxOh8gb7XJTZ6pxwAp11DhkIHFPY/YT/UPLbBpyfdiUAZqAwopbdPwLzmRf
lfow==
MIME-Version: 1.0
X-Received: by 10.107.156.14 with SMTP id f14mr6461641ioe.32.1441998403670;
Fri, 11 Sep 2015 12:06:43 -0700 (PDT)
Received: by 10.36.110.19 with HTTP; Fri, 11 Sep 2015 12:06:43 -0700 (PDT)
In-Reply-To: <CABm2gDoCecK1jk6i_bZMTRCTQUseXYugi5ntykMimzns_dxFug@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>
<CABm2gDoCecK1jk6i_bZMTRCTQUseXYugi5ntykMimzns_dxFug@mail.gmail.com>
Date: Fri, 11 Sep 2015 15:06:43 -0400
Message-ID: <CANOOu=_fX6buYhLz0hB0Swzu8MpgMx6UudFZfF4sJ_Cd4SVo5A@mail.gmail.com>
From: Christophe Biocca <christophe.biocca@gmail.com>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,URIBL_BLACK
autolearn=no 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 19:06:45 -0000
> How do you know which of 2 blocks with the same height is "newer"?
From the particular node's perspective. I'm aware there is no
possibility of consistent global ordering.
Dave's code is about switching blocks (instead of continuing on the
existing one), and, in that context, "old" means the first sibling the
node saw, and "new" is any subsequent block. I will disambiguate this
in the future, because I'm clearly confusing at least 1 person.
> 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 conf=
lict tx replacement policy).
There's always a default, and if miners don't have any overriding
reason to change, they'll likely stick to it. Which is why Dave
started his statement with:
> Rather than (promising to, and when they don't actually, at least pretend=
ing to) use the first-seen block
Clearly recognizing that any changed logic is non-binding.
On 11 September 2015 at 14:37, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote:
>
> 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 ju=
st
> a policy validation that everybody would be free to ignore (like the "fir=
st
> 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 confli=
ct
> tx replacement policy).
> If miners don't use it, I don't see how users can benefit from running th=
at
> 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
>> >
|
