From: Eric Voskuil <eric@voskuil.org>
To: Tom Zander <tomz@freedommail.ch>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Moving towards user activated soft fork activation
Date: Tue, 7 Mar 2017 10:13:36 -0800 [thread overview]
Message-ID: <08254322-D7BC-4BF8-ACB2-189588D93325@voskuil.org> (raw)
In-Reply-To: <9086552.5NYgjOP6f4@strawberry>
> Bitcoin would lose the security and in the short term even the ability to
mine blocks every 10 minutes.
Presumably a POW hard fork would be accompanied by a difficulty reset, so that the deployment didn't have *both* of these problems from the outset. There's really little difference between 10 minutes at little/no security and zero conf. See testnet. But people might feel better about still seeing blocks.
But in any case it's not clear to me why you assume a loss of security in the "short term" is something that can be overcome. The short term can presumably prevent the long term from ever becoming.
e
> On Mar 7, 2017, at 1:17 AM, Tom Zander via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On Tuesday, 7 March 2017 00:23:47 CET Gareth Williams via bitcoin-dev wrote:
>> What you're describing is a hashpower activated soft fork to censor
>> transactions, in response to a user activated soft fork that the majority
>> of hashpower disagrees with.
>
> It is incorrect to say that censoring of transactions is what Edmund
> suggested. It's purely about the form they take, you can re-send the
> transaction in a different form with the same content and they go through.
> Hence, not transaction censoring.
>
> I do believe the point that Edmund brought up is a very good one, the idea
> that a set of users can force the miners to do something is rather silly and
> the setup that a minority miner fraction can force the majority to do
> something is equally silly. This is because the majority mining hashpower
> can fight back against this attack upon them.
>
> Don’t be mistaken; a hash-minority attacking the hash-majority is in actual
> fact an attack upon Bitcoin as a whole.
> If this were possible then next year we’d see governments try to push
> through changes in the same UASF way. I’m very happy that UASFs can’t work
> because that would be the end of Bitcoin's freedom and decentralized nature.
>
>> It is always possible for a majority of hashpower to censor transactions
>> they disagree with. Users may view that as an attack, and can always
>> respond with a POW hard fork.
>
> I definitely welcome that approach.
>
> The result would be that you have two chains, but also you ensure that the
> chain that the miners didn’t like will no longer be something they can mine.
> Not even the minority set of miners that like the softfork can mine on it.
> This is a win-win and then the market will decide which one will "win".
>
>> Bitcoin only works if the majority of hashpower is not hostile to the
>> users.
>
> This goes both ways, miners both generate value (in the form of security)
> and they take value (in the form of inflation).
> If the majority of the users are hostile and reject blocks that the miners
> create, or change the POW, then what the miners bring to the table is also
> removed.
> Bitcoin would lose the security and in the short term even the ability to
> mine blocks every 10 minutes.
>
> So, lets correct your statement a little;
> «Bitcoin only works when the majority of the hashpower and the (economic)
> majority of the users are balanced in power and have their goals aligned.»
>
> --
> Tom Zander
> Blog: https://zander.github.io
> Vlog: https://vimeo.com/channels/tomscryptochannel
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
next prev parent reply other threads:[~2017-03-07 18:13 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-05 14:33 [bitcoin-dev] Moving towards user activated soft fork activation Chris Belcher
2017-03-05 18:10 ` David Vorick
2017-03-05 18:48 ` Eric Voskuil
2017-03-05 21:31 ` Nick ODell
2017-03-06 9:18 ` David Vorick
2017-03-06 10:29 ` Edmund Edgar
2017-03-06 23:23 ` Gareth Williams
2017-03-07 1:07 ` Edmund Edgar
2017-03-07 17:37 ` Eric Voskuil
2017-03-07 9:17 ` Tom Zander
2017-03-07 18:13 ` Eric Voskuil [this message]
2017-03-07 19:13 ` Alphonse Pace
-- strict thread matches above, loose matches on Subject: below --
2017-02-25 23:55 shaolinfry
2017-02-26 17:34 ` Jameson Lopp
2017-02-27 16:02 ` shaolinfry
2017-02-27 16:50 ` Eric Voskuil
2017-02-28 21:20 ` Luke Dashjr
2017-03-12 15:47 ` shaolinfry
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=08254322-D7BC-4BF8-ACB2-189588D93325@voskuil.org \
--to=eric@voskuil.org \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=tomz@freedommail.ch \
/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