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
0xB2E60C73.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev