Coinbit: A Peer-to-Peer Electronic Cash System

Transcription

1 Coinbit: A Peer-to-Peer Electronic Cash System Abstract. A solely peer-to-peer version of electronic cash would grant a direct transaction without any third party involved. Digital signatures are part of the solution, but benefits are obsolete if a third party is required to avert double- spending. This paper offers a solution to this problem in proposing a peer-to-peer network. This system timestamps transactions by altercating them into a chain of hash-based proof-of-work, establishing a record that cannot be altered without redoing the proof-of-work. The longest chain serves as a verification of the sequence of events, moreover it substantiates that it came from the largest pool of CPU power. As long as a majority of CPU power is controlled by nodes that are not attacking the network, they will generate the longest chain and excel attackers. For this network a minimal structure is needed. Information flow is broadcasted on a best effort basis, and nodes can come and go to the network without restraint, accepting the longest proof-of-work chain as proof of what occurred during their absence. 1. Introduction Trade on the Internet has come to depend almost entirely on financial institutions serving as a trustworthy party to process electronic remittances. This system suffers from the inherent weaknesses of the trust-based model. Non-reversible transactions cannot be executed, since financial institutions cannot avoid interfering in those matters. The cost of mediation increases expenditure. It also limits the transaction size and cuts off the option for minor casual transactions. Furthermore it leads to an augmenting amount of costs with regard to making non-reversible payments for non-reversible services. With each option of reversal, the need for a trustworthy party advances. Consequently merchants have to ask their customers for more information than normally required. Fraud is therefore being regarded as inevitable to a certain extent. These uncertainties can be evaded by using physical currency, but there seems to be no system to proceed payments without an additional trustworthy party. To improve this an electronic payment system based on cryptographic proof should be implemented instead the system of trust. This would enable parties to transact directly without any further party involved. Transactions that cannot be reversed would protect sellers from fraud, and security mechanisms could easily be installed to protect buyers. This paper proposes a solution to this problem using a peer-to-peer distributed timestamp server to generate proof of the chronological transaction order. The system is secure as long as genuine nodes hold more CPU power than any colluding attackers. 1

2 2. Transactions An electronic coin is defined as a chain of digital signatures. Each proprietor remits one coin to the next by digitally signing a hash of the previous transaction and the public key of the next owner and summate these to the end of the coin. A payee can then verify the signatures to verify this chain of proprietorship. The predicament is that the payee cannot verify that the coin has not been double-spent by one of the previous owners. To date a common solution has been to introduce a trustworthy authority, or mint, that investigates every remittance concerning double-spending. After each transaction, the coin must be returned to the mint in order to issue a new one. Only those coins issued directly from this authority are trusted not to be double-spent. The dilemma of this system is that its destiny relies on the institution operating the mint as every transaction has to go through it. The payee needs to know that the previous owners did not sign any earlier transactions. To achieve our objective it is solely the earliest transaction that matters. Consequently any further attempt of double-spending does not have to be considered. The only way to confirm the lack of a transaction is to be aware of all previous ones. In the mint-based model, all transactions were scrutinised and it was then decided which one has been the first to be proceeded. To achieve this without a trustworthy party, transactions must be publicly announced. Additionally a system is required for participants to agree on a single succession history of received transactions. The payee needs a verification that at the time of every transaction, the latter has been the first to be received compared to the majority of further existing ones. 3. Timestamp Server The solution proposed in this paper initiates with a timestamp server. This component works by taking a hash of a block of items to be timestamped and publishing the hash, such as in a newspaper. The timestamp authenticates that the data must have existed at the time in order to get into the hash. Each timestamp includes the previous one in its hash, forming a chain, with each additional timestamp reinforcing the previous ones. 2

3 4. Proof-of-Work To implement such a timestamp server on a peer-to-peer basis, a proof-of-work system similar to Adam Back s Hashcash is necessary, rather than newspaper or Usenet posts. This system includes scanning for a value that when hashed, the hash starts with a number of zero bits. The average work needed is exponential to the number of zero bits required and can be verified by producing a single hash. For the timestamp network proposed in this paper, the proof-of-work is implemented by incrementing a nonce in the block until a value is found that gives the block s hash the required zero bits. Once the CPU effort has been expended to achieve a satisfactory proof-of-work, the block cannot be altered without redoing everything. The procedure of adjusting one block would include redoing all the blocks succeeding it. With this the proof-of-work also solves the problem of determining representation in majority decision making. If the majority were based on one-ip-address-one-vote, it could be sabotaged by anyone able to allocate many IPs. The core of the proof-of-work is a one-cpu-one-vote. The majority decision is represented by the longest chain, which has the largest proof-of-work effort implemented in it. If a majority of CPU power is controlled by genuine nodes, this very chain will grow the fastest and outpace any competing ones. To modify a previous block, an attacker would have to redo the proof-of-work of the block and all subsequent blocks and then catch up with and surpass the work of the genuine nodes. It will be demonstrated later in this paper that the probability of a slow attack advancing declines exponentially as following blocks are added. To compensate for increasing hardware speed and varying interest in running nodes over time, the proof-of-work difficulty is determined by a moving average targeting an average number of blocks per hour. If they are generated too quickly, the predicament accumulates. 5. Network Here are the steps explaining how to run the network: 1) New transactions are being broadcasted to all nodes. 2) Each node transfers new transactions into a block. 3) Each node works on finding a difficult proof-of-work for its block. 4) When a node finds a proof-of-work, it sends the block to all nodes. 5) Nodes accept the block only if all transactions in it are valid and not already spent. 6) Nodes express their acceptance of the block by creating the next block in the chain, using the hash of the accepted block as the previous hash. The longest chain is always considered by the nodes to be the correct one and they will keep working on its extension. If two nodes send varying versions of the next block simultaneously, some nodes may receive one or the other first. In that case, they work on the first one they acquired, but save the other branch in case it is extended. This connection will be interrupted when the next proof-of-work is found and one branch elongated. The nodes that were working on the other branch will consequently switch to the longer one. 3

4 New transaction procedures do not automatically have to influence all nodes. As long as many nodes are contacted, they will get into a block immediately. Block broadcasts are also tolerant of lost messages. If a node does not receive a block, it will request it when it acquires the subsequent block and realizes it missed one. 6. Incentive The first transaction in a block is a special one that starts a new coin owned by the initiator of the block. This adds an enticement for nodes to support the network. It also provides a way to distribute coins into circulation initially, since no authority issues them. The steady addition of new coins can be compared with the gold miners method in using resources in such a way that includes an addition to gold to circulation. In this present case, it is CPU time and electricity that are consumed. The enticement can also be supported with transaction fees. If the output value of a transaction is less than its input value, the difference is a transaction fee that is added to the incentive value of the block containing the transaction. Once a predetermined number of coins have entered circulation, the incentive can transform entirely into transaction fees and therefore be utterly without inflation free. The incentive may help stimulate nodes to stay authentic. If an attacker can assemble more CPU power than all the authentic nodes, this person would have to choose between using it to defraud people by gaining his payments illegally or using it to create new coins. It might be more profitable for the attacker to play by the rules. Those regulations would rather favour him with a large quantity of new coins than any other party involved, than impairing the system and the value of his own wealth. 7. Reclaiming Disk Space Once the latest transaction in a coin is buried under a sufficient amount of blocks, the transactions made before can be discarded in order to preserve disk space. To achieve this without breaking the block s hash, transactions are hashed in a Merkle Tree, with only the root included in the block s hash. Old blocks can consequently be compacted by taking off branches of that organigram. The interior hashes do not have to be kept. A block header with no transactions would be about 80 bytes. If we suppose blocks are generated every 10 minutes, 80 bytes * 6 * 24 * 365 = 4.2MB per year. With computer systems typically selling with 2GB of RAM as of 2008, and Moore s Law predicting current growth of 1.2GB per year, storage should not be a problem even if the block headers must be kept in memory. 4

5 8. Simplified Payment Verification To authenticate payments without running a complete network node is feasible. The only item needed is a copy of the block headers of the longest proof-of-work chain, which he can get by querying network nodes until he is persuaded he has the longest chain, and obtain the Merkle branch linking the transaction to the block it is timestamped in. He cannot check the transaction for himself, but by connecting it to a place in the chain, he learns that a network node has accepted it, and blocks summated after it further confirm the network has approved it. In essence, the verification is sound as long as genuine nodes control the network. However it is more vulnerable the moment it is attacked. While network nodes can verify transactions on their own, the simplified method can be deceived by an attacker as long as this person can continue to vanquish the network. One protection strategy would be to accept alerts from network nodes as soon as they detect an invalid block, persuading the user s software to download the full block and to confirm the incongruity. Businesses that frequently receive payments will presumably prefer to establish their own nodes in order to achieve independent security and accelerated verification. 9. Combining and Splitting Value It is certainly possible to handle coins on an individual basis, but a separate transaction for every cent during a remittance would be too cumbersome a method. To allow the splitting and combining of a value, transactions consist of multiple inputs and outputs. As a rule there are two kinds of inputs: either a single input from a larger previous transaction or multiple inputs connecting minor amounts. And furthermore there are at most two outputs: one for the payment, and one returning the change back to the sender. 5

6 It is worth being mentioned that in this paper it is not considered a problem where a transaction relies on several ones, and those transactions respectively depend on many more. In such a case it is not necessary to excerpt a single copy of a transaction s history. 10. Privacy With the help of our traditional banking model a level of privacy is accomplished by limiting access to information to the parties involved and the reliable third party. This procedure consequently demands that all transactions are publicly announced. Privacy however can still be preserved by interrupting the flow of information: by keeping public keys anonymous. The only aspect the public can learn is that a party is sending an amount of coins to someone else, but without any further information provided as to the addressee s identity. Stock exchanges operate in an equivalent manner. A new key pair should be used as an additional firewall for each transaction to prevent them from being connected with an ordinary proprietor. Nonetheless a certain quantity of connection cannot be averted with multi-input transactions, which reveal that their inputs were owned by the same proprietor. This method contains the possibility that if the owner of a key is exposed, this could reveal other transactions conducted by the same person. 11. Calculations In this paragraph we take the liberty to construct a scenario of an attacker trying to create an alternate chain faster than the genuine one. Even if this is successful, the system is not succumbed to erratic changes, such as unreasonably creating value or taking money that the attacker could not possibly claim to be his. An invalid transaction will not be approved by nodes as payment, and authentic nodes will therefore never accept a block containing them. The only way an attacker can achieve to alter one of his own transactions is to retrieve the amount he has recently spent. The competition between those two chains, i.e. the genuine one and the one being attacked can be declared as a Binomial Random Walk. The successful event is the genuine chain being extended by one block, increasing its lead by +1, and the failing event is the attacker s chain being extended by one block, reducing the gap by -1. 6

7 The probability of an attacker trying to progress from a given deficit is akin to a Gambler s Ruin predicament. Suppose a gambler with unlimited credit starts at a deficit and plays potentially an infinite number of trials trying to reach breakeven. The probability he ever reaches breakeven, or that an attacker ever catches up with the honest chain, can be described as follows: p = probability an honest node finds the next block q = probability the attacker finds the next block q = probability the attacker will ever catch up from z blocks behind 1 When p > q, the probability falls exponentially to the number of blocks the attacker has to progress with augmentations. If he does not succeed, his chances decrease immediately as he fails to proceed. The following part will reveal how long the recipient of a new transaction needs to wait before he can be certain the sender cannot alter the transaction any more. Moreover it is assumed the sender is an attacker trying to make the recipient believe he paid him for the time being but after a certain period of time remits the amount back to himself. As soon as this occurs the receiver will be alerted and respectively the perpetrator hopes for a belated reaction. A new key pair is created by the recipient and he provides the public key to the sender shortly before signing. This way it is avoided that a chain of blocks is altered beforehand. The dishonest sender is persistently producing a transaction which he is about to proceed shortly afterwards. Once this has been executed, this sender starts working covertly on a substitute transaction. Meanwhile the recipient waits until this transaction has been added to a block and all subsequent ones have been connected. The exact content of the attacker s work is not revealed to the receiver. Should the time per each genuine block be as awaited, the attacker s improvement will be a Poisson distribution: λ Assuming the attacker is continuously progressing, the Poisson density is multiplied for each amount of progress that is made at that very moment: λ 0 1 Rearranging to avoid constituting the infinite tail of the distribution... 7

8 Converting to C code... #include <math.h> double AttackerSuccessProbability(double q, int z) { double p = q; double lambda = z * (q / p); double sum = 1.0; int i, k; for (k = 0; k <= z; k++) { double poisson = exp(-lambda); for (i = 1; i <= k; i++) poisson *= lambda / i; sum -= poisson * (1 - pow(q / p, z - k)); } return sum; } We can finally learn the probability declining exponentially with z. q=0.1 z=0 P= z=1 P= z=2 P= z=3 P= z=4 P= z=5 P= z=6 P= z=7 P= z=8 P= z=9 P= z=10 P= q=0.3 z=0 P= z=5 P= z=10 P= z=15 P= z=20 P= z=25 P= z=30 P= z=35 P= z=40 P= z=45 P= z=50 P=

9 Solving for P less than 0.1%... P < q=0.10 z=5 q=0.15 z=8 q=0.20 z=11 q=0.25 z=15 q=0.30 z=24 q=0.35 z=41 q=0.40 z=89 q=0.45 z= Conclusion This paper introduced a new system concerning electronic transaction save a third trustworthy party. At the beginning the common transaction of coins made from digital signatures has been presented. This method offers a sound control of proprietorship. However it is incomplete as it does not provide means to stop double-spending. As a solution to this problem this paper introduces a peer-to-peer network using proof-ofwork to establish a public history of transactions. In this way it will be computationally impossible for an attacker to alter authentic nodes as long as these control a majority of CPU power. This network provides a very sound basis because of its inherent unregulated structure. Nodes work simultaneously with hardly any coordination. Their identity does not have to be verified as their messages are not routed to any place in particular. They only have to be delivered the best way possible. Nodes can come and go to the network arbitrarily, accepting the proof-of-work chain as a verification during their absence. They rule with their CPU power, showing their acceptance of valid blocks by extending them and rejecting invalid blocks by refusing to work on them. Any rules and enticements necessary can be administered by this system. 9