public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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


  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 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$(echo .)org \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=tomz@freedommail$(echo .)ch \
    /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