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



signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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 
> 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
>  > 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
> 
> 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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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 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
>>
>>   OP_TRUE
>>
>> So is the below:
>>
>>   OP_SIZE  OP_EQUAL
>>
>> Or:
>>
>>   OP_1ADD  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  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

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 to make opt-in forks impractical/infeasible for
purpose of network wide consensus rule change, I'd love to hear it.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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
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
> 
>   OP_TRUE
> 
> So is the below:
> 
>   OP_SIZE  OP_EQUAL
> 
> Or:
> 
>   OP_1ADD  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  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 
> 
> 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

[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 using the issue tracker at GitHub:

  

How to Upgrade
==

If you are running an older version, shut it down. Wait until it has completely
shut down (which might take a few minutes for older versions), then run the 
installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on Mac)
or `bitcoind`/`bitcoin-qt` (on Linux).

The first time you run version 0.15.0, your chainstate database will be 
converted to a
new format, which will take anywhere from a few minutes to half an hour,
depending on the speed of your machine.

The file format of `fee_estimates.dat` changed in version 0.15.0. Hence, a
downgrade from version 0.15.0 or upgrade to version 0.15.0 will cause all fee
estimates to be discarded.

Note that the block database format also changed in version 0.8.0 and there is 
no
automatic upgrade code from before version 0.8 to version 0.15.0. Upgrading
directly from 0.7.x and earlier without redownloading the blockchain is not 
supported.
However, as usual, old wallet versions are still supported.

Downgrading warning
---

The chainstate database for this release is not compatible with previous
releases, so if you run 0.15 and then decide to switch back to any
older version, you will need to run the old release with the 
`-reindex-chainstate`
option to rebuild the chainstate data structures in the old format.

If your node has pruning enabled, this will entail re-downloading and
processing the entire blockchain.

Compatibility
==

Bitcoin Knots is supported on multiple operating systems using the Linux kernel,
macOS 10.8+, and Windows Vista and later. Windows XP is not supported.

Bitcoin Knots should also work on most other Unix-like systems but is not
frequently tested on them.

Notable changes
===

Performance Improvements


Version 0.15 contains a number of significant performance improvements, which 
make
Initial Block Download, startup, transaction and block validation much faster:

- The chainstate database (which is used for tracking UTXOs) has been changed
  from a per-transaction model to a per-output model (See [PR 
10195](https://github.com/bitcoin/bitcoin/pull/10195)). Advantages of this 
model
  are that it:
- avoids the CPU overhead of deserializing and serializing the unused 
outputs;
- has more predictable memory usage;
- uses simpler code;
- is adaptable to various future cache flushing strategies.

  As a result, validating the blockchain during Initial Block Download (IBD) 
and reindex
  is ~30-40% faster, uses 10-20% less memory, and flushes to disk far less 
frequently.
  The only downside is that the on-disk database is 15% larger. During the 
conversion from the previous format
  a few extra gigabytes may be used.
- Earlier versions experienced a spike in memory usage while flushing UTXO 
updates to disk.
  As a result, only half of the available memory was actually used as cache, 
and the other half was
  reserved to accommodate flushing. This is no longer the case (See [PR 
10148](https://github.com/bitcoin/bitcoin/pull/10148)), and the 
entirety of
  the available cache (see `-dbcache`) is now actually used as cache. This 
reduces the flushing
  frequency by a factor 2 or more.
- In previous versions, signature validation for transactions has been cached 
when the
  transaction is accepted to the mempool. Version 0.15 extends this to cache 
the entire script
  validity (See [PR 10192](https://github.com/bitcoin/bitcoin/pull/10192)). 
This means that if a transaction in a block has already been 
accepted to the
  mempool, the scriptSig does not need to be re-evaluated. Empirical tests show 
that
  this results in new block validation being 40-50% faster.
- LevelDB has been upgraded to version 1.20 (See [PR 
10544](https://github.com/bitcoin/bitcoin/pull/10544)). This version contains 
hardware 
acceleration for CRC
  on architectures supporting SSE 4.2. As a result, synchronization and block 
validation are now faster.
- SHA256 hashing has been optimized for architectures supporting SSE 4 (See [PR 
10821](https://github.com/bitcoin/bitcoin/pull/10821)). 
SHA256 is around
  50% faster on supported hardware, which results in around 5% faster IBD and 
block
  validation. In version 0.15, SHA256 hardware optimization is disabled in 
release builds by
  default, but can be enabled by using `--enable-experimental-asm` when 
building.
- Refill of the keypool no longer flushes the wallet between each key which 
resulted in a ~20x speedup in creating a new wallet. Part of 
this speedup was used to increase the default keypool to 1000 keys to make

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 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"  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
>>
>>   OP_TRUE
>>
>> So is the below:
>>
>>   OP_SIZE  OP_EQUAL
>>
>> Or:
>>
>>   OP_1ADD  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  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 
>>
>> 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

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
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
>
>   OP_TRUE
>
> So is the below:
>
>   OP_SIZE  OP_EQUAL
>
> Or:
>
>   OP_1ADD  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  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 
>
> 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] 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 signal for
segwit scripts, because these scripts result in different addresses.
That way, a WIF private key can still be associated to a single Bitcoin
address.

What WIF currently does is:

Nothing -> uncompressed pubkey
0x01-> compressed pubkeys, non-segwit (can be used in P2PKH or P2SH)

We could extend it as follows:

0x02 -> segwit script embedded in P2SH (P2WPKH or P2WSH)
0x03 -> native segwit script (P2WKH or P2WSH)


Note 1: This is similar to my {x,y,z}{pub,prv} proposal for bip32
extended keys. (see other thread)

Note 2: It is probably not useful to use distinct bytes for P2WKH and
P2WSH, because the P2SH script is not known anyway. We did not do it for
non-segwit addresses, I guess we should keep it the way it is.

Note 3: we could also use a bech32 format for the private key, if it is
going to be used with a bech32 address. I am not sure if such a format
has been proposed already.

Note 4: my proposal will not result in a user visible change at the
beginning of the string, like we have for compressed/uncompressed. This
could be improved.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[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 
sidechain-headers-on-mainchain/SHOM/SHM/driveproofs creates a very weak peg, 
and that only sidechain-only miners can take advantage of this weak peg.  This 
is because, the fee paid by sidechain-only miners to mainchain miners will 
approach TRANSFERLIMIT / 288 to protect against theft, and then sidechain 
miners will be unable to replenish their maincoin stock (to pay for the 
blind-merge-mine) if they do not transfer *only* their sidecoins earned.

Regards,
ZmnSCPxj

 Original Message 
Subject: Re: [bitcoin-dev] Sidechain headers on mainchain (unification of 
drivechains and spv proofs)
Local Time: September 8, 2017 10:56 PM
UTC Time: September 8, 2017 2:56 PM
From: zmnsc...@protonmail.com
To: Chris Stewart , CryptAxe , Paul 
Sztorc 
Bitcoin Protocol Discussion 

Good morning,

Chris mentioned the use of OP_WITHDRAWPROOFVERIFY.  I've come to realize
that this is actually superior to use OP_WITHDRAWPROOFVERIFY with a
sidechain-headers-on-mainchain approach.

Briefly, a payment to OP_WITHDRAWPROOFVERIFY is an instruction to transfer
value from the mainchain to a sidechain.  Thus, a payment to
OP_WITHDRAWPROOFVERIFY includes the sidechain to pay to, and a commitment
to a sidechain address (or whatever is the equivalent to a sidechain
address).

Various OP_WITHDRAWPROOFVERIFY explanations exist.  Most of them include
OP_REORGPROOFVERIFY.  With sidechain-headers-on-mainchain, however, there is
no need for reorg proofs.  This is because, the mainchain can see, in real
time, which branch of the sidechain is getting extended.  Thus if someone
attempts to defraud a sidechain by forking the sidechain to an invalid
state, sidechainers can immediately detect this on the mainchain and
immediately act to prevent the invalid fork from being advanced.  After
all, a reorg proof is really just an SPV proof that is longer than some
previous SPV proof, that shows that the previous SPV proof is incorrect,
by showing that the block at the specified height of the WT is not present
on a longer SPV proof.

Since sidechain-headers-on-mainchain implies merge mining of sidechains,
with no option to have independent proof-of-work of sidechains, the
sidechain's entire history is recorded on the mainchain, visible to all
mainchain nodes.

--

An advantage of sidechain-headers-on-mainchain is a side-to-side peg without
passing through the mainchain.
That is, a 2-way peg between any two chains, whether side or main.

Sidechains supporting side-to-side transfer would require supporting
OP_WITHDRAWPROOFVERIFY, but not any of the other parts of sidechains.

We must consider a WT format (withdrawal transaction) that is compatible
with an OP_WITHDRAWPROOFVERIFY Bitcoin transaction.

***That is, a lockbox UTXO on one chain is a WT on another chain.***

Sidechains need not follow the mainchain format for its normal
transactions, only for WT transactions that move coins across chains.

For this, mainchain should also have its own "sidechain ID".  Perhaps a
sidechain ID of 0 would be appropriate for mainchain, as its status as
mainchain.

Suppose we have two sidechains, Ess and Tee, both of which support
side-to-side pegs.

An Ess fullnode is a Bitcoin fullnode, but an Ess fullnode is not
necessarily a Tee fullnode, and vice versa.

A lockbox redemption in sidechain-headers-on-mainchain is simply a spend of
a lockbox, pointing to the sidechain header containing WT, the merkle tree
path to the WT transaction from the h* commitment of the header, the output
which locks, and so on as per usual OP_WITHDRAWPROOFVERIFY.

Then a sidechain can create tokens from nothing, that are locked in a
OP_WITHDRAWPROOFVERIFY lockbox; this is the only way to create sidecoin.
When transferring into a sidechain from mainchain, or anywhere, the
sidechain either creates tokens locked into OP_WITHDRAWPROOFVERIFY, or
looks for an existing UTXO with OP_WITHDRAWPROOFVERIFY from the source
chain and spends them (the latter is preferred as it is fewer
transactions and less space on the sideblock, reducing sidechain fees).

OP_WITHDRAWPROOFVERIFY on a sidechain would query the mainchain fullnodes.
Whatever rules allow lockbox unlocking on mainchain, will also be the same
rules that allow lockbox unlocking on sidechains.
A mainchain RPC can even be made to simplify sidechain verification of
side-to-side pegs, and to ensure that sidechains follow the same consensus
rules for OP_WITHDRAWPROOFVERIFY.

So if we want transfer TeeCoin to EssCoin, we spend into a
OP_WITHDRAWPROOFVERIFY lockbox on Teechain pointing to Esschain (i.e. a
Tee->Ess lockbox).  This lockbox is itself a WT

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 is the below:

  OP_SIZE  OP_EQUAL

Or:

  OP_1ADD  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  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 

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