From: Pavel Moravec <pavel.moravec@braiins•cz>
To: Jimmy Song <jaejoon@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] A Small Modification to Segwit
Date: Sat, 8 Apr 2017 08:33:01 +0000 [thread overview]
Message-ID: <CACDYSUROutAMV7C8pUXz0PMvH5awkw-XUtce7BxTtZMD_yUm5A@mail.gmail.com> (raw)
In-Reply-To: <CAJR7vkoq8Y_-fbdxN=--gF5wrGByr5oODc4FkTaCEvDSuP0whQ@mail.gmail.com>
> 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.
next prev parent reply other threads:[~2017-04-08 8:33 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-07 20:06 Jimmy Song
2017-04-08 0:05 ` Jimmy Song
2017-04-08 14:59 ` Luke Dashjr
2017-04-08 15:17 ` Jimmy Song
2017-04-08 16:05 ` Luke Dashjr
2017-04-08 16:16 ` Jimmy Song
2017-04-08 16:19 ` Timo Hanke
2017-04-08 1:48 ` praxeology_guy
2017-04-08 2:46 ` Jimmy Song
2017-04-08 8:33 ` Pavel Moravec [this message]
2017-04-08 14:35 ` Jimmy Song
2017-04-08 16:38 ` Pavel Moravec
2017-04-08 22:19 ` Jimmy Song
2017-04-08 18:15 ` praxeology_guy
2017-04-08 18:51 ` Eric Voskuil
2017-04-08 20:38 ` praxeology_guy
2017-04-09 11:46 ` Jorge Timón
2017-04-08 16:27 ` Jorge Timón
2017-04-08 17:22 ` Jorge Timón
2017-04-08 22:26 ` Jimmy Song
2017-04-09 11:48 ` Jorge Timón
2017-04-09 14:01 ` Jimmy Song
[not found] ` <CABm2gDqfsBREj2x5Uz9hxwt-Y6m=KHd2-hRw4gV0CbO+-8B0dg@mail.gmail.com>
2017-04-10 9:16 ` Jorge Timón
2017-04-09 18:44 ` Erik Aronesty
2017-04-09 21:16 ` Jared Lee Richardson
2017-04-09 23:51 ` David Vorick
2017-04-10 0:20 ` Erik Aronesty
2017-04-10 1:45 ` Thomas Daede
2017-04-10 14:34 ` Bram Cohen
2017-04-10 14:46 ` Bram Cohen
2017-04-10 15:25 ` g
2017-04-10 18:17 ` Erik Aronesty
2017-04-11 2:39 ` g
2017-04-11 18:39 ` Staf Verhaegen
2017-04-11 9:31 ` Sancho Panza
2017-04-11 13:00 ` Jorge Timón
2017-04-11 7:59 ` Tom Zander
2017-04-11 13:25 ` Sancho Panza
2017-04-11 14:40 ` Jimmy Song
2017-04-11 21:25 ` Jorge Timón
2017-04-11 23:42 ` Jimmy Song
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CACDYSUROutAMV7C8pUXz0PMvH5awkw-XUtce7BxTtZMD_yUm5A@mail.gmail.com \
--to=pavel.moravec@braiins$(echo .)cz \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jaejoon@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox