From: Jimmy Song <jaejoon@gmail•com>
To: Pavel Moravec <pavel.moravec@braiins•cz>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] A Small Modification to Segwit
Date: Sat, 8 Apr 2017 09:35:30 -0500 [thread overview]
Message-ID: <CAJR7vkrn-oFium3wFgcOdqNPuYq+rW2DqyOnkDaCTHabO0y3Xg@mail.gmail.com> (raw)
In-Reply-To: <CACDYSUROutAMV7C8pUXz0PMvH5awkw-XUtce7BxTtZMD_yUm5A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2636 bytes --]
Pavel,
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.
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.
In other words, the question isn't about allowing/disallowing ASICBoost at
this point. The question is whether we want ASICBoost open or hidden.
> 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.
>
This would only be the case if overt ASICBoost were not possible at all. It
is currently possible to use overt ASICBoost, so optimizations based on
overt ASICBoost would also be possible unless something were done to
actively block 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.
Market incentives, I would imagine. How quickly that would be is not
something I'm qualified to answer.
> 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.
>
I'm not adding support as much as explicitly allowing what's implicitly
allowed. Whatever risks you imagine for this proposal exist on the network
currently, with unmodified BIP-141 and with modified BIP-141. The
difference in adding the modification is that overt ASICBoost is explicitly
allowed in the modified BIP-141 as to not hide it.
Jimmy
[-- Attachment #2: Type: text/html, Size: 3768 bytes --]
next prev parent reply other threads:[~2017-04-08 14:35 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
2017-04-08 14:35 ` Jimmy Song [this message]
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=CAJR7vkrn-oFium3wFgcOdqNPuYq+rW2DqyOnkDaCTHabO0y3Xg@mail.gmail.com \
--to=jaejoon@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=pavel.moravec@braiins$(echo .)cz \
/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