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

2017-09-15 Thread Andrew Poelstra via bitcoin-dev
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

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

2017-09-15 Thread Dan Libby via bitcoin-dev
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?

2017-09-15 Thread Simone Bronzini via bitcoin-dev
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?

2017-09-15 Thread Dan Libby via bitcoin-dev
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?

2017-09-15 Thread Dan Libby via bitcoin-dev
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

[bitcoin-dev] Bitcoin Knots 0.15.0.knots20170914 released

2017-09-15 Thread Luke Dashjr via bitcoin-dev
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?

2017-09-15 Thread Tier Nolan via bitcoin-dev
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

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

2017-09-15 Thread Adam Back via bitcoin-dev
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

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

2017-09-15 Thread Thomas Voegtlin via bitcoin-dev
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] Fw: Re: Sidechain headers on mainchain (unification of drivechains and spv proofs)

2017-09-15 Thread ZmnSCPxj via bitcoin-dev
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?

2017-09-15 Thread ZmnSCPxj via bitcoin-dev
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