Bitcoin Forum
December 10, 2016, 03:35:44 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: [RFC] On the usefulness of scripting  (Read 1815 times)
devrandom
Newbie
*
Offline Offline

Activity: 26



View Profile WWW
March 21, 2011, 01:37:21 AM
 #1

I found scripting to be one of the more attractive features of bitcoin.  Standard transactions just check that the receiver signs using their pubkey.  But the scripting language can do much more interesting things.

However, the scripting language is currently mostly disabled.  Only two simple types of scripts are allowed in the standard client due to the implementation of ::IsStandard() and Solver() - script.cpp:967.  Any transactions with a different script form will not be relayed or mined.  A block with such a script will be accepted, so miners can choose to extend support.  But it would be ideal if some scripting is allowed for mining and relay in the standard client to allow for wider adoption.

Low trust escrow

The transaction script can be in the form of:

Code:
(sender_pubkey OR receiver_pubkey) AND escrow_pubkey

or even:

Code:
(sender_pubkey OR receiver_pubkey) AND vote(escrow_pubkey1, escrow_pubkey2...)

This allows the transaction to be finalized by a third party escrow and either the sender or receiver.  None of the parties have to be trusted with the coins.

Immediate transactions

The problem with using bitcoin in time sensitive settings is that it takes many minutes for transactions to be confirmed to achieve low probability of double spends.  It would be ideal for some applications (e.g. mobile payments) to have immediately verifiable transactions.  This can be achieved with a variant on the escrow script.  The funds are converted to "certified funds" ahead of time:

Code:
sender_pubkey AND certifier_pubkey

The funds can then be spent incrementally by having the sender and certifier collaborate to create a transaction.  The certifier is a trusted third party that guarantees no double spends using its reputation.  If it sees too much spends for the funds, it simply refuses to cooperate in the creation of the transaction.

So what would it take to re-enable more general scripting?

https://github.com/devrandom
1481340944
Hero Member
*
Offline Offline

Posts: 1481340944

View Profile Personal Message (Offline)

Ignore
1481340944
Reply with quote  #2

1481340944
Report to moderator
1481340944
Hero Member
*
Offline Offline

Posts: 1481340944

View Profile Personal Message (Offline)

Ignore
1481340944
Reply with quote  #2

1481340944
Report to moderator
1481340944
Hero Member
*
Offline Offline

Posts: 1481340944

View Profile Personal Message (Offline)

Ignore
1481340944
Reply with quote  #2

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

Posts: 1481340944

View Profile Personal Message (Offline)

Ignore
1481340944
Reply with quote  #2

1481340944
Report to moderator
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1470


View Profile
March 21, 2011, 01:50:22 AM
 #2

Because scripting is mostly disabled and difficult to get right in a secure way, I would rather just strip it out, for btc2.

You can do signed validation and multi-in, multi-out without a script engine.

Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2506


View Profile
March 21, 2011, 01:56:49 AM
 #3

Immediate transactions

That's an interesting idea. It would be much better than relying totally on a trusted third-party to handle it, since they can't steal your money in this case.

Many of the script ops (like OP_XOR and OP_MUL) were disabled when it was found that some of the arithmetic ones could be exploited to crash all Bitcoin nodes. Those need to have their security closely examined before they are enabled again.

I'm also strongly in favor of removing IsStandard restrictions, especially when relaying transactions. I modified my node to accept non-standard transactions, though I don't mine, so it doesn't matter much.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
devrandom
Newbie
*
Offline Offline

Activity: 26



View Profile WWW
March 21, 2011, 04:30:37 AM
 #4

Because scripting is mostly disabled and difficult to get right in a secure way, I would rather just strip it out, for btc2.

You can do signed validation and multi-in, multi-out without a script engine.

These use cases don't use multi-in or multi-out.  They have multiple pubkeys on a single output.  This allows multiple parties to cooperate in a transaction.  There's no way to implement escrow and such without scripts.

I agree that there should be a careful security review, but I don't think it's that difficult.  The main thing is to do validation of length and bounds, and have multiple reviewers of the code.

I went over the code and I don't actually see that many disabled operations.  Unless I am missing something, currently all clients accept blocks with complex scripts.   They only reject mining them.  So a miner could insert complex scripts into the block chain.  The security of the system as it currently stands does depend on making sure the scripting system is secure.

One thing I do notice is that OP_MUL doesn't have a bounds check.  Clients can be crashed with a few OP_DUP + OP_MUL in an otherwise valid block.  This seems to currently be a security issue.  I can do a more thorough review in a few days.

https://github.com/devrandom
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2506


View Profile
March 21, 2011, 04:39:27 AM
 #5

It's disabled, so it's not a current vulnerability. From script.cpp:
Code:
            if (opcode == OP_CAT ||
                opcode == OP_SUBSTR ||
                opcode == OP_LEFT ||
                opcode == OP_RIGHT ||
                opcode == OP_INVERT ||
                opcode == OP_AND ||
                opcode == OP_OR ||
                opcode == OP_XOR ||
                opcode == OP_2MUL ||
                opcode == OP_2DIV ||
                opcode == OP_MUL ||
                opcode == OP_DIV ||
                opcode == OP_MOD ||
                opcode == OP_LSHIFT ||
                opcode == OP_RSHIFT)
                return false;

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
March 21, 2011, 09:26:42 AM
 #6

The first step to playing with interesting scripts is to re-enable non standard transactions on the testnet. I keep meaning to do this but have been busy with other things, like making the testnet-in-a-box.
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
March 21, 2011, 12:17:00 PM
 #7

The first step to playing with interesting scripts is to re-enable non standard transactions on the testnet. I keep meaning to do this but have been busy with other things, like making the testnet-in-a-box.
Making IsStandard() return true if fTestNet is a good idea.

The process for getting a new transaction type into bitcoin would be to test it thoroughly on the testnet, get general consensus on its API and/or GUI and that it is useful, safe, and unlikely to be abused, and work with the 'infrastucture' sites (like blockexplorer and bitcoinmonitor) to make sure the right APIs or hooks are in place so they can do something intelligent with the new transactions.

How often do you get the chance to work on a potentially world-changing project?
devrandom
Newbie
*
Offline Offline

Activity: 26



View Profile WWW
March 21, 2011, 04:31:22 PM
 #8

Sounds like a good initial plan.  Let me think about the best way to approach this in the client, as it involves multiple coordinating parties.

https://github.com/devrandom
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1470


View Profile
March 21, 2011, 07:28:51 PM
 #9

Making IsStandard() return true if fTestNet is a good idea.

The process for getting a new transaction type into bitcoin would be to test it thoroughly on the testnet, get general consensus on its API and/or GUI and that it is useful, safe, and unlikely to be abused, and work with the 'infrastucture' sites (like blockexplorer and bitcoinmonitor) to make sure the right APIs or hooks are in place so they can do something intelligent with the new transactions.

+1 agreed


Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
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!