Tier Nolan [ARCHIVE] on Nostr: 📅 Original date posted:2017-09-15 📝 Original message:On Fri, Sep 15, 2017 at ...
📅 Original date posted:2017-09-15
📝 Original message:On Fri, Sep 15, 2017 at 10:14 AM, Adam Back via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> 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.
>
It depends on what software that the general user-base is using (especially
exchanges). If a majority of miners have deployed a hidden soft fork, then
the soft fork will only last as long as they can maintain their majority.
If they drop below 50%, then the majority of miners will eventually make
and then build on a block that is invalid according to their hidden soft
fork rules.
If the userbase doesn't support a censorship soft fork, then it will only
last as long as a majority of miners support it. Once the cartel loses its
majority, there is a strong incentive for members to disable their soft
fork rule. Any that don't will end up mining a lower POW, but valid, chain.
Users updating their nodes to enforce the soft fork is what makes the soft
fork irreversible (without a hard fork).
> A censorship soft-fork is harder, that's a standard hard-fork to bypass
> with current fungibility mechanisms.
>
It's only a hard fork to reverse if the community is enforcing the soft
fork. Forking off a minority of miners doesn't make it a hard fork.
>
> 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
>>
>>
> _______________________________________________
> 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/05615e0f/attachment-0001.html>;
📝 Original message:On Fri, Sep 15, 2017 at 10:14 AM, Adam Back via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> 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.
>
It depends on what software that the general user-base is using (especially
exchanges). If a majority of miners have deployed a hidden soft fork, then
the soft fork will only last as long as they can maintain their majority.
If they drop below 50%, then the majority of miners will eventually make
and then build on a block that is invalid according to their hidden soft
fork rules.
If the userbase doesn't support a censorship soft fork, then it will only
last as long as a majority of miners support it. Once the cartel loses its
majority, there is a strong incentive for members to disable their soft
fork rule. Any that don't will end up mining a lower POW, but valid, chain.
Users updating their nodes to enforce the soft fork is what makes the soft
fork irreversible (without a hard fork).
> A censorship soft-fork is harder, that's a standard hard-fork to bypass
> with current fungibility mechanisms.
>
It's only a hard fork to reverse if the community is enforcing the soft
fork. Forking off a minority of miners doesn't make it a hard fork.
>
> 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
>>
>>
> _______________________________________________
> 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/05615e0f/attachment-0001.html>;