Greg Sanders [ARCHIVE] on Nostr: 📅 Original date posted:2017-01-27 📝 Original message:Note that the 4MB number ...
📅 Original date posted:2017-01-27
📝 Original message:Note that the 4MB number comes from a single network metric.
Quotes directly from the paper in question:
http://fc16.ifca.ai/bitcoin/papers/CDE+16.pdf
>Our results hinge on the key metric of effective throughput in the overlay
network, which we define here as which blocks propagate within an average
block interval period the percentage of nodes to.
...
>Note that as we consider only a subset of possible metrics (due to
difficulty in accurately measuring others), our results on
reparametrization may be viewed as upper bounds: additional metrics could
reveal even stricter limits.
It says nothing about any mining centralization pressure, DoS attacks, etc.
A single metric among many we have to contend with.
On Fri, Jan 27, 2017 at 3:34 PM, Russell O'Connor via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> On Jan 27, 2017 03:03, "Andrew Johnson via bitcoin-dev" <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Other researchers have come to the conservative conclusion that we could
> handle 4MB blocks today.
>
>
> I believe this is a mischaracterization of the research conclusions. The
> actual conclusion was that the maximum value for the blocksize that the
> network can safely handle (at that time) is some value that is
> (conservatively) no more than 4MB. This is because the research only
> studies one aspect of the effect of blocksize on the network at a time and
> the true safe value is the minimum of all aspects. For example, the 4MB
> doesn't cover the aspect of quadratic hashing for large transactions in
> large blocks.
>
> _______________________________________________
> 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/20170127/c4f1926d/attachment-0001.html>;
📝 Original message:Note that the 4MB number comes from a single network metric.
Quotes directly from the paper in question:
http://fc16.ifca.ai/bitcoin/papers/CDE+16.pdf
>Our results hinge on the key metric of effective throughput in the overlay
network, which we define here as which blocks propagate within an average
block interval period the percentage of nodes to.
...
>Note that as we consider only a subset of possible metrics (due to
difficulty in accurately measuring others), our results on
reparametrization may be viewed as upper bounds: additional metrics could
reveal even stricter limits.
It says nothing about any mining centralization pressure, DoS attacks, etc.
A single metric among many we have to contend with.
On Fri, Jan 27, 2017 at 3:34 PM, Russell O'Connor via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> On Jan 27, 2017 03:03, "Andrew Johnson via bitcoin-dev" <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Other researchers have come to the conservative conclusion that we could
> handle 4MB blocks today.
>
>
> I believe this is a mischaracterization of the research conclusions. The
> actual conclusion was that the maximum value for the blocksize that the
> network can safely handle (at that time) is some value that is
> (conservatively) no more than 4MB. This is because the research only
> studies one aspect of the effect of blocksize on the network at a time and
> the true safe value is the minimum of all aspects. For example, the 4MB
> doesn't cover the aspect of quadratic hashing for large transactions in
> large blocks.
>
> _______________________________________________
> 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/20170127/c4f1926d/attachment-0001.html>;