Ok. I’ll try and explain it in simple English:
There are generally 3 entities in every transaction:
Alice (the seller)
Bob (the seller)
Trent (the exchange)
Traditionally a double entry transaction would look like this. (This is a transaction not a trade, so it is only one-way). It assumes there is another mirror transaction in reverse.
Alice (I want to sell a car)
Trent (I have found a buyer for this car)
Bob (I want to buy a car)
On Alice’s book:
Alice (16 – 1) – Trent (+ 1 car)On Trent’s Book: (two separate entries)
A: Trent (500 + 1) – Alice (– 1 car)
B: Trent (501 – 1) – Bob (+ 1 car)On Bob’s book:
Bob (2 + 1 car) – Trent (– 1 car)There is no 3 entry; the transaction went from Alice to Bob via Trent. However Only Trent has a ‘transaction pair.’
With triple entry book-keeping this entire transaction would happen with ONE entry:
Alice (I want to sell a car)
Trent (I have found a buyer for this car)
Bob (I want to buy a car)
Trent learns that there is a transaction that matches.
He creates an entry:
“Alice (16 – 1 car) – Bob (2 + 1 car)” … and signs it (with a reference number).
Trent then sends a copy of this entry to Alice.
Alice signs it (agrees with the transaction), and sends it back to Trent.
Trent then sends it to Bob, who also signs it (aka he also accepts the transaction).
Then the fully signed entry is propagated throughout the relevant parties.
It looks like:
“Alice (16 – 1 car) – Bob (2 + 1 car) Trent (agrees) – Alice (agrees) – Bob (agrees)“Every party has the same copy.In much the same system is how Bitcoin works.
Replace Trent with the blockchain;
Replace Bob with a bitcoin address. (That can only receive coins).
And Replace Alice with a private key.
Vola, you have Bitcoin.
Show Posts
Our API is coming along leaps and bounds. 
