Re: [bitcoin-dev] hypothetical: Could soft-forks be prevented?

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

Re: [bitcoin-dev] hypothetical: Could soft-forks be prevented?

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

[bitcoin-dev] Fw: Re: Sidechain headers on mainchain (unification of drivechains and spv proofs)

Good morning, I'm re-sending this message below as it appears to have gotten lost before it reached cc: bitcoin-dev. Paul even replied to it and the reply reached on-list, so I'm re-sending it as others might have gotten confused about the discussion. So far I've come to realize that

Re: [bitcoin-dev] hypothetical: Could soft-forks be prevented?

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 OP_TRUE So

[bitcoin-dev] proposal: extend WIF format for segwit

The Wallet Import Format (WIF) currently appends a 0x01 byte after the raw private key, when that key needs to be used in conjunction with a compressed public key. This allows wallets to associate a single Bitcoin address to a WIF key. It would be useful to extend the semantics of that byte, to

[bitcoin-dev] Bitcoin Knots 0.15.0.knots20170914 released

Bitcoin Knots version *0.15.0.knots20170914* is now available from: This is a new major version release, including new features, various bugfixes and performance improvements, as well as updated translations. Please report bugs

Re: [bitcoin-dev] hypothetical: Could soft-forks be prevented?

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 >

Re: [bitcoin-dev] hypothetical: Could soft-forks be prevented?

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

Re: [bitcoin-dev] hypothetical: Could soft-forks be prevented?

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

Re: [bitcoin-dev] hypothetical: Could soft-forks be prevented?

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

Re: [bitcoin-dev] hypothetical: Could soft-forks be prevented?

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