Advertisement
Guest User

Bitcoin/OT hybrid proposal

a guest
Nov 5th, 2012
119
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 2.32 KB | None | 0 0
  1. [NOTE: In this description when I say “OT transactions” I am referring to the various state-modifying messages that a user can send to an OT server. This would include issuing a new asset, placing a market order, using any of the various financial instruments, withdrawing assets as untraceable cash tokens, etc. I'm not sure what the correct OT nomenclature is (contract? message?), but coming from the Bitcoin world I will use the term “transaction.”]
  2.  
  3. 1. A network of hybrid Bitcoin-OT (bOTx) servers share OT “transactions” over a gossipy, peer-to-peer network protocol. These transactions are not executed, but are checked for consistency with the current OT state. Only transactions that *could* be executed are kept in a local data store.
  4.  
  5. 2. A mining node, of which there may be many, pulls some number of transactions from its own local data store up to a universally agreed upon limit. It verifies that these transactions will execute correctly if applied in sequence. It then computes a Merkle-tree hash of the transaction messages, and puts that hash in a standard Bitcoin header (where the Merkle-tree hash of Bitcoin transactions normally goes). The miner then iterates the nonce of the Bitcoin header until a valid proof-of-work is found, at which point it is broadcast to the network.
  6.  
  7. 3. Upon receiving a candidate-block, the other bOTx servers verify that the proof-of-work is valid (and that it does not exceed any of the universally agreed upon size limits, etc.), then executes the transactions in order. Once all transactions apply successfully, it then runs any server-side cron jobs exactly once (or according to some other deterministic schedule).
  8.  
  9. 4. Repeat.
  10.  
  11. Any user can connect with any one of the networked servers and use it like any other OT server... however with the difference that requests are queued up for execution once they are included in a valid block, not right away, and transactions can be reversed by a block reorganization--so queries about the OT state should include a “confirmation” value for confidence.
  12.  
  13. Another way of thinking about this proposal is that it uses Bitcoin's network protocol and proof-of-work system to enable a distributed, p2p network of OT servers that are guaranteed to all have the same internal state. It is a mechanism building a federated network of super-OT servers.
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement