<unnamed>

Public Key

npub1a9hemj8hf6exprh5q6w8y70n9mm36h6pt5vlp2wtl9gjwfzaqjrqeuvwuq

Profile Code

nprofile1qqswjmuaerm5avnq3m6qd8rj08ejaacataq46x0s489lj5f8y3wsfpsprpmhxue69uhhyetvv9ujuumwdae8gtnnda3kjctvqy28wumn8ghj7un9d3shjtnyv9kh2uewd9hszrthwden5te0dehhxtnvdakq0d2928

Publishing to

relay.snort.social

relay.damus.io

nos.lol

Last Notes

2023-06-07 17:59:48 UTC

- reply

📅 Original date posted:2017-04-08
📝 Original message:Jimmy,
>> Until all miners update (firmware or hardware), the change encourages
>> large difference in mining efficiency. And IMO it gives another
>> advantage to large mining operations in general.
>
> Certainly, there would have to be changes for stratum, pool software, etc.
> But the monetary incentives align to all the changes needed.
I agree. I only wanted to make clear, that the impact would be
significant. Lot of parties would be involved with nonequivalent
starting positions.
> Remember, overt ASICBoost can get something like a 12.5% efficiency boost
> from toggling a single bit in the version (equivalent to 2 colliding work
> items), 18.5% from 2 bits (equivalent to 4 colliding work items), 23.4% from
> 4 bits (see https://arxiv.org/ftp/arxiv/papers/1604/1604.00575.pdf). In lieu
> of an explicit allowance of overt ASICBoost, the monetary incentives lead to
> odd BIP9 signaling, especially if 4 or more proposals signal at once. There
> really isn't a practical way to block overt ASICBoost without forcing the
> version bits to be some value.
You can e.g. place the version number into a coinbase, similarly to
block height. Then, it is the same (number of operations) as modifying
the coinbase directly.
A cost of version in coinbase is 4B per block, sure, but it allows to
save all bits for "more useful" purposes. Either for BIP9 signalling
or other future purposes I cannot see now. And it removes an incentive
to mess with version bits.
Mining empty blocks and finding collisions by toggling bits there can
be prevented as well.
> In other words, the question isn't about allowing/disallowing ASICBoost at
> this point. The question is whether we want ASICBoost open or hidden.
I think the ASICBoost can and should be prevented completely.
Pavel

2023-06-07 17:59:47 UTC

- reply

📅 Original date posted:2017-04-08
📝 Original message:> Second, we can make this change relatively quickly. Most of the Segwit testing stays valid and this change can be deployed relatively quickly.
It is true only for nodes software. Most of the world's mining
infrastructure (at least for pool mining) is not ready for such
change. Current version of Stratum protocol doesn't support block
version changing. A broad adoption would require:
- A new standard extension to the mining protocol (generally, we want
the hash rate to be free to change the used pool without efficiency
loss)
- Pool operators must change their software.
- All miners must update their firmware IF they have compatible
hardware (we know there is compatible hardware out there but
definitely not all of the currently used). The firmware can be changed
after the mining protocol extension is settled.
Until all miners update (firmware or hardware), the change encourages
large difference in mining efficiency. And IMO it gives another
advantage to large mining operations in general.
> But think of it this way, if some newer ASIC optimization comes up, would you rather have a non-ASICBoosted hash rate to defend with or an ASICBoosted hash rate? Certainly, the latter, being higher will secure the Bitcoin network better against newer optimizations.
You make a strong assumption that the new optimization is not
compatible with overt ASICBoost. If it is compatible, ASICBoost
doesn't help you with "defending against" the new optimization at all.
And it can be the case that the new optimization is based on ASICBoost
so you can make the situation "worse" by allowing it.
> Certainly, if only one company made use of the extra nonce space, they would have an advantage.
Can you explain why the reality should be significantly different? In
sufficiently near future.
> Is that patented in any jurisdiction, all jurisdictions or only certain jurisdictions? Would a patent granted for SHA256 in Swaziland be sufficient for Bitcoin to change the Proof of Work algorithm?
We don't have to deal with any such theoretical situation now. You
proposal goes in opposite direction, by adding support for patented
algorithm. I don't know myself what the possible legal implications
are (maybe only for a subset of miners) so I consider it as an
unnecessary risk. At least before some conclusive legal analysis says
differently.