Re: [bitcoin-dev] Moving towards user activated soft fork activation
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] Bitcoin Core and hard forks
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
I've seen a lot of talk on this list debating the role of Bitcoin Core and its
maintainers WRT consensus, typically focused around whether they can
technically force anyone to run their code (of course, they can't.)
I've yet to see the discussion framed in terms of influence and leadership.
Which is why I want to highlight:
>I believe it is the responsibility of the maintainers/developers of
>Bitcoin
>Core to create software which helps guarantee the security and
>operation of
>the Bitcoin network
Perhaps s/helps guarantee/promotes/ , but this stands out as an excellent
description of Bitcoin Core's relationship to the Bitcoin network.
Defaults are powerful. Users technically /can/ compile and run any code they
like, but very few even bother to change configurable settings. They just want
a trusted brand ("Bitcoin Core") that does the right thing out of the box.
Bitcoin Core and its maintainers play a valuable /leadership/ role for the
network. Whether they can force people to run their code is uninteresting --
people trust them.
That trust is well earned, precisely because they have always promoted the
operation and security of the network.
In light of this responsibility it seems unreasonable for anyone to expect Core
maintainers to promote patches that endanger network consensus (e.g. user
configurable consensus parameters.)
Consensus is order of business #1. If we can't all agree to use the same money
then the grand experiment is resolved as a failure. Everyone has consensus
parameters they'd (strongly) prefer. Somebody needs to heard us all toward
using the same ones, sometimes even in the face of very high costs.
- -Gareth
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1
iQFABAEBCgAqBQJVsKPgIxxHYXJldGggV2lsbGlhbXMgPGdhY3J1eEBnbWFpbC5j
b20+AAoJEEY5w2E3jkVEZuEIAIKC9jTO33y4YC/cl1mO/+ux9YUqBlFUpuElKjNe
NLUIqPANrMV3nTjUm666Hk3tVHk8IpYLUU1pRuYBAT17d1t/2bFC4CpfpWssF9Nw
YhoYOKKVMvLUR4DRlkyhMD4YxorJ/TGiuEaFD4K/1s5uKf1+7Vj/BTi+SP+AIAIW
gTbn2CA3T4n8WjDYADE0dqcYSqzt2M1fjXB+Ld95JGLun8m+6lDPhFy/o5aGhBk6
5j86SITT9UtyyA6oaV5NNNgumcNBievnVwjTxjaWm8CBJlJ5jNpW65PQGkoSnCgz
TpYt/wZHcdSqBeNHyno9XaEBSm99Ylk3i2Z1dGQwrSsZU0Q=
=0pac
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP draft: Hardfork bit
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 >I don't understand the situation here. Is the assumption of a group of >miners suddenly switching (for example, they realise that they didn't >intend to support the new rules)? Or they're economically rational miners, and a large difficulty decrease on the original chain, without an equally large decrease in the value of original chain tokens, has made it profitable to switch? It's dangerous to assume all miners will continue to support the side they have initially signaled. They're only invested in the chain they mine for a short time (until coinbase maturity.) If both sides if a fork retain value you'd expect mining to redistribute itself WRT short term profitability at every difficulty adjustment, irrespective of initially signaled support for the fork. -BEGIN PGP SIGNATURE- Version: APG v1.1.1 iQFABAEBCgAqBQJVsZIuIxxHYXJldGggV2lsbGlhbXMgPGdhY3J1eEBnbWFpbC5j b20+AAoJEEY5w2E3jkVEN7YIAIlgaAahHCssIEXYzqB1gRKYRP4fPsq8NtOMrkki dc1gfKmprlPDShFvu2Hn5L8amP51ouRpmDSJwNyU//1DyU5p1tcWTAtkHr6SY7TY uJtcPMM03BUD2i3rXSY4FbpWn8aOoUnQrkYFhx5Y/Aru+l47C0I5KF4fgMag7FhI RxkTFylvq7uWvu0QCUkVh1MgohNxMqIGAvE5t8yoj5LxrNzOq95TcOGwFngWCdJM a5BADFjq7v4j/+cP748ZTPcLUusTQTwEuIsCIhpwwiKADsy1FKjmAdHhKTff/6wn cpNYvwimKNSSESCwzAnxekaJCTXpEOWQV7/6FO9vJbTMKw8= =/hJk -END PGP SIGNATURE- ___ 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 4 August 2015 11:12:36 PM AEST, Gavin Andresen via bitcoin-dev 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
