📅 Original date posted:2015-08-04
📝 Original message:> On 4 Aug 2015, at 14:30, Gavin Andresen <gavinandresen at gmail.com> wrote:
>
> On Tue, Aug 4, 2015 at 2:41 PM, Dave Hudson via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto: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....
Yes, but the block maker won't publish the second block it finds for the same set of transactions. It won't orphan its own block. In fact even if it does it still doesn't matter because the block maker still gets the block reward irrespective of which of the two solutions are published.
It's not about which hash wins, the issue is who gets paid as a result.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150804/f8ac9aae/attachment.html>;
Dave Hudson [ARCHIVE] /
npub1re…679nu
2023-06-07 17:32:49
in reply to nevent1q…hctw
Author Public Key
npub1re22dhneg8azw7z3979njqn2sp4gxzp4703g62tsrvmsvnj76heqj679nuPublished at
2023-06-07 17:32:49Event JSON
{
"id": "6ef3cdf5f09d8a4d523d24212fba349ba08c47dade8a04ab06ec9eecc9f41718",
"pubkey": "1e54a6de7941fa2778512f8b39026a806a830835f3e28d29701b37064e5ed5f2",
"created_at": 1686159169,
"kind": 1,
"tags": [
[
"e",
"2da2e00d8e383de13f6ee6d9d66f9da48994b834188a0ae47ea0319febd85ff5",
"",
"root"
],
[
"e",
"37388eebd6b4fbd6915abc80c202df08bedeef745527e75aeb75818f03c8f74f",
"",
"reply"
],
[
"p",
"22a868507215305fa476bdd2014ec70efeb69e47ad5116a1face0a0da1267495"
]
],
"content": "📅 Original date posted:2015-08-04\n📝 Original message:\u003e On 4 Aug 2015, at 14:30, Gavin Andresen \u003cgavinandresen at gmail.com\u003e wrote:\n\u003e \n\u003e On Tue, Aug 4, 2015 at 2:41 PM, Dave Hudson via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e wrote:\n\u003e Fundamentally a block maker (pool or aggregation of pools) does not orphan its own blocks.\n\u003e \n\u003e 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.\n\u003e \n\u003e 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....\n\nYes, but the block maker won't publish the second block it finds for the same set of transactions. It won't orphan its own block. In fact even if it does it still doesn't matter because the block maker still gets the block reward irrespective of which of the two solutions are published.\n\nIt's not about which hash wins, the issue is who gets paid as a result.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150804/f8ac9aae/attachment.html\u003e",
"sig": "ba71843e13aeccb032871cb7415536152ef0f8b076bc53daaf718a74fd48953a13c3b06eb83c2a8cb7a51778c27fbbeefe7688c12d6c184a12c2bced8f9177b8"
}