* Re: [bitcoin-dev] BIP - Block75 - Historical and future projections (t. khan)
@ 2017-01-10 4:14 Ryan J Martin
2017-01-10 10:04 ` Adam Back
2017-01-10 19:09 ` t. khan
0 siblings, 2 replies; 3+ messages in thread
From: Ryan J Martin @ 2017-01-10 4:14 UTC (permalink / raw)
To: bitcoin-dev
The adaptive/automatic block size notion has been around for a while--- others would be better able to speak to why it hasn't gotten traction. However my concern with something like that is that it doesn't regard the optimal economic equilibrium for tx fees/size---not that the current limit does either but the concern with an auto-adjusting size limit that ignores this would be the potential to create unforeseen externalities for miners/users. Miners may decide it is more profitable to mine very small blocks to constrict supply and increase marginal fees and with how centralized mining is, where a dozen pools have 85% hashrate, a couple of pools could do this. Then on the other side, maybe the prisoner's dilemma would hold and all miners would have minrelaytxfee set at zero and users would push the blocks to larger and larger sizes causing higher and higher latency and network issues.
Perhaps something like this could work (I can only speak to the economic side anyway) but it would have to have some solid code that has a social benefit model built in to adjust to an equilibrium that is able to optimize---as in maximizes benefit/minimize cost for both sides via a Marshallian surplus model--- for each size point.
To be clear, I'm not saying an auto-adjusting limit is unworkable (again only from an economic standpoint), just that it would need to have these considerations built in.
-Ryan J. Martin
________________________________________
------------------------------
Message: 2
Date: Mon, 9 Jan 2017 14:52:31 -0500
From: "t. khan" <teekhan42@gmail.com>
To: Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
Subject: [bitcoin-dev] BIP - Block75 - Historical and future
projections
Message-ID:
<CAGCNRJpSV9zKxhVvqpMVPyFyXco_ABB9a7_ihaDKEKFPQ9v3sw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Using daily average block size over the past year (source:
https://blockchain.info/charts/avg-block-size?daysAverageString=14×pan=1year
), here's how Block75 would have altered max block sizes:
[image: Inline image 1]
As of today, the max block size would be 1,135KB.
Looking forward and using the last year's growth rate as a model:
[image: Inline image 2]
This shows the max block size one year from now would be 2,064KB, if
Block75 activated today.
Of course, this is just an estimate, but even accounting for a substantial
increase in transactions in the last quarter of 2017 and changes brought
about by SegWit (hopefully) activating, Block75 alters the max size in such
a way that allows for growth, keeps blocks as small as possible, *and*
maintains transaction fees at a level similar to May/June 2016.
If anyone has an alternate way to model future behavior, please run it
through the Block75 algorithm.
Every 2016 blocks, do this:
new max blocksize = x + (x * (AVERAGE_CAPACITY - TARGET_CAPACITY))
TARGET_CAPACITY = 0.75 //Block75's target of keeping blocks 75% full
AVERAGE_CAPACITY = average percentage full of the last 2016 blocks, as a
decimal
x = current max block size
Thanks,
- t.k.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170109/b0e0b713/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Block75 2016.png
Type: image/png
Size: 32088 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170109/b0e0b713/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Block75 2017.png
Type: image/png
Size: 33176 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170109/b0e0b713/attachment-0001.png>
------------------------------
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
End of bitcoin-dev Digest, Vol 20, Issue 21
*******************************************
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [bitcoin-dev] BIP - Block75 - Historical and future projections (t. khan)
2017-01-10 4:14 [bitcoin-dev] BIP - Block75 - Historical and future projections (t. khan) Ryan J Martin
@ 2017-01-10 10:04 ` Adam Back
2017-01-10 19:09 ` t. khan
1 sibling, 0 replies; 3+ messages in thread
From: Adam Back @ 2017-01-10 10:04 UTC (permalink / raw)
To: Ryan J Martin, Bitcoin Protocol Discussion
See discussion on bitcoin-discuss on this topic last few days. People
may want to subscribe to that for more free wheeling discussion.
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-discuss
Adam
On 10 January 2017 at 04:14, Ryan J Martin via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> The adaptive/automatic block size notion has been around for a while--- others would be better able to speak to why it hasn't gotten traction. However my concern with something like that is that it doesn't regard the optimal economic equilibrium for tx fees/size---not that the current limit does either but the concern with an auto-adjusting size limit that ignores this would be the potential to create unforeseen externalities for miners/users. Miners may decide it is more profitable to mine very small blocks to constrict supply and increase marginal fees and with how centralized mining is, where a dozen pools have 85% hashrate, a couple of pools could do this. Then on the other side, maybe the prisoner's dilemma would hold and all miners would have minrelaytxfee set at zero and users would push the blocks to larger and larger sizes causing higher and higher latency and network issues.
> Perhaps something like this could work (I can only speak to the economic side anyway) but it would have to have some solid code that has a social benefit model built in to adjust to an equilibrium that is able to optimize---as in maximizes benefit/minimize cost for both sides via a Marshallian surplus model--- for each size point.
> To be clear, I'm not saying an auto-adjusting limit is unworkable (again only from an economic standpoint), just that it would need to have these considerations built in.
>
> -Ryan J. Martin
>
>
> ________________________________________
>
> ------------------------------
>
> Message: 2
> Date: Mon, 9 Jan 2017 14:52:31 -0500
> From: "t. khan" <teekhan42@gmail.com>
> To: Bitcoin Protocol Discussion
> <bitcoin-dev@lists.linuxfoundation.org>
> Subject: [bitcoin-dev] BIP - Block75 - Historical and future
> projections
> Message-ID:
> <CAGCNRJpSV9zKxhVvqpMVPyFyXco_ABB9a7_ihaDKEKFPQ9v3sw@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Using daily average block size over the past year (source:
> https://blockchain.info/charts/avg-block-size?daysAverageString=14×pan=1year
> ), here's how Block75 would have altered max block sizes:
>
> [image: Inline image 1]
>
> As of today, the max block size would be 1,135KB.
>
> Looking forward and using the last year's growth rate as a model:
>
> [image: Inline image 2]
>
> This shows the max block size one year from now would be 2,064KB, if
> Block75 activated today.
>
> Of course, this is just an estimate, but even accounting for a substantial
> increase in transactions in the last quarter of 2017 and changes brought
> about by SegWit (hopefully) activating, Block75 alters the max size in such
> a way that allows for growth, keeps blocks as small as possible, *and*
> maintains transaction fees at a level similar to May/June 2016.
>
> If anyone has an alternate way to model future behavior, please run it
> through the Block75 algorithm.
>
> Every 2016 blocks, do this:
>
> new max blocksize = x + (x * (AVERAGE_CAPACITY - TARGET_CAPACITY))
>
> TARGET_CAPACITY = 0.75 //Block75's target of keeping blocks 75% full
> AVERAGE_CAPACITY = average percentage full of the last 2016 blocks, as a
> decimal
> x = current max block size
>
>
> Thanks,
>
> - t.k.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170109/b0e0b713/attachment.html>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: Block75 2016.png
> Type: image/png
> Size: 32088 bytes
> Desc: not available
> URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170109/b0e0b713/attachment.png>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: Block75 2017.png
> Type: image/png
> Size: 33176 bytes
> Desc: not available
> URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170109/b0e0b713/attachment-0001.png>
>
> ------------------------------
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> End of bitcoin-dev Digest, Vol 20, Issue 21
> *******************************************
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [bitcoin-dev] BIP - Block75 - Historical and future projections (t. khan)
2017-01-10 4:14 [bitcoin-dev] BIP - Block75 - Historical and future projections (t. khan) Ryan J Martin
2017-01-10 10:04 ` Adam Back
@ 2017-01-10 19:09 ` t. khan
1 sibling, 0 replies; 3+ messages in thread
From: t. khan @ 2017-01-10 19:09 UTC (permalink / raw)
To: Ryan J Martin, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 4877 bytes --]
As Block75 maintains blocks at 75% full (average over time), it
automatically stabilizes transaction fees at about the level they were in
May/June 2016. It will even do so through changes in transaction size and
volume caused by SegWit and Lightning.
- t.k.
On Mon, Jan 9, 2017 at 11:14 PM, Ryan J Martin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> The adaptive/automatic block size notion has been around for a
> while--- others would be better able to speak to why it hasn't gotten
> traction. However my concern with something like that is that it doesn't
> regard the optimal economic equilibrium for tx fees/size---not that the
> current limit does either but the concern with an auto-adjusting size limit
> that ignores this would be the potential to create unforeseen
> externalities for miners/users. Miners may decide it is more profitable to
> mine very small blocks to constrict supply and increase marginal fees and
> with how centralized mining is, where a dozen pools have 85% hashrate, a
> couple of pools could do this. Then on the other side, maybe the prisoner's
> dilemma would hold and all miners would have minrelaytxfee set at zero and
> users would push the blocks to larger and larger sizes causing higher and
> higher latency and network issues.
> Perhaps something like this could work (I can only speak to the
> economic side anyway) but it would have to have some solid code that has a
> social benefit model built in to adjust to an equilibrium that is able to
> optimize---as in maximizes benefit/minimize cost for both sides via a
> Marshallian surplus model--- for each size point.
> To be clear, I'm not saying an auto-adjusting limit is unworkable
> (again only from an economic standpoint), just that it would need to have
> these considerations built in.
>
> -Ryan J. Martin
>
>
> ________________________________________
>
> ------------------------------
>
> Message: 2
> Date: Mon, 9 Jan 2017 14:52:31 -0500
> From: "t. khan" <teekhan42@gmail.com>
> To: Bitcoin Protocol Discussion
> <bitcoin-dev@lists.linuxfoundation.org>
> Subject: [bitcoin-dev] BIP - Block75 - Historical and future
> projections
> Message-ID:
> <CAGCNRJpSV9zKxhVvqpMVPyFyXco_ABB9a7_ihaDKEKFPQ9v3sw@mail.
> gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Using daily average block size over the past year (source:
> https://blockchain.info/charts/avg-block-size?
> daysAverageString=14×pan=1year
> ), here's how Block75 would have altered max block sizes:
>
> [image: Inline image 1]
>
> As of today, the max block size would be 1,135KB.
>
> Looking forward and using the last year's growth rate as a model:
>
> [image: Inline image 2]
>
> This shows the max block size one year from now would be 2,064KB, if
> Block75 activated today.
>
> Of course, this is just an estimate, but even accounting for a substantial
> increase in transactions in the last quarter of 2017 and changes brought
> about by SegWit (hopefully) activating, Block75 alters the max size in such
> a way that allows for growth, keeps blocks as small as possible, *and*
> maintains transaction fees at a level similar to May/June 2016.
>
> If anyone has an alternate way to model future behavior, please run it
> through the Block75 algorithm.
>
> Every 2016 blocks, do this:
>
> new max blocksize = x + (x * (AVERAGE_CAPACITY - TARGET_CAPACITY))
>
> TARGET_CAPACITY = 0.75 //Block75's target of keeping blocks 75% full
> AVERAGE_CAPACITY = average percentage full of the last 2016 blocks, as a
> decimal
> x = current max block size
>
>
> Thanks,
>
> - t.k.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> attachments/20170109/b0e0b713/attachment.html>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: Block75 2016.png
> Type: image/png
> Size: 32088 bytes
> Desc: not available
> URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> attachments/20170109/b0e0b713/attachment.png>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: Block75 2017.png
> Type: image/png
> Size: 33176 bytes
> Desc: not available
> URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> attachments/20170109/b0e0b713/attachment-0001.png>
>
> ------------------------------
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> End of bitcoin-dev Digest, Vol 20, Issue 21
> *******************************************
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 6801 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2017-01-10 19:09 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-01-10 4:14 [bitcoin-dev] BIP - Block75 - Historical and future projections (t. khan) Ryan J Martin
2017-01-10 10:04 ` Adam Back
2017-01-10 19:09 ` t. khan
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
