public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Tom Zander <tomz@freedommail.ch>
To: bitcoin-dev@lists.linuxfoundation.org, Gareth Williams <gjw@posteo.net>
Subject: Re: [bitcoin-dev] Moving towards user activated soft fork activation
Date: Tue, 07 Mar 2017 10:17:18 +0100	[thread overview]
Message-ID: <9086552.5NYgjOP6f4@strawberry> (raw)
In-Reply-To: <964E4801-234F-4E30-A040-2C63274D27F2@posteo.net>

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


  parent reply	other threads:[~2017-03-07  9:14 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 [this message]
2017-03-07 18:13             ` Eric Voskuil
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=9086552.5NYgjOP6f4@strawberry \
    --to=tomz@freedommail.ch \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=gjw@posteo.net \
    /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