Bitcoin Forum
September 22, 2019, 02:41:59 AM *
News: If you like a topic and you see an orange "bump" link, click it. More info.
 
   Home   Help Search Login Register More  
Pages: « 1 [2]  All
  Print  
Author Topic: Testing so that opcodes can be re-enabled  (Read 2926 times)
TierNolan
Legendary
*
Offline Offline

Activity: 1232
Merit: 1002


View Profile
July 14, 2013, 08:18:53 PM
 #21

isn't that the purpose for test net 3 bitcoins? why not try it out on them~~~

That sounds reason.  Re-enable all the opcodes for testnet?

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
There are several different types of Bitcoin clients. The most secure are full nodes like Bitcoin Core, which will follow the rules of the network no matter what miners do. Even if every miner decided to create 1000 bitcoins per block, full nodes would stick to the rules and reject those blocks.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1569120119
Hero Member
*
Offline Offline

Posts: 1569120119

View Profile Personal Message (Offline)

Ignore
1569120119
Reply with quote  #2

1569120119
Report to moderator
1569120119
Hero Member
*
Offline Offline

Posts: 1569120119

View Profile Personal Message (Offline)

Ignore
1569120119
Reply with quote  #2

1569120119
Report to moderator
1569120119
Hero Member
*
Offline Offline

Posts: 1569120119

View Profile Personal Message (Offline)

Ignore
1569120119
Reply with quote  #2

1569120119
Report to moderator
Peter Todd
Legendary
*
expert
Offline Offline

Activity: 1106
Merit: 1013


View Profile
July 14, 2013, 09:43:52 PM
 #22

isn't that the purpose for test net 3 bitcoins? why not try it out on them~~~

That sounds reason.  Re-enable all the opcodes for testnet?

Testnet has to match mainnet, so the removed opcodes are still removed. By all other transaction types are valid - testnet doesn't use the IsStandard() tests.

If you want to test new opcodes on testnet, go right ahead. It'll just mean you get forked by the rest of testnet, not a big deal.

gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2814
Merit: 2416



View Profile
July 15, 2013, 03:03:32 AM
 #23

Probably the most interesting thing in testing this stuff is coming up with uses for them. Doing so would guide which ones were more important to add. (and this is key: it should probably be thought of as _add_ not re-enable, since adding can be done as a soft fork, a lot easier and less risky)

d'aniel
Sr. Member
****
Offline Offline

Activity: 461
Merit: 250


View Profile
July 15, 2013, 11:04:50 AM
 #24

A p2p prediction market would be a pretty cool use case.  This could also be used to hedge FX risk of holding bitcoins.  I guess it might work something like this:

An oracle publishes the hash of a secret, and the secret as well if a given event occurs before some expiry date.

With this setup, we want anyone (a writer) to be able to construct a tx with a txout (the contract) whose script allows only the buyer of the contract to spend it before the expiry date, and only if he can provide the secret.  Furthermore, we want only the writer to be able to spend the txout after the expiry date.  I think this only additionally requires the PUSH_BLOCK_DATE opcode that Sergio proposed above.  The writer would include a second txout that spends to him the price in bitcoins he's asking for the contract.  He would sign inputs that add up to the contract txout plus any tx fee, and the buyer would provide the rest of the inputs required.

It would be nice if trust could be spread across multiple oracles by requring m of n secrets for the buyer to spend the txout.  We don't have OP_AND or OP_OR, so I guess we'd need these or maybe a special opcode just for this purpose?

A really nice feature would be if the person buying this contract were able to spend it on the blockchain without requiring a signature from the person writing it.  Then we could have trust free (ignoring underlying trust in oracles) secondary markets for these contracts.  Could this be done using the transaction persistence you mentioned, Sergio?  I guess the condition for the buyer to be able to spend it before the expiry date, but without the secret(s), would be that the tx which spends it has a txout (the replacement contract) of greater or equal value, and with the same script, except with the original buyer's address replaced by the new buyer's.
TierNolan
Legendary
*
Offline Offline

Activity: 1232
Merit: 1002


View Profile
July 15, 2013, 11:07:57 AM
 #25

Probably the most interesting thing in testing this stuff is coming up with uses for them. Doing so would guide which ones were more important to add. (and this is key: it should probably be thought of as _add_ not re-enable, since adding can be done as a soft fork, a lot easier and less risky)

You mean using nops?  My understanding is that a script containing a disabled opcode will fail.

Maybe it could work like the P2SH code.

Pub key:

<script - version> <ignore> <actual script> OP_EXECUTE OP_DROP OP_DROP OP_DUP OP_HASH160 <hash of address> OP_EQUAL_VERIFY OP_CHECKSIG

sig script
<hash of public key>
<signature>
<hashes for actual script>

This means that old clients won't allow spending unless you have the standard public key.

Colored coins would still want to make sure that the spend is authorized, so the <actual script> would .

New clients would run the actual script too.

The rules could be something like

- reject script if <script - version> of any output is not a network accepted version
- reject script if it has more than 1 OP_EXECUTE opcode
- run <actual script> with 2 + <ignore> items popped off the stack (2 + 2 in this case)
-- transaction is invalid if this script fails

This would need to be combined with a rule for updating the script number.  

For example, if 550 out of 1000 blocks have /SCV+<n>/ in their coinbase transactions, then from 2000 blocks later, scripts of that version would be allowed.  If there is 55 out 100 with </SCV-<n>/, then that disables that script version.

The rule for miners would be to not include any transactions that they cannot verify in their own blocks.  A warning would also be given recommending upgrading.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
Sergio_Demian_Lerner
Hero Member
*****
expert
Offline Offline

Activity: 546
Merit: 521


View Profile WWW
July 15, 2013, 12:59:07 PM
 #26

I have the following proposal:

Why don't we schedule a hard fork for 2014 to enable 50 additional opcodes that we know for sure that cannot have any semantic ambiguity or security flaw?

For example: OP_PUSH_BLOCK_DATE.

We also re-standarize small/fast arbitrary scripts (say no more than 10 ops, no more than 5 sigs)

So we give researchers and innovators a whole bunch of tools to try new ideas for real.


Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526
Merit: 1008


View Profile
July 15, 2013, 01:54:25 PM
 #27

I think the first step would be to make a forked Bitcoin that implements them all (with unit tests), run a little testnet with them, and then write some cool apps that use them.

It's much easier to build consensus for big changes when there's an app everyone wants just sitting there, waiting to be activated ....
jl2012
Legendary
*
Offline Offline

Activity: 1792
Merit: 1010


View Profile
July 15, 2013, 04:50:00 PM
 #28

The most useful thing to reactivate would be tx replacement - re-adding opcodes is a hard forking change at this point and nobody has any use cases for them, whereas tx replacement is not a hard forking change and it'd be useful for some real things.

Why tx replacement is useful? There is no method to prevent miners mining a transaction with lower sequence.

Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)
LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
Pages: « 1 [2]  All
  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!