jl2012 at xbt.hk [ARCHIVE] on Nostr: š Original date posted:2015-08-28 š Original message:Mode could be ruled out ...
š
Original date posted:2015-08-28
š Original message: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 at 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 at 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 at 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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
š Original message: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 at 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 at 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 at 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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev