Re: [bitcoin-dev] hypothetical: Could soft-forks be prevented?

From: Simone Bronzini <simone.bronzini@chainside•net>
To: Dan Libby <dan@osc•co.cr>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>,
	ZmnSCPxj <ZmnSCPxj@protonmail•com>
Subject: Re: [bitcoin-dev] hypothetical: Could soft-forks be prevented?
Date: Fri, 15 Sep 2017 22:40:12 +0200	[thread overview]
Message-ID: <0c98e067-dff3-988b-af66-7c624de3eef4@chainside.net> (raw)
In-Reply-To: <9a541ba8-7c25-fdbb-505f-6426f61bdc63@osc.co.cr>

[-- Attachment #1.1.1: Type: text/plain, Size: 7037 bytes --]

Since a soft-fork is a restriction of the consensus rules, I think the
only way to have an un-soft-forkable cryptocurrency is creating a
cryptocurrency where no transaction is valid.

Imagine I build a very minimal cryptocurrency where in the transaction
output you only indicate the public key to send your coins to and the
amount. One can still soft-fork it by deciding that, from now on, only
even amounts are valid or only public keys that are a multiple of 10 are
valid.

On 15/09/17 21:55, Dan Libby via bitcoin-dev wrote:
> Ok, this is good stuff.  thanks for the thoughtful reply.
>
> Regarding anyone-can-spend:
>
> all of the examples you gave do not satisfy isStandard.  So if our
> hypothetical cryptocurrency were to restrict all transactions to
> isStandard at the consensus layer, would that not effectively prevent
> anyone-can-spend?
>
> Or more generally and with our thinking caps on, what would be the best
> way to prevent anyone-can-spend, if that is our goal?
>
>
> Regarding soft-fork = restrict:
>
> Your example of miners running secret soft-fork code that blacklists
> satoshi's utxo's is intriguing and somewhat troubling.
>
> I think the main takeaways are that:
>   1) there are other ways to soft-fork besides anyone-can-spend.
>   2) it is impossible to prevent hidden soft-forks.
>
> Is that accurate?
>
> Still, I would put forth the following question:  If anyone-can-spend tx
> were no longer allowed according to consensus rules (assuming that is
> possible/practical), then could the network still be practically
> "upgraded" with new features (eg opcodes) via soft-fork, and if so, what
> would be the mechanism for backwards compatibility in this scenario?
>
>
> or from another angle:  even if it is impossible to prevent all
> soft-forks, can you see any way at all to make it logistically
> infeasible to use soft-forks as a network-wide consensus change mechanism?
>
> and another thought:  as I understand it, bitcoin is presently able to
> add new opcodes via soft-fork because Satoshi added 10 unused opcodes
> via hardfork. What will happen when these run out?  Can new opcodes
> still be added without a hard-fork?
>
>
> note: I ask these questions with the goal/vision of creating an
> immutable altcoin or sidechain, not necessarily restricting bitcoin's path.
>
>
>
>
>
> On 09/14/2017 09:01 PM, ZmnSCPxj wrote:
>> Good morning Dan,
>>
>> My understanding is that it is impossible for soft forks to be prevented.
>>
>> 1.  Anyone-can-spend
>>
>> There are a very large number of anyone-can-spend scripts, and it would
>> be very impractical to ban them all.
>>
>> For example, the below output script is anyone-can-spend
>>
>>  <random number> OP_TRUE
>>
>> So is the below:
>>
>>   OP_SIZE <random small number> OP_EQUAL
>>
>> Or:
>>
>>   OP_1ADD <random number> OP_EQUAL
>>
>> Or:
>>
>>   OP_BOOLAND
>>
>> Or:
>>
>>   OP_BOOLOR
>>
>> And so on.
>>
>> So no, it is not practically possible to ban anyone-can-spend outputs,
>> as there are too many potential scriptPubKey that anyone can spend.
>>
>> It is even possible to have an output that requires a proof-of-work,
>> like so:
>>
>>  OP_HASH256 <difficulty target> OP_LESSTHAN
>>
>> All the above outputs are disallowed from propagation by IsStandard, but
>> a miner can put them validly in a block, and IsStandard is not consensus
>> code and can be modified.
>>
>> 2.  Soft fork = restrict
>>
>> It is possible (although unlikely) for a majority of miners to run soft
>> forking code which the rest of us are not privy to.
>>
>> For example, for all we know, miners are already blacklisting spends on
>> Satoshi's coins.  We would not be able to detect this at all, since no
>> transaction that spends Satoshi's coins have been broadcast, ever.  It
>> is thus indistinguishable from a world where Satoshi lost his private
>> keys.  Of course, the world where Satoshi never spent his coins and
>> miners are blacklisting Satoshi's coins, is more complex than the world
>> where Satoshi never spent his coins, so it is more likely that miners
>> are not blacklisting.
>>
>> But the principle is there.  We may already be in a softfork whose rules
>> we do not know, and it just so happens that all our transactions today
>> do not violate those rules.  It is impossible for us to know this, but
>> it is very unlikely.
>>
>> Soft forks apply further restrictions on Bitcoin.  Hard forks do not. 
>> Thus, if everyone else is entering a soft fork and we are oblivious, we
>> do not even know about it.  Whereas, if everyone else is entering a hard
>> fork, we will immediately see (and reject) invalid transactions and blocks.
>>
>> Thus the only way to prevent soft fork is to hard fork against the new
>> soft fork, like Bcash did.
>>
>> Regards,
>> ZmnSCPxj
>>
>> -------- Original Message --------
>> Subject: [bitcoin-dev] hypothetical: Could soft-forks be prevented?
>> Local Time: September 13, 2017 5:50 PM
>> UTC Time: September 13, 2017 9:50 AM
>> From: bitcoin-dev@lists•linuxfoundation.org
>> To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
>>
>> Hi, I am interested in the possibility of a cryptocurrency software
>> (future bitcoin or a future altcoin) that strives to have immutable
>> consensus rules.
>>
>> The goal of such a cryptocurrency would not be to have the latest and
>> greatest tech, but rather to be a long-term store of value and to offer
>> investors great certainty and predictability... something that markets
>> tend to like. And of course, zero consensus rule changes also means
>> less chance of new bugs and attack surface remains the same, which is
>> good for security.
>>
>> Of course, hard-forks are always possible. But that is a clear split
>> and something that people must opt into. Each party has to make a
>> choice, and inertia is on the side of the status quo. Whereas
>> soft-forks sort of drag people along with them, even those who oppose
>> the changes and never upgrade. In my view, that is problematic,
>> especially for a coin with permanent consensus rule immutability as a
>> goal/ethic.
>>
>> As I understand it, bitcoin soft-forks always rely on anyone-can-spend
>> transactions. If those were removed, would it effectively prevent
>> soft-forks, or are there other possible mechanisms? How important are
>> any-one-can spend tx for other uses?
>>
>> More generally, do you think it is possible to programmatically
>> avoid/ban soft-forks, and if so, how would you go about it?
>>
>>
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[-- Attachment #1.1.2: 0xB2E60C73.asc --]
[-- Type: application/pgp-keys, Size: 15783 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 898 bytes --]