On 7 March 2017 at 08:23, Gareth Williams 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.
Well, they'd be censoring transactions to prevent the thing from
acti
On 6 March 2017 at 18:18, David Vorick via bitcoin-dev
wrote:
> User activated soft forks, or perhaps more accurately called 'economically
> forced soft forks' are a tool to use if the miners are in clear opposition
> to the broader economy.
I don't think they work for that, at least not for new
On 26 January 2017 at 18:20, Johnson Lau via bitcoin-dev
wrote:
>You can’t anti-replay if you don’t even know a hardfork might happen. And I
>think your hypothesis (replay reduces the incentive of split) is not supported
>by the ETC/ETH split.
I agree with the general point you're making, but y
On 30 November 2016 at 05:56, Erland Lewin via bitcoin-dev
wrote:
> This proposal describes a consistent way to create s type of p2sh addresses
> (“Boolean addresses”) which can be redeemed by an arbitrary set of keys and
> multi signatures combined with logical and/or operations.
From our point
> So to point out what I consider obvious: if Bitcoin requires central
> control over its rules by a group of developers, it is completely
> uninteresting to me. Consensus changes should be done using consensus, and
> the default in case of controversy is no change.
This is a really interesting th
