From: "Jorge Timón" <jtimon@jtimon.cc>
To: Allen Piscitello <allen.piscitello@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Is it possible for there to be two chains after a hard fork?
Date: Wed, 30 Sep 2015 18:14:42 +0200 [thread overview]
Message-ID: <CABm2gDrNLhV-B_+BCFj5FbTZkTuFctTMQZSV45rQAGK8eGbHmg@mail.gmail.com> (raw)
In-Reply-To: <CAJfRnm4xNozyynxoTQS25FTCcOw_hwfFfV1V-mVfq+qZ+Q8jVQ@mail.gmail.com>
Gavin, you assume that users must necessarily always follow the
hashrate majority, but this is not true.
In fact, it is the opposite: market forces make the hashrate follow the users.
Not following the hashrate majority is not necessarily insane.
If some users aren't happy with the new hardfork rules, they may never
upgrade. This is discussed (although I want to improve the text) under
the "Schism hardforks" section of BIP99 (which you may have some
complaints against, so please review
https://github.com/bitcoin/bips/pull/181/files#diff-e331b8631759a4ed6a4cfb4d10f473caR135
).
It is true that users of chain A may sell or their B-coins, but the
opposite is also true: users in chain B may sell all their A-coins.
Speculators will likely sell both and probably not buy again until the
initial uncertainty is gone (or they may never buy again, nobody can
predict this).
Let's use an example. Let's assume that a hardfork is rolled out to
completely remove the blocksize limit (I believe you would be against
that from previous conversations with you).
As long as there are users creating demand for the old-coins, there
will be miners mining the old coins.
This is not insane for neither users or miners no matter how big the
majority of users and/or miners in the new rules chain.
Again, probably the best place to discuss this kind of thing is
https://github.com/bitcoin/bips/pull/181 or the bitcoin-dev thread
linked from the BIP (
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008936.html
).
On Tue, Sep 29, 2015 at 8:23 PM, Allen Piscitello via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>>I started this thread as a sanity check on myself, because I keep seeing
>> smart people saying that two chains could persist for more than a few days
>> after a hard fork, and I still don't see how that would possibly work.
>
> When you start with the assumption that anyone who disagrees with you is
> insane or crazy, I can see why you have such difficulty.
>
>
> On Tue, Sep 29, 2015 at 1:01 PM, Gavin Andresen <gavinandresen@gmail.com>
> wrote:
>>
>> We really shouldn't have to go over "Bitcoin 101" on this mailing list,
>> and this discussion should move to the not-yet-created more general
>> discussion list. I started this thread as a sanity check on myself, because
>> I keep seeing smart people saying that two chains could persist for more
>> than a few days after a hard fork, and I still don't see how that would
>> possibly work.
>>
>> So: "fraud" would be 51% miners sending you bitcoin in exchange for
>> something of value, you wait for confirmations and send them that something
>> of value, and then the 51% reverses the transaction.
>>
>> Running a full node doesn't help.
>>
>> On Tue, Sep 29, 2015 at 1:55 PM, Allen Piscitello
>> <allen.piscitello@gmail.com> wrote:
>>>
>>> >A dishonest miner majority can commit fraud against you, they can mine
>>> > only empty blocks, they can do various other things that render your money
>>> > worthless.
>>>
>>> Mining empty blocks is not fraud.
>>>
>>> If you want to use terms like "honest miners" and "fraud", please define
>>> them so we can at least be on the same page.
>>>
>>> I am defining an honest miner as one that follows the rules of the
>>> protocol. Obviously your definition is different.
>>>
>>> On Tue, Sep 29, 2015 at 12:51 PM, Mike Hearn <hearn@vinumeris.com> wrote:
>>>>>
>>>>> >because Bitcoin's basic security assumption is that a supermajority of
>>>>> > miners are 'honest.'
>>>>>
>>>>> Only if you rely on SPV.
>>>>
>>>>
>>>> No, you rely on miners honesty even if you run a full node. This is in
>>>> the white paper. A dishonest miner majority can commit fraud against you,
>>>> they can mine only empty blocks, they can do various other things that
>>>> render your money worthless.
>>>
>>>
>>
>>
>>
>> --
>> --
>> Gavin Andresen
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
next prev parent reply other threads:[~2015-09-30 16:14 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-29 14:04 [bitcoin-dev] Is it possible for there to be two chains after a hard fork? Gavin Andresen
2015-09-29 14:17 ` Jonathan Toomim (Toomim Bros)
2015-09-29 14:59 ` Mark Friedenbach
2015-09-29 17:24 ` Allen Piscitello
2015-09-29 17:35 ` Gavin Andresen
2015-09-29 17:43 ` Allen Piscitello
2015-09-29 17:51 ` Mike Hearn
2015-09-29 17:55 ` Allen Piscitello
2015-09-29 18:01 ` Gavin Andresen
2015-09-29 18:23 ` Allen Piscitello
2015-09-30 16:14 ` Jorge Timón [this message]
2015-09-29 18:02 ` Mike Hearn
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=CABm2gDrNLhV-B_+BCFj5FbTZkTuFctTMQZSV45rQAGK8eGbHmg@mail.gmail.com \
--to=jtimon@jtimon.cc \
--cc=allen.piscitello@gmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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