Nxt Forum

Please login or register.

Login with username, password and session length
Advanced search  

News:

Latest Nxt 1.11.13 - NEW RELEASE: Ardor 2.0.14 - The Ardor genesis block happened at 0:00 January 1st

Pages: [1]

Author Topic: ATOMIC 11694807213441909013 - in SuperNET CORE - single blockchain for all  (Read 1694 times)

jl777

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 6170
    • View Profile
  • Karma: +718/-123

Update: We will be appending this information to the ATOMIC technical document

ATOMIC Ledger Process

Brief: As ATOMIC will act as a single “ticker tape” that can keep track of exchanges between all crypto-currencies, assets, or any future blockchain related technologies, how will we keep track of and verify all of the exchanges in a decentralized way? One part of the ATOMIC network called the ATOMIC Ledger (the blockchain of the network) will make use of newly available attributes of Bitcoin transaction scripts for a portion of the process. If you would like to read more about transactions scripts there is a great article on the wiki: https://en.bitcoin.it/wiki/Script

Coinbase header script data (Block):
   Upon the generation of a block the generation transaction contains the coinbase which can contain any small amount of random data as it is the input of the generation transaction. Bitcoin core currently does not actually make use of this data so there is no risk in ATOMIC appending transaction information. Some mining pools will append the name of their pool or other information for example. While the data isn't seen by most users of Bitcoin, the data can be accessed via the RPC interface or directly as strings from the blockchain database file stored locally. This small data area of each block in the blockchain is a great place for ATOMIC to store information that must be verifiable by all members of the network and backed by a decentralized blockchain. As the amount of data that we can fit into the coinbase is very small (the entire script must be less than 100 bytes) this area is going to be lightly used.

OP_RETURN data (Transaction):
   The main area that ATOMIC will be appending information however will be within the OP_RETURN attribute of transaction scripts which has been enabled in every transaction since Bitcoin core version 0.9 was released. ATOMIC obviously does not use the same blockchain as Bitcoin but it is good to know that the OP_RETURN attribute has seen major use for a long period of time in the core Bitcoin network which means it has been well used and abused. As this feature has been well tested we can take a look at both the positives and the possible drawbacks of using OP_RETURN as a solution for appending small amounts POE related data.
   OP_RETURN data is different from the coinbase data described above as instead of being part of each block generated, OP_RETURN is a part of every transaction. This means that when the ATOMIC network has confirmed an exchange via POE or when an exchange is being broadcast to the 'miners' of the network in order for it to be confirmed we can use OP_RETURN to store relevant data. With this portion of the ATOMIC ledger process we will be able to broadcast, verify and store exchange information in a 100% decentralized way. As with the coinbase of each block described above, the OP_RETURN data from transactions is not displayed to typical users of Bitcoin unless they request the information from the command line or manually view data in the blockchain. We will be developing an open source addition to current blockchain explorers which will allow this information to be viewed as the ATOMIC network will need to.

Multiple forms of verification:
   Another benefit of making use of these two separate areas of decentralized storage is that by design the messages in the block coinbase can only be generated by the miners of network where as transactions may be generated by any user. One option for a slight amount of added security would require that all new 'miners' go through a significant verification process (ruled by the network not by a central authority) similar to the waiting period that is required by Proof Of Stake coins before they will begin minting coins. This would mean that in order to be able to actually add data to coinbase you must have already proven your node as being reliable and stable.
There are over 1000 people in SuperNET slack! http://slackinvite.supernet.org/ automatically sends you an invite

I am just a simple C programmer

tylergillies

  • Jr. Member
  • **
  • Offline Offline
  • Posts: 42
    • View Profile
  • Karma: +4/-0

UNITY UNITY UNITY But really, Unity. This is not zero sum. We are better together.
Pages: [1]