Peter Todd [ARCHIVE] on Nostr: š Original date posted:2015-08-04 š Original message:-----BEGIN PGP SIGNED ...
š
Original date posted:2015-08-04
š Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 4 August 2015 17:30:28 GMT-04:00, Gavin Andresen via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>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....
I'd suggest you do more research into how Bitcoin and mining works as the above has a number of serious misunderstandings.
Or, I could just point out the obvious rather than try to be polite: you know exactly why the above makes no sense as a reply to this thread and are deliberately lying.
If the situation is the latter, your conduct is toxic to the development mailing list discussion, not to mention a waste of all our time, and you should leave.
-----BEGIN PGP SIGNATURE-----
iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVwTKi
AAoJEMCF8hzn9Lnc47AH/0txNyw9dLdsfQOsNE14jLEcQifxOkaKLqTJV1O4gn6O
L4+T6rPo9pVLTBuVWcsm2A24R/gBL+pYaWgaIyk/3fbSRpg4GfVau0xxh54vQU6m
U4L7FPHsdZ2y67frv/+5ExJ2xrVuedhpTciTi2SqSE6C0fioO+YarH0Dvd8I5Wjx
f9GnmxLdKytoj2kUaoriSSxsUzMNzxVzq78jEmhMR85TGy73ApeLdgBC/pdNgxZa
oAQ0CXCMYgsE59HUOO05xFLazGxNh2epPADTbTTgoNQ9py38evlW254okhRmk9p9
v4i1yTzuv/Y6C0qw2RZcEiT/GTdvajkMKCidLEm3LbY=
=W/Ke
-----END PGP SIGNATURE-----
š Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 4 August 2015 17:30:28 GMT-04:00, Gavin Andresen via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>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....
I'd suggest you do more research into how Bitcoin and mining works as the above has a number of serious misunderstandings.
Or, I could just point out the obvious rather than try to be polite: you know exactly why the above makes no sense as a reply to this thread and are deliberately lying.
If the situation is the latter, your conduct is toxic to the development mailing list discussion, not to mention a waste of all our time, and you should leave.
-----BEGIN PGP SIGNATURE-----
iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVwTKi
AAoJEMCF8hzn9Lnc47AH/0txNyw9dLdsfQOsNE14jLEcQifxOkaKLqTJV1O4gn6O
L4+T6rPo9pVLTBuVWcsm2A24R/gBL+pYaWgaIyk/3fbSRpg4GfVau0xxh54vQU6m
U4L7FPHsdZ2y67frv/+5ExJ2xrVuedhpTciTi2SqSE6C0fioO+YarH0Dvd8I5Wjx
f9GnmxLdKytoj2kUaoriSSxsUzMNzxVzq78jEmhMR85TGy73ApeLdgBC/pdNgxZa
oAQ0CXCMYgsE59HUOO05xFLazGxNh2epPADTbTTgoNQ9py38evlW254okhRmk9p9
v4i1yTzuv/Y6C0qw2RZcEiT/GTdvajkMKCidLEm3LbY=
=W/Ke
-----END PGP SIGNATURE-----