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
|
Return-Path: <jl2012@xbt.hk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 960BAEE5
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 28 Aug 2015 03:02:49 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from s47.web-hosting.com (s47.web-hosting.com [199.188.200.16])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 098D7A7
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 28 Aug 2015 03:02:48 +0000 (UTC)
Received: from localhost ([::1]:36488 helo=server47.web-hosting.com)
by server47.web-hosting.com with esmtpa (Exim 4.85)
(envelope-from <jl2012@xbt.hk>)
id 1ZV9wF-00494s-AF; Thu, 27 Aug 2015 23:02:47 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
format=flowed
Content-Transfer-Encoding: 8bit
Date: Thu, 27 Aug 2015 23:02:47 -0400
From: jl2012@xbt.hk
To: Jeff Garzik <jgarzik@gmail.com>
In-Reply-To: <CADm_WcYXEu2dWCBWJwzSJnp6A4iFsR1eBXrQinQmd_NRXAs9Vw@mail.gmail.com>
References: <CADToNK93kmXjwSAxj3WcPSYgq2uReVNJSpX1a5M7DMzgjgv5vA@mail.gmail.com>
<CADm_WcbEhMNWKCY6CqsSTRQztTz3Ap8PMkO+csz+jptc9Nbazg@mail.gmail.com>
<CADToNK972BgCXtZScciF_F+Db_AYWP=obXSqUS7DozY-rAmT7g@mail.gmail.com>
<CADm_WcYXEu2dWCBWJwzSJnp6A4iFsR1eBXrQinQmd_NRXAs9Vw@mail.gmail.com>
Message-ID: <038c418c354b4b4559137652282e88b4@xbt.hk>
X-Sender: jl2012@xbt.hk
User-Agent: Roundcube Webmail/1.0.5
X-AntiAbuse: This header was added to track abuse,
please include it with any abuse report
X-AntiAbuse: Primary Hostname - server47.web-hosting.com
X-AntiAbuse: Original Domain - lists.linuxfoundation.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - xbt.hk
X-Get-Message-Sender-Via: server47.web-hosting.com: authenticated_id:
jl2012@xbt.hk
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Questiosn about BIP100
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, 28 Aug 2015 03:02:49 -0000
Mode could be ruled out immediately. Just consider this: 34% 8MB, 33%
1.5MB, 33% 1.2MB
I personally believe the median is the most natural and logical choice.
51% of miners can always force the 49% to follow the simple majority
choice through a 51% attack. Using median will eliminate the incentive
to 51% attack due to this reason. The incentive to 51% attack will exist
when you use any value other than 50-percentile. The further it is from
50, the bigger the incentive.
Having said that, I don't think it is an absolutely bad idea to use a
value other than 50-percentile. The exact value is debatable.
However, if you use something other than median, you should make it
symmetrical. For example, the block size will increase if the
20-percentile is bigger than the current limit, and the block size will
decrease if the 80-percentile is smaller than the current limit.
Jeff Garzik via bitcoin-dev 於 2015-08-27 16:49 寫到:
> 20th percentile, though there is some argument to take the 'mode' of
> several tranches
>
> On Thu, Aug 27, 2015 at 11:07 AM, Andrew C <achow101@gmail.com> wrote:
>
>> I have been reading the pdf and one thing I can't figure out is what
>> you mean by "most common floor". Is that the smallest block size
>> that has a vote or the block size with the most votes or something
>> else?
>>
>> On Mon, Aug 24, 2015 at 10:40 AM Jeff Garzik <jgarzik@gmail.com>
>> wrote:
>>
>> Great questions.
>>
>> - Currently working on technical BIP draft and implementation,
>> hopefully for ScalingBitcoin.org. Only the PDF is publicly
>> available as of today.
>> - Yes, the initial deployment is in the same manner as size votes.
>>
>> On Fri, Aug 21, 2015 at 7:38 PM, Andrew C via bitcoin-dev
>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> Hi all,
>>
>> Is there any client or code that currently implements BIP 100? And
>> how will it be deployed? WIll the initial fork be deployed in the
>> same manner that the max block size changes are deployed described
>> in the bip?
>>
>> Thanks
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [1]
>
>
>
> Links:
> ------
> [1] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
