This diagram shows some additions I want to make to the Bitcoin architecture. An explanation follows below the image.
Normal Bitcoin transactions follow the black arrows:
2. The buyer instructs his PC to publish the transaction on the Bitcoin
network. For this, the PC uses the seller address and the amount (both
transferred in an non-standardized way outside the Bitcoin network),
and the buyer's private keys, which are stored on the buyer's device.
6. Miners pick up unverified transactions to put them in new blocks.
7. Approximately 10 minutes later, a miner manages to construct a new
block with the transaction in it, and adds it to the block chain.
8/9. Both the buyer and seller can follow the verification process by
monitoring the block chain. After approximately one hour, the
transaction is buried under 6 blocks in the chain, which is the moment
when most Bitcoin users consider the transaction verified.
Depending on the required verification confidence, the whole process
can take up to an hour. This is definitely too long for application
in POS (Point Of Sale) transactions, where transactions must not
take more than a few seconds.
The 'classical' approach would be to accept a lower quality of
verification. For POS transactions, even waiting for a single block
would take too much time, so the only classical verification method
would be to monitor the pool of unverified transactions, to check
whether there is any double-spending. This method is not guaranteed
to work, and especially in a very large Bitcoin network, where
it takes more than a few seconds for transactions to reach all network
nodes, this creates a risk for the seller.
For fast, reliable and convenient POS transactions, I propose an
addition to the Bitcoin architecture, which consists of the red arrows.
The figure assumes that the buyer uses a smart phone or some other
portable, programmable device. The device needs a connection with the
Bitcoin network: this can either be an independent connection (e.g.
using mobile Internet), or it can be tunneled through the Internet
connection of the seller.
The first addition is arrow 1. I propose to make one or a small
number of standardized ways to transfer transaction information
(such as seller Bitcoin address, and the amount) between the POS
terminal and the buyer device. NFC or QR codes would be suitable
media for this.
The buyer confirms the transaction by publishing the transaction in
the Bitcoin network (2). There, the transaction follows the normal
"slow" verification route (6/7/8/9).
The second addition allows to speed up the verification process.
In addition to publishing the transaction (2), the buyer also signs
the transaction, and (3) sends it to a node in the "Fast Verification
Network", which will be described later. Nodes in the Fast
Verification Network quickly check the transaction against the
existing transactions (4), and if it is OK, it is signed and
transferred further through the network, until it reaches the POS
terminal (5). The signatures received with the transaction through
the Fast Verification Network give the seller an initial verification
within a few seconds. Final verification reaches buyer and seller in
the classical way (8, 9).
The reason why the signature received through (5) can act as
verification is that nodes in the Fast Verification Network do not
connect to each other randomly: instead, a link is only made when
the two nodes trust each other. If a node signs a transaction and
sends it to a neighbor, and later the transaction turns out to be
a rejected double-spend, the node is obliged to pay the corresponding
amount of bitcoins to the same neighbor. This means that, even if
the payment turns out to be a double-spend, the seller can still
receive his payment by requesting it from his nearest neighbor in the
Fast Verification Network. As long as all nodes are honest towards
their direct neighbors, this means that eventually the buyer will
have to do the payment to his access point in the Fast Verification
Network.
Normally, when a node sends a signed transaction to another node,
the receiving node has to trust the sending node. Trust can be
reversed if the sending node sends a certain amount of bitcoins to
the receiving node PRIOR to establishing the connection. If the
receiving node has no trust at all in the sending node, this prior
payment creates a maximum for the value of transactions that can be
sent simultaneously over the link.
Trust can be obtained in a number of different ways, e.g. knowledge of
the real-world identity of a neighboring node, or an online reputation
rating system.
So, what do you think? Is this a useful addition to the Bitcoin
infrastructure? Do you see any issues, or possible improvements?
