What is Nostr?
Tier Nolan [ARCHIVE] /
npub1g6vā€¦l5wd
2023-06-07 17:47:01
in reply to nevent1qā€¦k8vr

Tier Nolan [ARCHIVE] on Nostr: šŸ“… Original date posted:2015-12-20 šŸ“ Original message:On Sun, Dec 20, 2015 at ...

šŸ“… Original date posted:2015-12-20
šŸ“ Original message:On Sun, Dec 20, 2015 at 12:42 PM, Natanael <natanael.l at gmail.com> wrote:

> If total difficulty is X and the ratio for full blocks to candidate blocks
> shared with the pool is Y, then the candidate block PoW now has to meet X/Y
> while hashing the candidate block PoW + the pool's commitment hash must
> meet Y, which together makes for X/Y*Y and thus the same total difficulty.


This gives the same total difficulty but miners are throwing away otherwise
valid blocks.

This means that it is technically a soft fork. All new blocks are valid
according to the old rule.

In practice, it is kind of a hard fork. If Y is 10, then all upgraded
miners are throwing away 90% of the blocks that are valid under the old
rules.

>From the perspective of non-upgraded clients, the upgraded miners operate
at a 10X disadvantage.

This means that someone with 15% of the network power has a majority of the
effective hashing power, since 15% is greater than 8.5% (85% * 0.1).

The slow roll-out helps mitigate this though. It gives non-upgraded
clients time to react. If there is only a 5% difference initially, then
the attacker doesn't get much benefit.

The main differences are that there's a public key identifier the miners
> are told about in advance and expect to see in block templates, and that
> that now the pool has to publish this commitment value together with the
> block that also contains the commitment hash, and that this is verified
> together with the PoW.


I don't think public keys are strictly required. Registering them with
DNSSEC is way over the top. They can just publish the key on their website
and then use that for their identity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151220/d23c9ae8/attachment.html>;
Author Public Key
npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wd