John T. Winslow [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-08-01 to 2015-08-01
💬 Posted a total of 1 messages
📚 Participated in the following categories:
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 17:32:07

- reply

📅 Original date posted:2015-08-01
📝 Original message:Regarding the block size increase, at least conceptually it seems to me
there should be an easy solution. If we look at what works well with
bitcoin, for example the block reward halving and difficulty regimes
which due to their step function nature both contribute to the stability
and predictability of the bitcoin universe while still allowing for the
necessary dynamic adjustments. It seems to me there should be a
corresponding and equally simple solution for the maximum block size.
I've never quite understood the supposed rationale behind the proposals
for a new static maximum of 20 MB or 8 MB or 2 MB other than it would be
trivial to implement. Why not come up with an equally simple,
predictable dynamic function consistent with what is already proven to
work in the bitcoin universe that would both preserve the scarcity of
transaction capacity to encourage a fee market but also allow for more
transactions when needed.
For example how about something like once every month at month-end, take
the 6-month average non-zero transaction fee block size and multiply by 1.5?
With the # of transactions increasing then plateauing you arrive at a
constant excess capacity of around 33%:
MO ABS MBS EX CAP
1 750 1000 25.0%
2 775 1000 22.5%
3 800 1000 20.0%
4 825 1000 17.5%
5 850 1000 15.0%
6 875 1219 28.2%
7 900 1256 28.4%
8 925 1294 28.5%
9 950 1331 28.6%
10 975 1369 28.8%
11 1000 1406 28.9%
12 1000 1438 30.4%
13 1000 1463 31.6%
14 1000 1481 32.5%
15 1000 1494 33.1%
16 1000 1500 33.3%
17 1000 1500 33.3%
18 1000 1500 33.3%
Similarly, in a declining then plateauing # of transactions market you
also arrive at a constant excess capacity of about 33%
MO ABS MBS EX CAP
1 750 1000 25.0%
2 725 1000 27.5%
3 700 1000 30.0%
4 675 1000 32.5%
5 650 1000 35.0%
6 625 1031 39.4%
7 600 994 39.6%
8 575 956 39.9%
9 550 919 40.1%
10 525 881 40.4%
11 500 844 40.7%
12 500 813 38.5%
13 500 788 36.5%
14 500 769 35.0%
15 500 756 33.9%
16 500 750 33.3%
17 500 750 33.3%
18 500 750 33.3%
With some simple statistical analysis, one could easily arrive at a
statistically-inferred excess capacity linked the to probability of
transaction volume exceeding the new cap in any forward monthly
interval. In the tables above, I have used my own intuition that people
seem to be generally comfortable with excess capacity of >= 33% and
become less so at < 33%.
A scheme like this would have multiple benefits:
1) Adapts predictably and automatically to both rising and declining
market demand for transactions
2) Preserves the fee market with a constant target excess capacity
3) Monthly adjustment interval and six month lookback allow for
sufficient time to plan for changes in system capacity
In the case where transaction volume spikes such that it exceeds the
monthly limit, the fee market would then take over to ensure high
priority transactions get through fastest. In the case of malicious
activity, such an attack would have to be maintained for well over a
month to significantly adversely affect the maximum block size. As long
as there is a non-zero cost to such attacks, the likelihood of
maintaining one for a period of months decreases significantly.
Thx,
JTW
On 7/31/2015 1:45 PM, Eric Lombrozo via bitcoin-dev wrote:
>
> I would love to be able to increase block size. But I have serious
> doubts about being able to do this safely at this time given what we
> presently know about the Bitcoin network. And I'm pretty sure I'm not
> alone in this sentiment.
>
> Had we been working on fixing the known issues that most complicate
> bigger blocks in the last six years, or even in the last three years
> after many issues had already been well-identified, perhaps we'd be
> ready to increase the limit. But other things have seemed more
> important, like specifying the use of X.509 overlay protocols or
> adding complex filtering mechanisms to the p2p protocol to make it
> practical to use tx merkle trees...and as a result we're not ready for
> safely allowing larger blocks.
>
> - Eric
>
> On Jul 30, 2015 11:43 PM, "Thomas Zander via bitcoin-dev"
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> On Thursday 30. July 2015 16.33.16 <tel:2015%2016.33.16> Eric
> Lombrozo via bitcoin-dev wrote:
> > I don’t think it’s really a matter of whether we agree on
> whether it’s good
> > to raise the block size limit, Gavin. I think it’s a matter of a
> difference
> > in priorities.
>
> Having different priorities is fine, using your time to block
> peoples attempts
> to increase block size is not showing different priorities, it
> shows conflicting
> priorities.
> Different priorities means you can trust someone else to do things
> they care
> about while you do things you care about.
> --
> Thomas Zander
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150801/f9491970/attachment-0001.html>

2023-06-07 17:32:07

- reply

2023-06-07 15:44:31

- reply