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
|
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 6F4CF1189
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 11 Sep 2015 17:18:11 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com
[209.85.213.175])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 08B881CF
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 11 Sep 2015 17:18:10 +0000 (UTC)
Received: by igbkq10 with SMTP id kq10so49901921igb.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 11 Sep 2015 10:18:10 -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=uKqFo67N+4vau0Enybsx+MiEGXQ1QH+I3y7giw/Uk3o=;
b=hiPGXKX3ZTJGCccxEWC++fy5zP8OQyHwyPeoelGp9LwvgD8BG5iLL/eQ7o9R55WsWG
qlrJOrnzUQ2HiR/jvuFTuKkrwLBp5vU8nxrtyxsn+CeV9nhn/o7pk0ttlLVMLqtom+bb
YHZCFRhn1AWOkBhl93TQIwWk+iofEeC22bMqIE/Ff1hI8x/KxC2dJWaxGk/pXJ2IOLpw
Px1jX67IyBFf+ajpgz8D6KEweIaPAo04HCAUFPzV52fBBBu38eLs0UtQhYHTlEeqrWkZ
OBhtmRyMVcCHkKiREM3do/vqEa4tU4f8TgSOYddshYfKiq9JugzdB13VfEoeCxu11PH6
XlmQ==
MIME-Version: 1.0
X-Received: by 10.50.79.196 with SMTP id l4mr17198351igx.48.1441991890445;
Fri, 11 Sep 2015 10:18:10 -0700 (PDT)
Received: by 10.36.110.19 with HTTP; Fri, 11 Sep 2015 10:18:10 -0700 (PDT)
In-Reply-To: <CABm2gDpsJdSDTyvTGNSZXX1+UyAHxTB=ODuy6bJvMj3A9BqhqQ@mail.gmail.com>
References: <CAGLBAhd11-_LNJ-ba6NXmWBXz=yb+pFTmf9tHAgFW_m6S5jnfw@mail.gmail.com>
<CABm2gDpsJdSDTyvTGNSZXX1+UyAHxTB=ODuy6bJvMj3A9BqhqQ@mail.gmail.com>
Date: Fri, 11 Sep 2015 13:18:10 -0400
Message-ID: <CANOOu=8jT++mX_pTHrEnryJqiw3C+J3mWKL27dEkQh=rO0q_Cg@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=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
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 17:18:11 -0000
It's pretty obvious that Dave is suggesting an alternate tie-breaker:
> It also makes an empty block far less attractive because it is easily rep=
laced, all the way until the next block locks it in.
I do see a problem with the proposal. Right now, when a miner sees a
new block with the most work and there are no ties, it is always a
good idea to build on top of it (unless they're in the middle of
building a private chain, or other pathological cases).
With this new heuristic (assuming it is actually followed by a good
chunk of people), a miner can reasonably know whether or not they can
safely mine a sibling of the block instead. When enough widely
propagated transactions exist, and the block to orphan is small,
there's minimal risk in mining a sibling block instead of a child
block (the only extra risk is in someone else mining a child block
right around the time we suceed in mining a siblish block, where we'll
definitely be orphaned instead of ~50% of the time).
Because the risk can be measured and is sometimes very small, it will
then be profitable for a miner to orphan a small non-empty block and
double-spend some confirmed transactions whenever the block confirming
them is easily replaced. This lowers the security of 1-conf
transactions.
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.
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 sophistic=
ated
>> 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
>
|
