The Scripting system in the Bitcoin Protocol

[W-M]

Hello there,

I was really amazed when I found out that Bitcoin uses a scripting system internally to create transactions, and that that means that special forms of transactions are possible.
However, it seems that the scripting part of the Bitcoin Protocol has been left mostly unused/unresearched. The two pages with the most information on them I found so far are:
The page on the wiki about Scripting
This blog post on bitcoinsecurity.org

I still do not understand the scripting system myself fully, especially the way the next person can 'validate' a certain transaction by running the script and filling in some values of its own. If someone could shed some light on this, I would be very grateful.


Anyway, it seems that there might be very interesting possibilities for novel transaction types using the scripting system. But this is largely unresearched. What new ideas can you come up with?

Until now, the following transactions have happened:

• Simple address -> address transactions: This is the one we use everyday.
• The generation of new coins as miner reward.

The following do not seem to currently be supported by all nodes:

• Provably unspendable outputs: Essentially destroying bitcoins.
• Anyone-can-spend transactions: Anyone that reads the transaction might spend the coins. Could be used to implement extra transaction costs or 'Fidelity-Bonds', a way to show that this account is not a trhowaway one.
• Address  -> IP address transactions: I believe that these can be claimed by anyone showing that their IP is the correct one. But how do these work exactly? How could other nodes verify this information?
• Transaction Puzzles: Anyone who solves the 'puzzle' (finds the correct answer and hashes it) can claim the coins.
  

So... does anyone have any more ideas as to interesting transactions to be had?

~W-M

[1715558935]

1715558935

[1715558935]

1715558935

[jdbtracker]

There are quite a few, I've mostly found them here on the forum.

Read up on Contracts and you'll see quite a few interesting scenarios.

https://en.bitcoin.it/wiki/Contracts

[extro24]

This is a very informative document:


Programming Bitcoin Transaction Scripts
https://docs.google.com/document/d/1D_gi_7Sf9sOyAHG25cMpOO4xtLq3iJUtjRwcZXFLv1E/edit

For a very good background on how Bitcoin works, read this doc:


How the Bitcoin Protocol actually works
http://www.michaelnielsen.org/ddi/how-the-bitcoin-protocol-actually-works/


Read both documents.  You won't be disappointed.  Be aware that Bitcoin scripts are written in Forth, and you can download gforth and play with it.  (In Ubuntu "apt-get install gforth").  I am still looking for a program where I can write, run and debug Bitcoin scripts.


I actually want to share scripts on this thread so that we can learn from each other. I haven't found a decent tutorial on general scripting, so these threads will have to do. I am particularly interested in scripts that transfer and validate data.  Mike Hearn is the expert here.   Maybe we can attract him to this thread.  The Bitcoin source code dealing with Scripts is script.cpp and script.h.

[Mike Hearn]

Scripts are not written in Forth. The scripting language is Bitcoin specific and is Forth-like, in that it's a stack language.

The scripting language is extremely limited, you won't find working with it to be anything like regular programming. For instance you can't do any loops and the programs can only use a tiny number of opcodes. Most interesting apps don't actually use complex scripts at all, but rather algorithms that build chains of transactions that use special SIGHASH modes and lock times.

The easiest way to experiment with these protocols IMHO is to use bitcoinj on a local regtest node (or public testnet). That's how the recent paper on multi-party lotteries was done, the researchers developed what is certainly the most advanced use of scripting yet and they prototyped it with bitcoinj.

[extro24]

Thanks Mike for answering.

Core Update 5 allows messaging:

Relay OP_RETURN <data> TxOut

OP_RETURN and <data> I understand, but what is Relay?  Some sort of instruction to the node receiving the message?  Will this script be bounced from node to node (relayed?).  And where is the destination address?

The same applies to TxOut.  Is it an instruction to put the data in the TxOut field of the script?

Where is the scriptsig/scriptPubKey of this new way of sending messages?

The following old (non-standard) way of sending a message makes much more sense to me:

scriptPubKey: <message> OP_DROP <pubKey> OP_CHECKSIG
scriptsig: <sig>

Here I can see where the message is going and how the stack will work.

[bitpop]

Yeah how was ip verified?

[bluemeanie1]

I still do not understand the scripting system myself fully, especially the way the next person can 'validate' a certain transaction by running the script and filling in some values of its own. If someone could shed some light on this, I would be very grateful.


Anyway, it seems that there might be very interesting possibilities for novel transaction types using the scripting system. But this is largely unresearched. What new ideas can you come up with?

most of the documentation assumes you know a thing or two about how assembler code works, how stacks work, etc.  The scripts are very similar to Assembly language, and officially they are 'forth-like', which is an antiquated programming language that was related to assembler.

when you first crack open Bitcoin at this level, most likely you learn about what addresses actually are and how a transaction is actually executed.  Look at how the various parts of the transaction work with the stack and you should be able to work through how to write more complex TXs.  You're right that for the most part, TX scripting is not used aside from novelty projects.  Probably the most commonly discussed alternative TX script is the fabled 'multi-sig transaction' which is a TX whose output is unlocked by more than one address.  This confuses people who believe that an address is something like an account, when in reality an address is simply a signature.

[Mike Hearn]

Thanks Mike for answering.

Core Update 5 allows messaging:

Relay OP_RETURN <data> TxOut

OP_RETURN and <data> I understand, but what is Relay?  Some sort of instruction to the node receiving the message?  Will this script be bounced from node to node (relayed?).  And where is the destination address?

The same applies to TxOut.  Is it an instruction to put the data in the TxOut field of the script?

You are misunderstanding the note. It just means outputs with scripts that contain

OP_RETURN <data>

are now treated as standard and thus will not be dropped by network nodes (after people upgrade).

I think your questions indicate you should learn more about the Bitcoin protocol before proceeding. These are fairly basic I'm afraid.

[extro24]

Ah.  So what was meant was "relay OP_RETURN <data> in TxOut".  In other words, the clients can treat it as kosher and pass it on.

Thanks again.  Certainly I need to read more.

So sending a message will end up as

scriptPubKey:  OP_RETURN <data> OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
scriptsig: <sig> <pubKey>

?  

Now there will be no problem in identifying the recipient.

[Mike Hearn]

No. Please go read the C++ to understand how this works precisely. This is advanced stuff, failure to understand what you are doing at this level will result in you destroying money. If you aren't able to read the Bitcoin Core code, learn C++ until you can.

[apxu]

[...] It just means outputs with scripts that contain

OP_RETURN <data>

are now treated as standard and thus will not be dropped by network nodes[...]

This looks like as transferring some data with bitcoin network (not free).
For example, there is a virus on computer
This virus does the following: it takes some significant data from computer (not bitcoin-related), encodes it someway and sends with OP_RETURN to bitcoin

The attacker looks through blockchain, parses all such transactions and decodes <data>

And there is no way to locate the attacker person

(Sorry, English is not my native language)

[zerox102]

looking into https://en.bitcoin.it/wiki/Contracts#Example_8:_Multi-party_decentralised_lotteries, is there a way to implement a service with no operators involved? like an ethereum autonomous entity?

[nasamanBoy]

Here on this link you very useful information on this topic
http://www.usv.com/posts/bitcoin-as-protocol...

[drawingthesun]

looking into https://en.bitcoin.it/wiki/Contracts#Example_8:_Multi-party_decentralised_lotteries, is there a way to implement a service with no operators involved? like an ethereum autonomous entity?

In relation to this question, I would be interested if the Core team feel more opcodes are needed to compete with Ethereum?