Re: [bitcoin-dev] Moving towards user activated soft fork activation

[Gareth Williams via bitcoin-dev]

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 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. 

Bitcoin only works if the majority of hashpower is not hostile to the users.


On 6 March 2017 9:29:35 PM AEDT, Edmund Edgar via bitcoin-dev 
 wrote:
>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 features,
>because miners will presumably just head the whole thing off by
>orphaning the whole class of non-standard transactions that are the
>subject of the fork. In the SegWit case, they'd just orphan anything
>that looks like a SegWit transaction, valid or not. That way they
>don't need to worry about ending up on the wrong side of the upgrade,
>because no transaction affected by the proposed rule change will ever
>get into the longest chain. Rational node operators (particularly
>exchanges) will likely also adopt their stricter rule change, since
>they know any chain that breaks it will end up being orphaned, so you
>don't want to act on a payment that you see confirmed in it. So then
>you're back where you started, except that your soft-fork is now a
>de-facto hard-fork, because you have to undo the new, stricter rule
>that the miners introduced to head off your shenannigans.
>
>Where they're interesting is where you can do something meaningful by
>forcing some transactions through on a once-off basis. For example, if
>the Chinese government identified an address belonging to Uighur
>separatists and leaned on Chinese miners to prevent anything from that
>address confirming, it might be interesting for users to say, "If
>these utxos are not spent by block X, your block is invalid".
>
>They might also be interesting for feature upgrades in a world where
>mining is radically decentralized and upgrades are fighting against
>inertia rather than opposition, but sadly that's not the world we
>currently live in.

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Block size following technological growth

[Gareth Williams via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



On 4 August 2015 11:12:36 PM AEST, Gavin Andresen via bitcoin-dev 
bitcoin-dev@lists.linuxfoundation.org wrote:
On Tue, Aug 4, 2015 at 7:27 AM, Pieter Wuille via bitcoin-dev 
bitcoin-dev@lists.linuxfoundation.org wrote:

 I would say that things already demonstrately got terrible. The
mining
 landscape is very centralized, with apparently a majority depending
on
 agreements to trust each other's announced blocks without validation.

And that is a problem... why?

With all due respect Gavin, large-block advocates appear to hold the position 
that:
* pushing individual economic actors away from running full nodes is a natural 
and unproblematic consequence of block size increase, as they're expected to 
rely on SPV
You now also appear to hold the position that:
* pushing miners to SPV mining is unproblematic

Have I misunderstood? Is one of these not an expected outcome of large blocks? 
I can understand the validity of either argument alone -- the assertion that we 
can trust miners to validate and just trust most-POW ourselves, /or/ the 
assertion that lack of miner validation is safe under certain circumstances. 
But together?

Who do you expect to actually validate large blocks if not miners, and what do 
you expect their incentive to do so to be?

-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQFABAEBCgAqBQJVwcYAIxxHYXJldGggV2lsbGlhbXMgPGdhY3J1eEBnbWFpbC5j
b20+AAoJEEY5w2E3jkVEEWQH/Aty47q71H/ZcMMX/6qcTpOumI9h/buUfsvYA2H+
J6Al5S8JvCy3/0yMFCLmqolHoxOdWu5jwtUf/w2fepgA1RJyZItFo1EG9cJB0Cpz
JgM+2s4L/F3l4+Gea2ddjhvE5JqGS0Qh3EWaR/xy1bouq0FZjtDendmK7vFRj/oS
Gowm+g5EFBiT1XwCQQXJc9k0RxzDpPQ0ouSOXWdPUuxfQAjPyX89eQBeQzgVDtEf
zVfROZVHQuBu85rKTd32TdCNLQ0oEhAYmwgdtmJyLLgieeqHmNbaikBaVDEOvixn
S+fmnfD8CVeeXo5zKdlLZXazc5geRx97H4NMBMjTyjPzR5k=
=WG0I
-END PGP SIGNATURE-

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev