📅 Original date posted:2017-09-15
📝 Original message: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 at lists.linuxfoundation.org
>> To: Bitcoin Protocol Discussion <bitcoin-dev at 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 at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xB2E60C73.asc
Type: application/pgp-keys
Size: 15541 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170915/56ee44a1/attachment-0001.bin>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 898 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170915/56ee44a1/attachment-0001.sig>;
Simone Bronzini [ARCHIVE] /
npub1eu…6244x
2023-06-07 18:06:01
in reply to nevent1q…xqq9
Author Public Key
npub1eutgkshv9qrfk005wypygy20svrhkz0f8sjnxp95pjm8y7ptxv4q96244xPublished at
2023-06-07 18:06:01Event JSON
{
"id": "0b83de51324f3dde8fba7d86b7444d8b3ba88f30ba932d83c65f999bc3fd793f",
"pubkey": "cf168b42ec28069b3df4710244114f83077b09e93c253304b40cb672782b332a",
"created_at": 1686161161,
"kind": 1,
"tags": [
[
"e",
"91d6ec02934746fcbd43013df1b7508b93012bf45b887171ea0d0bbaa6dee098",
"",
"root"
],
[
"e",
"8b0a9f19a6f7b62e1a9f13087624820daf586bd81a8f27395412e205a9ec48b5",
"",
"reply"
],
[
"p",
"bee276d1ae3341411bf36280d4da29fe701581dff23dcd2a5d7ac65535f7d8f9"
]
],
"content": "📅 Original date posted:2017-09-15\n📝 Original message:Since a soft-fork is a restriction of the consensus rules, I think the\nonly way to have an un-soft-forkable cryptocurrency is creating a\ncryptocurrency where no transaction is valid.\n\nImagine I build a very minimal cryptocurrency where in the transaction\noutput you only indicate the public key to send your coins to and the\namount. One can still soft-fork it by deciding that, from now on, only\neven amounts are valid or only public keys that are a multiple of 10 are\nvalid.\n\n\nOn 15/09/17 21:55, Dan Libby via bitcoin-dev wrote:\n\u003e Ok, this is good stuff. thanks for the thoughtful reply.\n\u003e\n\u003e Regarding anyone-can-spend:\n\u003e\n\u003e all of the examples you gave do not satisfy isStandard. So if our\n\u003e hypothetical cryptocurrency were to restrict all transactions to\n\u003e isStandard at the consensus layer, would that not effectively prevent\n\u003e anyone-can-spend?\n\u003e\n\u003e Or more generally and with our thinking caps on, what would be the best\n\u003e way to prevent anyone-can-spend, if that is our goal?\n\u003e\n\u003e\n\u003e Regarding soft-fork = restrict:\n\u003e\n\u003e Your example of miners running secret soft-fork code that blacklists\n\u003e satoshi's utxo's is intriguing and somewhat troubling.\n\u003e\n\u003e I think the main takeaways are that:\n\u003e 1) there are other ways to soft-fork besides anyone-can-spend.\n\u003e 2) it is impossible to prevent hidden soft-forks.\n\u003e\n\u003e Is that accurate?\n\u003e\n\u003e Still, I would put forth the following question: If anyone-can-spend tx\n\u003e were no longer allowed according to consensus rules (assuming that is\n\u003e possible/practical), then could the network still be practically\n\u003e \"upgraded\" with new features (eg opcodes) via soft-fork, and if so, what\n\u003e would be the mechanism for backwards compatibility in this scenario?\n\u003e\n\u003e\n\u003e or from another angle: even if it is impossible to prevent all\n\u003e soft-forks, can you see any way at all to make it logistically\n\u003e infeasible to use soft-forks as a network-wide consensus change mechanism?\n\u003e\n\u003e and another thought: as I understand it, bitcoin is presently able to\n\u003e add new opcodes via soft-fork because Satoshi added 10 unused opcodes\n\u003e via hardfork. What will happen when these run out? Can new opcodes\n\u003e still be added without a hard-fork?\n\u003e\n\u003e\n\u003e note: I ask these questions with the goal/vision of creating an\n\u003e immutable altcoin or sidechain, not necessarily restricting bitcoin's path.\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e On 09/14/2017 09:01 PM, ZmnSCPxj wrote:\n\u003e\u003e Good morning Dan,\n\u003e\u003e\n\u003e\u003e My understanding is that it is impossible for soft forks to be prevented.\n\u003e\u003e\n\u003e\u003e 1. Anyone-can-spend\n\u003e\u003e\n\u003e\u003e There are a very large number of anyone-can-spend scripts, and it would\n\u003e\u003e be very impractical to ban them all.\n\u003e\u003e\n\u003e\u003e For example, the below output script is anyone-can-spend\n\u003e\u003e\n\u003e\u003e \u003crandom number\u003e OP_TRUE\n\u003e\u003e\n\u003e\u003e So is the below:\n\u003e\u003e\n\u003e\u003e OP_SIZE \u003crandom small number\u003e OP_EQUAL\n\u003e\u003e\n\u003e\u003e Or:\n\u003e\u003e\n\u003e\u003e OP_1ADD \u003crandom number\u003e OP_EQUAL\n\u003e\u003e\n\u003e\u003e Or:\n\u003e\u003e\n\u003e\u003e OP_BOOLAND\n\u003e\u003e\n\u003e\u003e Or:\n\u003e\u003e\n\u003e\u003e OP_BOOLOR\n\u003e\u003e\n\u003e\u003e And so on.\n\u003e\u003e\n\u003e\u003e So no, it is not practically possible to ban anyone-can-spend outputs,\n\u003e\u003e as there are too many potential scriptPubKey that anyone can spend.\n\u003e\u003e\n\u003e\u003e It is even possible to have an output that requires a proof-of-work,\n\u003e\u003e like so:\n\u003e\u003e\n\u003e\u003e OP_HASH256 \u003cdifficulty target\u003e OP_LESSTHAN\n\u003e\u003e\n\u003e\u003e All the above outputs are disallowed from propagation by IsStandard, but\n\u003e\u003e a miner can put them validly in a block, and IsStandard is not consensus\n\u003e\u003e code and can be modified.\n\u003e\u003e\n\u003e\u003e 2. Soft fork = restrict\n\u003e\u003e\n\u003e\u003e It is possible (although unlikely) for a majority of miners to run soft\n\u003e\u003e forking code which the rest of us are not privy to.\n\u003e\u003e\n\u003e\u003e For example, for all we know, miners are already blacklisting spends on\n\u003e\u003e Satoshi's coins. We would not be able to detect this at all, since no\n\u003e\u003e transaction that spends Satoshi's coins have been broadcast, ever. It\n\u003e\u003e is thus indistinguishable from a world where Satoshi lost his private\n\u003e\u003e keys. Of course, the world where Satoshi never spent his coins and\n\u003e\u003e miners are blacklisting Satoshi's coins, is more complex than the world\n\u003e\u003e where Satoshi never spent his coins, so it is more likely that miners\n\u003e\u003e are not blacklisting.\n\u003e\u003e\n\u003e\u003e But the principle is there. We may already be in a softfork whose rules\n\u003e\u003e we do not know, and it just so happens that all our transactions today\n\u003e\u003e do not violate those rules. It is impossible for us to know this, but\n\u003e\u003e it is very unlikely.\n\u003e\u003e\n\u003e\u003e Soft forks apply further restrictions on Bitcoin. Hard forks do not. \n\u003e\u003e Thus, if everyone else is entering a soft fork and we are oblivious, we\n\u003e\u003e do not even know about it. Whereas, if everyone else is entering a hard\n\u003e\u003e fork, we will immediately see (and reject) invalid transactions and blocks.\n\u003e\u003e\n\u003e\u003e Thus the only way to prevent soft fork is to hard fork against the new\n\u003e\u003e soft fork, like Bcash did.\n\u003e\u003e\n\u003e\u003e Regards,\n\u003e\u003e ZmnSCPxj\n\u003e\u003e\n\u003e\u003e -------- Original Message --------\n\u003e\u003e Subject: [bitcoin-dev] hypothetical: Could soft-forks be prevented?\n\u003e\u003e Local Time: September 13, 2017 5:50 PM\n\u003e\u003e UTC Time: September 13, 2017 9:50 AM\n\u003e\u003e From: bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e To: Bitcoin Protocol Discussion \u003cbitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e\u003e\n\u003e\u003e Hi, I am interested in the possibility of a cryptocurrency software\n\u003e\u003e (future bitcoin or a future altcoin) that strives to have immutable\n\u003e\u003e consensus rules.\n\u003e\u003e\n\u003e\u003e The goal of such a cryptocurrency would not be to have the latest and\n\u003e\u003e greatest tech, but rather to be a long-term store of value and to offer\n\u003e\u003e investors great certainty and predictability... something that markets\n\u003e\u003e tend to like. And of course, zero consensus rule changes also means\n\u003e\u003e less chance of new bugs and attack surface remains the same, which is\n\u003e\u003e good for security.\n\u003e\u003e\n\u003e\u003e Of course, hard-forks are always possible. But that is a clear split\n\u003e\u003e and something that people must opt into. Each party has to make a\n\u003e\u003e choice, and inertia is on the side of the status quo. Whereas\n\u003e\u003e soft-forks sort of drag people along with them, even those who oppose\n\u003e\u003e the changes and never upgrade. In my view, that is problematic,\n\u003e\u003e especially for a coin with permanent consensus rule immutability as a\n\u003e\u003e goal/ethic.\n\u003e\u003e\n\u003e\u003e As I understand it, bitcoin soft-forks always rely on anyone-can-spend\n\u003e\u003e transactions. If those were removed, would it effectively prevent\n\u003e\u003e soft-forks, or are there other possible mechanisms? How important are\n\u003e\u003e any-one-can spend tx for other uses?\n\u003e\u003e\n\u003e\u003e More generally, do you think it is possible to programmatically\n\u003e\u003e avoid/ban soft-forks, and if so, how would you go about it?\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: 0xB2E60C73.asc\nType: application/pgp-keys\nSize: 15541 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170915/56ee44a1/attachment-0001.bin\u003e\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 898 bytes\nDesc: OpenPGP digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170915/56ee44a1/attachment-0001.sig\u003e",
"sig": "d539d7343b16471407e99275e81bd43a87913433b44b6fb158dad9b4de94145900513cc8db7a2da9975dfdaec60a479532676bdf98d178e9cb4eccf288693d24"
}