mirror of https://github.com/Qortal/AT
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
148 lines
5.7 KiB
148 lines
5.7 KiB
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> |
|
|
|
<html> |
|
<head> |
|
<title>CIYAM AT - Integrating AT with Script</title> |
|
|
|
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/> |
|
<meta name="copyright" content="Copyright 2015 CIYAM Developers"/> |
|
|
|
<link rel="stylesheet" href="document.css" type="text/css"/> |
|
</head> |
|
|
|
<div id="content"> |
|
<div id="header"> |
|
<div id="appname"><a href="//ciyam.org/at">AT</a></div> |
|
<h3 class="right-top">Integrating AT with Script</h3> |
|
</div> |
|
|
|
<div id="main"> |
|
<div id="text"> |
|
<pre> |
|
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". |
|
|
|
</pre> |
|
</div> |
|
</div> |
|
|
|
<div style="visibility: visible;" id="footer"> |
|
<p> |
|
<div class="footer-icon"><a target="_blank" href="//ciyam.org/"><img src="logo-gryscl-128.png" /></a></div> |
|
© 2012-2015 CIYAM Developers |
|
</p> |
|
</div> |
|
</body> |
|
|
|
</html> |
|
|
|
|