Topic: Chance to have a Script 2.0? (Read 1614 times)

Thanks

Not necessary. Some hardfork may not break all implementations. For example, increasing max block size won't affect SPV clients

Breaking implementations is sortof the definition of a hard-fork...


Anyway, this is already something I'm working on with a few others. The discussion is going on in a mailing list dedicated to these types of programming languages:

http://article.gmane.org/gmane.comp.lang.concatenative/3712/match=

No that simple. A hardfork with OP_CHECKSIG will likely to break all kinds of implementations

"Hard fork" is just a scary way of describing a mandatory upgrade.

Nothing wrong with them because only the ones with overwhelming user acceptance can work.

Yes

Thanks, but I still don't get it. Do you mean "is not upgradable except as a hard-fork everybody accepts at the same time"?

The way that BIP16 implemented is not ideal as it created a special case in script interpretation. Also, as mentioned above, I think we should have more options than just HASH160.

For example, we may allow the use of shorter hash and public key as micro-payment and short term storage doesn't require the full security level. That would help the scalability a lot

Instead of redefining an OP_NOP one might just introduce a new type of P2SH where the script popped from the stack is evaluated by an new engine.

https://bitcointalksearch.org/topic/m.5403507

why?

Just an extension of this discussion: https://bitcointalksearch.org/topic/transaction-malleability-is-actually-a-big-problem-486133

Script is one of the most important elements in bitcoin, but it is far from perfect. Several codes were disabled due to bugs. OP_CHECKSIG is not upgradable. Do we even have a chance to have Script 2.0? This is the Script 2.0 in my mind:

1. It has to be backward compatible, aka soft fork. Thanks to Satoshi, this existing Script will allow us to do so by redefining one of the OP_NOP as something like OP_SCRIPT2EVAL

2. It has to be fully upgradable: it should retain enough room for future upgrade, in case we want Script 3.0, 4.0, 5.0. This is simple

3. Support merklized abstract syntax tree (MAST). This will allow very complex redemption conditions and embedding secret messages, while saving a lot of space.

4. Support multiple public key algorithms, allowing n-of-n multisig with n different public key algorithms. Since it is extremely unlikely for breaking different algorithms at the same time, funds are safe forever.

5. Support more hashing algorithms. Same as 4

6. OP_CHECKSIG should be broken down into several codes. It should allow the signer to specify the value of the input so lightweight wallet can calculate the fee without knowing the details of the previous tx. It should have enough flexibility to let people decide the way to sign. I had other preliminary ideas here: https://bitcointalksearch.org/topic/checksig-20-258931

7. The new OP_CHECKSIG has to take tx malleability in mind. It should allow people not to specify the txid of input (signing any UTXO of the same address), or sign the normalized txid. With normalized txid supported, however, it means full nodes have to keep an index of the normalized txid of all UTXO

8. It may allow pushing the block height and block hash to the stake. Pushing block height may allow something not doable with nLockTime (I'm not very sure). Pushing block hash will allow users to specify the fork which they want their tx being mined (something like POS. not sure if this is really useful)

EDIT: 9. It should allow the use of shorter hash and public key. This will be very useful for micro-payment and short-term storage.

The problem is, having a Script 2.0 like this could be risky. We may need to create a new alt-coin to test it for a long time before it could be merge to bitcoin. Any comments?