Skip to main content

2 Way Transaction

banner

Currently, Bitcoin payments reflect as "charity": Alice pays Bob 1 BTC for a mid-range car, but the Bitcoin ledger can only reliably show that Alice charitably gave Bob 1 BTC. AIBlock's blockchain needs to be able to reflect the token payment as well as the asset the payment is for. To this end, what is required is a 2 way transaction, or 2WT.

How a 2WT Works​

Bob has a karambit, an rare knife skin used in the game Counter Strike which he wishes to sell through the AIBlock blockchain. Alice decides to buy the in-game item. In the event that Alice pays Bob 100 AIBCOIN for the item skin, the following sequence occurs:

  1. Alice creates a transaction that sends 100 AIBCOIN to Bob, and expects the encoding scheme for his karambit knife skin

  2. Bob creates a transaction that sends the karambit knife skin encoding scheme to Alice, and expects 100 AIBCOIN in return

  3. Alice and Bob exchange their respective halves of an identifier called a DRUID (Double Resolution Unique ID)

  4. Alice and Bob each concatenate the other party's half to their own in order to create the final DRUID, and attach the DRUID to their own respective transactions as an attribute (druid: Option<String>)

  5. Alice sends her DRUID transaction to the Mempool node for verification. Since Bob is currently offline and has not sent his corresponding DRUID transaction, the Mempool node simply adds Alice's transaction to its DRUID pool as a DRUID droplet (druid_pool: BTreeMap<String, DruidDroplet>) and waits until Bob sends his

  6. Once Bob sends his transaction, the Mempool node matches it with Alice's by checking the corresponding DRUID, removes Alice's transaction droplet from the DRUID pool, and processes each transaction separately before adding them to the next block

NOTE: Even though both transactions are processed separately, both still retain the DRUID value. This allows for auditing of the trade at a later stage

Item-Based Payments​

In addition to enabling auditable trades of tokens for data assets, the 2WT also enables item-based payments. A item-based payment is one in which Alice wants to give Bob 100 AIBCOIN as a charitable gift, but requires Bob to approve the gift before it gets processed into a block.

In order to facilitate this, Alice simply needs to leave the expected asset field in her transaction blank (signifying that she expects nothing in return). Bob does the same on his side, by requesting 100 AIBCOIN but leaving the data asset to sell blank (signifying he does not intend to provide anything of value in return). The process is the same as before, with both Alice and Bob submitting their respective transactions with the same DRUID and having them processed by the Mempool node.

Future Considerations and Improvements​

In order for item-based payments to truly be effective, the content will need to be signed with each user's private key before submitting to the Mempool node. This means that eventually there will need to be some value in the data field for item-based payments, but this can be fixed to a value which does not require a creation event (as normal data assets do).