* Re: [bitcoin-dev] hypothetical: Could soft-forks be prevented? @ 2017-09-18 6:40 Daniel Wilczynski 0 siblings, 0 replies; 12+ messages in thread From: Daniel Wilczynski @ 2017-09-18 6:40 UTC (permalink / raw) To: bitcoin-dev Hi Dan. What might be better aim is to have built in wipeout protection? In softfork scenario this would protect a majority threatening a minority with a wipeout if they do not opt in to some soft-fork consensus change. This could be partly done done by having automoated consensus critical checkpoints, for example at 100 blocks deep. Maybe there are better ways? This would in effect turn softforks into hardforks. Regards, Daniel Wilczynski ^ permalink raw reply [flat|nested] 12+ messages in thread
* [bitcoin-dev] hypothetical: Could soft-forks be prevented?
@ 2017-09-13 9:50 Dan Libby
2017-09-15 4:01 ` ZmnSCPxj
[not found] ` <CADSvpf7sC-Rh0qoGKgagQV7Mo_BV6ymeadgfMzJ_oXPCTyJ6Mw@mail.gmail.com>
0 siblings, 2 replies; 12+ messages in thread
From: Dan Libby @ 2017-09-13 9:50 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
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?
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [bitcoin-dev] hypothetical: Could soft-forks be prevented? 2017-09-13 9:50 Dan Libby @ 2017-09-15 4:01 ` ZmnSCPxj 2017-09-15 9:14 ` Adam Back 2017-09-15 19:55 ` Dan Libby [not found] ` <CADSvpf7sC-Rh0qoGKgagQV7Mo_BV6ymeadgfMzJ_oXPCTyJ6Mw@mail.gmail.com> 1 sibling, 2 replies; 12+ messages in thread From: ZmnSCPxj @ 2017-09-15 4:01 UTC (permalink / raw) To: Dan Libby; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 3991 bytes --] 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 [-- Attachment #2: Type: text/html, Size: 5443 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] hypothetical: Could soft-forks be prevented? 2017-09-15 4:01 ` ZmnSCPxj @ 2017-09-15 9:14 ` Adam Back 2017-09-15 11:47 ` Tier Nolan 2017-09-15 20:01 ` Dan Libby 2017-09-15 19:55 ` Dan Libby 1 sibling, 2 replies; 12+ messages in thread From: Adam Back @ 2017-09-15 9:14 UTC (permalink / raw) To: Bitcoin Dev, ZmnSCPxj [-- Attachment #1: Type: text/plain, Size: 5037 bytes --] 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@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@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 > > [-- Attachment #2: Type: text/html, Size: 7190 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] hypothetical: Could soft-forks be prevented? 2017-09-15 9:14 ` Adam Back @ 2017-09-15 11:47 ` Tier Nolan 2017-09-15 20:01 ` Dan Libby 1 sibling, 0 replies; 12+ messages in thread From: Tier Nolan @ 2017-09-15 11:47 UTC (permalink / raw) To: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 6171 bytes --] On Fri, Sep 15, 2017 at 10:14 AM, Adam Back via bitcoin-dev < bitcoin-dev@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@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@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 >> >> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 9238 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] hypothetical: Could soft-forks be prevented? 2017-09-15 9:14 ` Adam Back 2017-09-15 11:47 ` Tier Nolan @ 2017-09-15 20:01 ` Dan Libby 1 sibling, 0 replies; 12+ messages in thread From: Dan Libby @ 2017-09-15 20:01 UTC (permalink / raw) To: adam, Bitcoin Dev, ZmnSCPxj On 09/15/2017 02:14 AM, Adam Back wrote: > However most types of soft fork are opt-in... my concern is that the community can be manipulated via political means. marketing, social media, payoffs, fud, etc, etc, etc. And essentially degrades to tyranny of the majority. So if there is any way to make opt-in forks impractical/infeasible for purpose of network wide consensus rule change, I'd love to hear it. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] hypothetical: Could soft-forks be prevented? 2017-09-15 4:01 ` ZmnSCPxj 2017-09-15 9:14 ` Adam Back @ 2017-09-15 19:55 ` Dan Libby 2017-09-15 20:40 ` Simone Bronzini 2017-09-16 3:38 ` ZmnSCPxj 1 sibling, 2 replies; 12+ messages in thread From: Dan Libby @ 2017-09-15 19:55 UTC (permalink / raw) To: ZmnSCPxj; +Cc: Bitcoin Protocol Discussion 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] hypothetical: Could soft-forks be prevented? 2017-09-15 19:55 ` Dan Libby @ 2017-09-15 20:40 ` Simone Bronzini 2017-09-15 21:48 ` Dan Libby 2017-09-16 1:42 ` Andrew Poelstra 2017-09-16 3:38 ` ZmnSCPxj 1 sibling, 2 replies; 12+ messages in thread From: Simone Bronzini @ 2017-09-15 20:40 UTC (permalink / raw) To: Dan Libby, Bitcoin Protocol Discussion, ZmnSCPxj [-- Attachment #1.1.1: Type: text/plain, Size: 7037 bytes --] 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 [-- Attachment #1.1.2: 0xB2E60C73.asc --] [-- Type: application/pgp-keys, Size: 15783 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 898 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] hypothetical: Could soft-forks be prevented? 2017-09-15 20:40 ` Simone Bronzini @ 2017-09-15 21:48 ` Dan Libby 2017-09-16 1:42 ` Andrew Poelstra 1 sibling, 0 replies; 12+ messages in thread From: Dan Libby @ 2017-09-15 21:48 UTC (permalink / raw) To: Simone Bronzini, Bitcoin Protocol Discussion, ZmnSCPxj On 09/15/2017 01:40 PM, Simone Bronzini wrote: > 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. sure, but in this scenario how would one meaningfully "upgrade" the functionality, eg add a new opcode? We couldn't, right? so.... success! Preventing new functionality is the primary goal of this thought experiment. I believe that common sense and market incentives would prevent arbitrary tightening of the rules for no good reason... ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] hypothetical: Could soft-forks be prevented? 2017-09-15 20:40 ` Simone Bronzini 2017-09-15 21:48 ` Dan Libby @ 2017-09-16 1:42 ` Andrew Poelstra 1 sibling, 0 replies; 12+ messages in thread From: Andrew Poelstra @ 2017-09-16 1:42 UTC (permalink / raw) To: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 948 bytes --] On Fri, Sep 15, 2017 at 10:40:12PM +0200, Simone Bronzini via bitcoin-dev wrote: > 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. > Even this can be soft-forked to add an extension block that contains transactions :) Ultimately I think the best you can do in this direction is to design for maximal fungibility and/or transaction structures that minimize interaction with the blockchain. This minimizes the surface for transaction censorship, which is somewhat in the spirit of your goal. -- Andrew Poelstra Mathematics Department, Blockstream Email: apoelstra at wpsoftware.net Web: https://www.wpsoftware.net/andrew "A goose alone, I suppose, can know the loneliness of geese who can never find their peace, whether north or south or west or east" --Joanna Newsom [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 455 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] hypothetical: Could soft-forks be prevented? 2017-09-15 19:55 ` Dan Libby 2017-09-15 20:40 ` Simone Bronzini @ 2017-09-16 3:38 ` ZmnSCPxj 1 sibling, 0 replies; 12+ messages in thread From: ZmnSCPxj @ 2017-09-16 3:38 UTC (permalink / raw) To: Dan Libby; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 7517 bytes --] Good Morning Dan, No. Let us suppose that IsStandard is applied to outputs, but we support P2SH. Then we could encode those scripts in P2SH. The softfork could require the script preimageto be put elsewhere, such as an OP_RETURN in the same tx, to determine the script that is anyone can spend. We could ban P2SH or restrict P2SH to be IsStandard also, but you are now unable to support HTLC (no atomic swap) or LN, unless you specifically add those scripts to IsStandard. And if a better layer 2 comes along or LN is updated to use better scripts, you have to hardfork those in. Even then, you can still be softforked. Remember that if we pay to a P2PKH, then publish the private key, every output paying to that address is now practically anyone can spend. Then a softfork can implement desired rules in an extensiom block, where money in UTXOs paying to the special publicized "private" key are controlled, post softfork, by data in a block that is not published to pre softfork nodes, like witness data is treated in SegWit. Sent with [ProtonMail](https://protonmail.com) Secure Email. > -------- Original Message -------- > Subject: Re: [bitcoin-dev] hypothetical: Could soft-forks be prevented? > Local Time: September 16, 2017 3:55 AM > UTC Time: September 15, 2017 7:55 PM > From: dan@osc•co.cr > To: ZmnSCPxj <ZmnSCPxj@protonmail•com> > Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org> > > 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 [-- Attachment #2: Type: text/html, Size: 10629 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <CADSvpf7sC-Rh0qoGKgagQV7Mo_BV6ymeadgfMzJ_oXPCTyJ6Mw@mail.gmail.com>]
* Re: [bitcoin-dev] hypothetical: Could soft-forks be prevented? [not found] ` <CADSvpf7sC-Rh0qoGKgagQV7Mo_BV6ymeadgfMzJ_oXPCTyJ6Mw@mail.gmail.com> @ 2017-09-15 20:15 ` Dan Libby 0 siblings, 0 replies; 12+ messages in thread From: Dan Libby @ 2017-09-15 20:15 UTC (permalink / raw) To: Andrew Quentson, Bitcoin Protocol Discussion Thanks for this link. From my reading though, it seems that only soft-forks that attempt to freeze funds are problematic on ethereum. From the article: > The soft fork creates a new and fundamentally different class of > transactions in contrast with those that currently exist within the > protocol. Currently, transactions either complete successfully and > cause a state transition, or run into an exception, in which case > state is reverted but the maximum possible gas is still charged. With > the soft fork, transactions which interact with a DAO will not fit > within these two classes: they will fail execution but no gas will be > charged. This must inevitably be the case in any soft fork that aims > to freeze the stolen funds; So in the general case ethereum can still soft-fork I think... On 09/15/2017 04:19 AM, Andrew Quentson wrote: > From my understanding, the blockchain can be designed in such a way as > to make soft-forks be impossible or at least impractical due to attack > vectors. > > http://hackingdistributed.com/2016/06/28/ethereum-soft-fork-dos-vector/ > > Ethereum, for example, can't soft-fork. They have to always hardfork. > > On 13 September 2017 at 10:50, Dan Libby via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation.org > <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote: > > 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 > <mailto:bitcoin-dev@lists•linuxfoundation.org> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev> > > -- Dan Libby Open Source Consulting S.A. Santa Ana, Costa Rica http://osc.co.cr phone: 011 506 2204 7018 Fax: 011 506 2223 7359 ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2017-09-18 6:40 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-09-18 6:40 [bitcoin-dev] hypothetical: Could soft-forks be prevented? Daniel Wilczynski
-- strict thread matches above, loose matches on Subject: below --
2017-09-13 9:50 Dan Libby
2017-09-15 4:01 ` ZmnSCPxj
2017-09-15 9:14 ` Adam Back
2017-09-15 11:47 ` Tier Nolan
2017-09-15 20:01 ` Dan Libby
2017-09-15 19:55 ` Dan Libby
2017-09-15 20:40 ` Simone Bronzini
2017-09-15 21:48 ` Dan Libby
2017-09-16 1:42 ` Andrew Poelstra
2017-09-16 3:38 ` ZmnSCPxj
[not found] ` <CADSvpf7sC-Rh0qoGKgagQV7Mo_BV6ymeadgfMzJ_oXPCTyJ6Mw@mail.gmail.com>
2017-09-15 20:15 ` Dan Libby
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox