jl2012 at xbt.hk [ARCHIVE] on Nostr: 📅 Original date posted:2015-08-30 📝 Original message:Jorge Timón via ...
📅 Original date posted:2015-08-30
📝 Original message:Jorge Timón via bitcoin-dev 於 2015-08-29 16:41 寫到:
>
> I still don't see the point in having a lower moving size maximum.
> If 8 MB is mining-centralization-safe, let's move directly to 8 MB
> without adding this seemingly useless extra complexity.
> If it's not, mining voting on a lower moving maximum won't make it
> safer.
>
> Once we have more objective tools (centralization metrics, simulators,
> etc...) to determine whether or not a block size is
> mining-centralization-safe for a given point in time (looking at
> current centralization and current technology available), I don't see
> the problem with repeating the equivalent of bip102 periodically
> (every 2 years?) to adapt the size to better technology or lower
> mining centralization.
> It would be also helpful to have a tool to somehow measure "size
> increase urgency" (ie right now free transactions get mined and blocks
> aren't full or close to be full, I don't think the current general
> sense of urgency on this matter is justified).
>
> With all respect, I believe bip100 and this proposal are
> over-engineering; and bip101 and bip103 (pieter's) are
> overly-optimistic (in their exponential technological growth
> assumptions).
This is based on the assumption that miners would always like to use up
the last byte of the available block size. However, this is just not
true:
1. The 6 year blockchain history has shown that most miners have a soft
cap with their block size.
2. Chinese miners, controlling 60% of the network, rejected Gavin's
initial 20MB proposal and asked for 8MB:
http://cointelegraph.com/news/114577/chinese-mining-pools-propose-alternative-8-mb-block-size
3. BTCChina supports BIP100 and will vote for 2MB at the beginning, with
8MB as a mid-term goal:
https://vip.btcchina.com/page/noticetemplate?id=100.
BTCChina is controlling 12% of the network in the past month. If BIP100
uses the 20-percentile vote as the block size, it takes only 8% more
vote to keep the size at 2MB
For many reasons miners may want to have a smaller block size, which we
don't need to list them here. Although they can limit it by a softfork
or even 51% attack, it is a very violent process. Why don't we just
allow them to vote for a lower limit?
So I think the right way is to choose a mining-centralization-safe
limit, and let it free float within a range based on miner's vote. If we
are lucky enough to have some responsible miners, they will keep it as
low as possible, until the legitimate tx volume catches up. Even in the
worst case, the block size is still mining-centralization-safe. The
upper limit may increase linearly, if not exponentially, until we find a
better long-term solution. (sort of a combination of BIP100 and 101,
with different parameters)
--------
For the matter of "urgency", I agree with you that there is no actual
urgency AT THIS MOMENT. However, if a hardfork may take 5 years to
deploy (as you suggested), we really have the urgency to make a decision
now. Actually, the main point is not urgency but uncertainty. We have
debated for 5 years. Why won't we have 5 more years of debate, plus 5
years of deployment delay? Are we sticking to 1MB for 10 years? In that
case Bitcoin Core must be abandoned by the economic majority and a
Schism fork must occur.
📝 Original message:Jorge Timón via bitcoin-dev 於 2015-08-29 16:41 寫到:
>
> I still don't see the point in having a lower moving size maximum.
> If 8 MB is mining-centralization-safe, let's move directly to 8 MB
> without adding this seemingly useless extra complexity.
> If it's not, mining voting on a lower moving maximum won't make it
> safer.
>
> Once we have more objective tools (centralization metrics, simulators,
> etc...) to determine whether or not a block size is
> mining-centralization-safe for a given point in time (looking at
> current centralization and current technology available), I don't see
> the problem with repeating the equivalent of bip102 periodically
> (every 2 years?) to adapt the size to better technology or lower
> mining centralization.
> It would be also helpful to have a tool to somehow measure "size
> increase urgency" (ie right now free transactions get mined and blocks
> aren't full or close to be full, I don't think the current general
> sense of urgency on this matter is justified).
>
> With all respect, I believe bip100 and this proposal are
> over-engineering; and bip101 and bip103 (pieter's) are
> overly-optimistic (in their exponential technological growth
> assumptions).
This is based on the assumption that miners would always like to use up
the last byte of the available block size. However, this is just not
true:
1. The 6 year blockchain history has shown that most miners have a soft
cap with their block size.
2. Chinese miners, controlling 60% of the network, rejected Gavin's
initial 20MB proposal and asked for 8MB:
http://cointelegraph.com/news/114577/chinese-mining-pools-propose-alternative-8-mb-block-size
3. BTCChina supports BIP100 and will vote for 2MB at the beginning, with
8MB as a mid-term goal:
https://vip.btcchina.com/page/noticetemplate?id=100.
BTCChina is controlling 12% of the network in the past month. If BIP100
uses the 20-percentile vote as the block size, it takes only 8% more
vote to keep the size at 2MB
For many reasons miners may want to have a smaller block size, which we
don't need to list them here. Although they can limit it by a softfork
or even 51% attack, it is a very violent process. Why don't we just
allow them to vote for a lower limit?
So I think the right way is to choose a mining-centralization-safe
limit, and let it free float within a range based on miner's vote. If we
are lucky enough to have some responsible miners, they will keep it as
low as possible, until the legitimate tx volume catches up. Even in the
worst case, the block size is still mining-centralization-safe. The
upper limit may increase linearly, if not exponentially, until we find a
better long-term solution. (sort of a combination of BIP100 and 101,
with different parameters)
--------
For the matter of "urgency", I agree with you that there is no actual
urgency AT THIS MOMENT. However, if a hardfork may take 5 years to
deploy (as you suggested), we really have the urgency to make a decision
now. Actually, the main point is not urgency but uncertainty. We have
debated for 5 years. Why won't we have 5 more years of debate, plus 5
years of deployment delay? Are we sticking to 1MB for 10 years? In that
case Bitcoin Core must be abandoned by the economic majority and a
Schism fork must occur.