Gavin Andresen [ARCHIVE] on Nostr: š Original date posted:2015-08-04 š Original message:On Tue, Aug 4, 2015 at ...
š
Original date posted:2015-08-04
š Original message:On Tue, Aug 4, 2015 at 2:41 PM, Dave Hudson via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Fundamentally a block maker (pool or aggregation of pools) does not orphan
> its own blocks.
Unless the block maker has an infinitely fast connection to it's hashpower
OR it's hashpower is not parallelized at all, that's not strictly true --
it WILL orphan its own blocks because two hashing units will find solutions
in the time it takes to communicate that solution to the block maker and to
the rest of the hashing units.
That's getting into "how many miners can dance on the head of a pin"
territory, though. I don't think we know whether the communication
advantages of putting lots of hashing power physically close together will
outweigh the extra cooling costs of doing that (or maybe some other
tradeoff I haven't thought of). That would be a fine topic for another
paper....
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150804/a696269d/attachment.html>
š Original message:On Tue, Aug 4, 2015 at 2:41 PM, Dave Hudson via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Fundamentally a block maker (pool or aggregation of pools) does not orphan
> its own blocks.
Unless the block maker has an infinitely fast connection to it's hashpower
OR it's hashpower is not parallelized at all, that's not strictly true --
it WILL orphan its own blocks because two hashing units will find solutions
in the time it takes to communicate that solution to the block maker and to
the rest of the hashing units.
That's getting into "how many miners can dance on the head of a pin"
territory, though. I don't think we know whether the communication
advantages of putting lots of hashing power physically close together will
outweigh the extra cooling costs of doing that (or maybe some other
tradeoff I haven't thought of). That would be a fine topic for another
paper....
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150804/a696269d/attachment.html>