Bitcoin Forum
June 03, 2015, 11:48:06 PM *
News: Change your password!
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Chance to have a Script 2.0?  (Read 1136 times)
jl2012
Legendary
*
Offline Offline

Activity: 1134


View Profile

Ignore
February 27, 2014, 04:46:35 PM
 #1

Just an extension of this discussion: https://bitcointalk.org/index.php?topic=486133.0

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://bitcointalk.org/index.php?topic=258931.0

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?

Donation address: 1CiZPrEJdN4FJcqdLdgVLzT8tgCXxT5ion

Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1433375286
Hero Member
*
Offline Offline

Posts: 1433375286

View Profile Personal Message (Offline)

Ignore
1433375286
Reply with quote  #2

1433375286
Report to moderator
1433375286
Hero Member
*
Offline Offline

Posts: 1433375286

View Profile Personal Message (Offline)

Ignore
1433375286
Reply with quote  #2

1433375286
Report to moderator
readerbtc
Jr. Member
*
Offline Offline

Activity: 44


View Profile

Ignore
February 28, 2014, 01:31:38 AM
 #2

OP_CHECKSIG is not upgradable.

why?
jl2012
Legendary
*
Offline Offline

Activity: 1134


View Profile

Ignore
February 28, 2014, 02:09:34 AM
 #3

OP_CHECKSIG is not upgradable.

why?

https://bitcointalk.org/index.php?topic=486133.msg5403507#msg5403507

Donation address: 1CiZPrEJdN4FJcqdLdgVLzT8tgCXxT5ion
grau
Hero Member
*****
Offline Offline

Activity: 816


bits of proof


View Profile WWW

Ignore
February 28, 2014, 03:02:56 AM
 #4

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.
jl2012
Legendary
*
Offline Offline

Activity: 1134


View Profile

Ignore
February 28, 2014, 04:25:51 AM
 #5

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.

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

Donation address: 1CiZPrEJdN4FJcqdLdgVLzT8tgCXxT5ion
readerbtc
Jr. Member
*
Offline Offline

Activity: 44


View Profile

Ignore
March 04, 2014, 03:39:15 AM
 #6

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"?
jl2012
Legendary
*
Offline Offline

Activity: 1134


View Profile

Ignore
March 04, 2014, 03:44:41 AM
 #7

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

Yes

Donation address: 1CiZPrEJdN4FJcqdLdgVLzT8tgCXxT5ion
justusranvier
Legendary
*
Offline Offline

Activity: 1274



View Profile WWW

Ignore
March 04, 2014, 03:53:48 AM
 #8

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

Bitcoinism / OTC rating
Bitcoin is Sedition
BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc
jl2012
Legendary
*
Offline Offline

Activity: 1134


View Profile

Ignore
March 04, 2014, 04:48:00 AM
 #9

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

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

Donation address: 1CiZPrEJdN4FJcqdLdgVLzT8tgCXxT5ion
maaku
Legendary
*
Offline Offline

Activity: 905


View Profile

Ignore
March 04, 2014, 06:07:34 AM
 #10

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

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=

I'm an independent developer working on bitcoin-core, making my living off community donations.
If you like my work, please consider donating yourself: 13snZ4ZyCzaL7358SmgvHGC9AxskqumNxP
jl2012
Legendary
*
Offline Offline

Activity: 1134


View Profile

Ignore
March 04, 2014, 06:11:11 AM
 #11

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

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=

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

Donation address: 1CiZPrEJdN4FJcqdLdgVLzT8tgCXxT5ion
readerbtc
Jr. Member
*
Offline Offline

Activity: 44


View Profile

Ignore
March 04, 2014, 10:03:16 PM
 #12


Yes
Thanks
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!