Adam Back [ARCHIVE] on Nostr: 📅 Original date posted:2017-09-15 📝 Original message:True however in principle ...
📅 Original date posted:2017-09-15
📝 Original message:True however in principle a soft-fork can also be soft-forked out. Eg say a
publicly known soft-fork done by miners only that user node software did
not upgrade for first by opt-in adoption. If there was consensus against by
users and ecosystem a node/user flag day soft fork could block it's
effects. Or if a soft fork was determined to have a major bug.
However most types of soft fork are opt-in and so mostly that situation
seems unlikely. A censorship soft-fork is harder, that's a standard
hard-fork to bypass with current fungibility mechanisms.
Adam
On Sep 15, 2017 08:12, "ZmnSCPxj via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170915/6bfa793b/attachment.html>;
📝 Original message:True however in principle a soft-fork can also be soft-forked out. Eg say a
publicly known soft-fork done by miners only that user node software did
not upgrade for first by opt-in adoption. If there was consensus against by
users and ecosystem a node/user flag day soft fork could block it's
effects. Or if a soft fork was determined to have a major bug.
However most types of soft fork are opt-in and so mostly that situation
seems unlikely. A censorship soft-fork is harder, that's a standard
hard-fork to bypass with current fungibility mechanisms.
Adam
On Sep 15, 2017 08:12, "ZmnSCPxj via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170915/6bfa793b/attachment.html>;