From: Eric Voskuil <eric@voskuil•org>
To: Chaofan Li <li3939108@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Blockchain Voluntary Fork (Split) Proposal (Chaofan Li)
Date: Mon, 22 Jan 2018 20:57:46 -0800 [thread overview]
Message-ID: <16b2ea77-3ff5-81b1-d3d7-a7107f4b37fc@voskuil.org> (raw)
In-Reply-To: <CANZDnNoGnab6HYESA0oOL-8Q8HtR1Ns0AfP3KNEmwU6KN5W5pA@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2234 bytes --]
On 01/22/2018 04:38 PM, Chaofan Li via bitcoin-dev wrote:
> Miners are most likely to be equally distributed between the two almost
> same chains.
This is irrelevant as miners don't determine the utility of a money,
they anticipate it. However you don't have to accept this to recognize
the error of the argument below...
> If one chain is faster, according to the difficulty adjustment scheme,
> it will become more difficult to mine.
Mining difficulty controls the block period, not miner return on capital.
> The two chain should have similar chain generation rates with similar
> difficulty and similar length.
This is the consequence of the presumed common regulation of the block
period. It matters not how useful are either of the monies.
> or the miners will be attracted to the chain easier to mine,
> and more miners will make the chain generation rate increase and then,
> after difficulty adjustment, harder to mine.
You are conflating difficulty with profitability. These are not the same
thing. A chain can be more difficult and less profitable and the
reverse. Profitability is controlled by competition, as it is in all
markets. Competition is controlled by the cost of capital, which is in
turn controlled by time preference. Mining seeks the same level of
profitability for any coin, regardless of how difficultly. This applies
to all industry - difficulty does not regulate profit, it's just a cost.
> Equilibrium will be achieved.> All the above are based on one assumption: the two chains have the same
> value initially or miners believe they will have the same value finally.
Actually the opposite is the case. Even if we could start at a point of
perfect equality, the smallest change in the number of merchants or
human perception of the money (as examples), would lead one to be
slightly better. All things being equal that alone would lead to
elimination of one money in favor of the other.
One money is inherently better than two, as there is an exchange cost
between them. In the absence of exchange controls the better money gets
used, and in this case that can simply be the result of a slightly
larger network (or perception of it).
e
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
next prev parent reply other threads:[~2018-01-23 4:57 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-23 0:38 Chaofan Li
2018-01-23 4:57 ` Eric Voskuil [this message]
2018-01-23 5:47 ` Chaofan Li
2018-01-30 5:32 ` ZmnSCPxj
2018-01-30 6:20 ` Chaofan Li
[not found] <CALTsm7iyJjQa5rkddZj2jL_BTdGxH+6Xz78Rt0wOqW1OveecHw@mail.gmail.com>
[not found] ` <CALTsm7gQC8RejAhmobzejEoU4T7xLf77Ykk2m0p=Z2=oM2p0Uw@mail.gmail.com>
2018-01-22 19:01 ` Ilan Oh
2018-01-22 19:59 ` Mark Friedenbach
2018-01-22 22:52 ` Eric Voskuil
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=16b2ea77-3ff5-81b1-d3d7-a7107f4b37fc@voskuil.org \
--to=eric@voskuil$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=li3939108@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