Integrating AT with Script
--------------------------
It is not expected that any crypto-currency using Bitcoin's "script" is going to try and extend it so that it
could execute Turing complete scripts. This document therefore suggests a "minimal" approach that would allow
AT to operate externally by adding a single op code (OP_CHECKSTATE).
AT Address Format
-----------------
An AT cannot have a "normal" address as it does not have a private key. It is suggested that a custom address
format would be "reserved" for AT's (so every peer can recognise when funds are being to be sent to an AT and
so that end users can "easily recognise" such addresses and not confuse them with standard addresses).
The following is a suggestion as to how this might be done:
1xxATxx<MD5 of AT>[checksum]
So an AT address might look like the following:
1xxATxxYptzC5a7p9obc2SLMPS148G2Qxg
and consists of 3 parts:
1xxATxx (prefix) YptzC5a7p9obc2SLMPS148G (MD5 in base58) 2Qxg (normal address checksum)
Thus if a user goes to send funds to 1xxATxxYptzC5a7p9obc2SLMPS148G2Qxg then the client would see the special
"1xxATxx" prefix and could "warn" the user that they are possibly sending funds to an AT (assuming that it is
not the AT creation transaction).
Creating an AT
--------------
So assuming the creator has a UTXO that has 600 satoshis and that the "AT creation fee" is 500 satoshis, with
the creator wanting to give the AT an initial balance of 100 satoshis, the AT creation transaction would look
very similar to this (assuming an "implicit" tx fee of 1 satoshi):
INPUT:
OP_DUP OP_HASH160 <creator's address hash160> OP_EQUALVERIFY OP_CHECKSIG amount: 600
OUTPUT:
script: hash160(1xxATxxYptzC5a7p9obc2SLMPS148G2Qxg) OP_CHECKSTATE amount: 599
script: OP_RETURN <meta, state, code and initial data>
Mining a new AT
---------------
Upon receiving an AT creation tx the miner would check that the fee is sufficient then it would determine the
initial "state" of the AT by determining a hash of the entire AT image (which could be saved as a binary file
or stored in DB). This "state" hash would then be prefixed to the OP_CHECKSTATE script. The "initial balance"
for the AT would appear as an output that is identical to the original UXTO script.
INPUT:
<state> hash160(1xxATxxYptzC5a7p9obc2SLMPS148G2Qxg) OP_CHECKSTATE amount: 599
OUTPUT:
script: hash160(1xxATxxYptzC5a7p9obc2SLMPS148G2Qxg) OP_CHECKSTATE amount: 100
...
script: OP_DUP OP_HASH160 <miner's address hash160> OP_EQUALVERIFY OP_CHECKSIG amount: 499 (i.e. rest of fee)
Note that every peer would also need to run AT in order to be able to verify that the AT state is correct. So
it is important that there are "maximum limits" (such as how many AT steps can be executed per AT and perhaps
how many ATs can be included per block so there is no way to "kill a node" with an AT).
Sending Funds to an AT
----------------------
Assuming we had a "lottery" AT and we have three entrants each sending 100 satoshis then the transactions the
peers send would look much like the following:
(sender1)
INPUT:
OP_DUP OP_HASH160 <sender1 address hash160> OP_EQUALVERIFY OP_CHECKSIG amount: 101
OUTPUT:
script: hash160(1xxATxxYptzC5a7p9obc2SLMPS148G2Qxg) OP_CHECKSTATE amount: 100
(sender2)
INPUT:
OP_DUP OP_HASH160 <sender2 address hash160> OP_EQUALVERIFY OP_CHECKSIG amount: 101
OUTPUT:
script: hash160(1xxATxxYptzC5a7p9obc2SLMPS148G2Qxg) OP_CHECKSTATE amount: 100
(sender3)
INPUT:
OP_DUP OP_HASH160 <sender3 address hash160> OP_EQUALVERIFY OP_CHECKSIG amount: 101
OUTPUT:
script: hash160(1xxATxxYptzC5a7p9obc2SLMPS148G2Qxg) OP_CHECKSTATE amount: 100
The output scripts use OP_CHECKSTATE (rather than OP_CHECKSIG like regular transactions) hence why the custom
address format is suggested (otherwise the end-user would have to "instruct the software to do an AT send").
Processing an AT
----------------
INPUT:
<state> hash160(1xxATxxYptzC5a7p9obc2SLMPS148G2Qxg) OP_CHECKSTATE (original 100)
<state> hash160(1xxATxxYptzC5a7p9obc2SLMPS148G2Qxg) OP_CHECKSTATE (sender1's 100)
<state> hash160(1xxATxxYptzC5a7p9obc2SLMPS148G2Qxg) OP_CHECKSTATE (sender2's 100)
<state> hash160(1xxATxxYptzC5a7p9obc2SLMPS148G2Qxg) OP_CHECKSTATE (sender3's 100)
OUTPUT:
script: OP_DUP OP_HASH160 <sender2 address hash160> OP_EQUALVERIFY OP_CHECKSIG amount: 300
script: OP_DUP OP_HASH160 <miner's address hash160> OP_EQUALVERIFY OP_CHECKSIG amount: 50
script: hash160(1xxATxxYptzC5a7p9obc2SLMPS148G2Qxg) OP_CHECKSTATE amount: 50
So in much the same way that the AT create was handled we see that AT's "state" hash is prefixed to the UTXOs
that here include the original 100 and the three lots of 100 sent by the "lottery" participants.
Assuming that the lottery decides that "sender2" is the winner and that the fee for mining this AT is 50 then
we see 300 being output to "sender2" (assuming that was the amount determined to be paid out) as well as then
50 being "returned to the AT".
