ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2017-09-15 📝 Original message:Good morning Dan, My ...
📅 Original date posted:2017-09-15
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170915/e6f45267/attachment.html>;
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170915/e6f45267/attachment.html>;