DRAFT P2P TRADING OF BITCOIN PAGE 1

Transcription

1 Creating a Peer to Peer System for Buying and Selling Bitcoin Online DRAFT.1 By Rizwan Virk, 2013 riz@alum.mit.edu Table of Contents Introduction... 2 Overview of the Problem... 3 Parts of a Transaction Anatomy of Trades Today... 4 Where are Trusted Intermediaries Truly Needed?... 6 Can you replace Trusted intermediaries with P2P System?... 9 The Thorny Problem of Peer to Peer Escrow The special case of dishonest buyers and sellers and dispute resolution Disputing a Transaction and a p2p reputation system Conclusion DRAFT P2P TRADING OF BITCOIN PAGE 1

2 Introduction The introduction of bitcoin and other peer to peer crypto currencies lays out the possibility of a brave new world of money and commerce. In this decentralized model, banks play no role in the storage and transfer of the currency itself, and governments play no role in determining how much currency is issued, or to whom. Because the currency doesn t rely on any centralized trusted intermediary, like a bank or an exchange, transactions are conducted directly between individuals who wish to exchange goods or services for the currency. However, while it s true that trusted intermediaries aren t needed to transfer bitcoin from one account to another, practice, though, for a user to buy bitcoin using fiat currency such as US dollars, or to sell bitcoin to get dollars, some intermediaries are almost always needed. These intermediaries are websites and exchanges that users must sign up for accounts with to accomplish the finding of other bitcoin owners/buyers to transact with and to help facilitate the transaction. In particular, buying or selling bitcoin online is a difficult process without a trusted intermediary to 1) find other bitcoin owners, 2) to hold the assets in escrow while waiting for payment, 3) to confirm that payment has been made, and 4) to release the assets once payment has been made,and to mediate disputes. This paper asks whether a fully peer to peer system can be implemented to buy and sell bitcoin online in exchange for fiat currency, without the need for any additional bitcoin specific trusted intermediaries, and it lays out some guidelines for how such a system might be implemented. Since existing fiat currencies already have a financial system setup, it is assumed that the fiat portion of the transaction can happen using those existing systems. Like the transfer of bitcoin itself, which is implemented by adhering to a particular peer to peer protocol, this paper tries to answer the question of whether a peer to peer protocol can solve the problem of exchanging bitcoin for fiat currency online. For this paper, we will restrict our discussion to a peer to peer system to allow end points, or users, to find and exchange bitcoin or other virtual currencies for fiat currency (US dollars) online. While trusted intermediaries are needed much less for local in person transactions exchanging cash for virtual currency, even these situations usually require some element of a trusted intermediary to find local actors to transact with, and typically to provide escrow or other such services. DRAFT P2P TRADING OF BITCOIN PAGE 2

3 Overview of the Problem The problem with using trusted intermediaries for any part of this process is that it leaves the system vulnerable to regulation and can be shut down. This has already been seen with many online sites/exchanges being shut down or requiring more personal information for validating identify before allowing trading of bitcoin. Some sites, have had difficulty transferring fiat currency back to users because of toughening financial regulations, particularly in the United States. Thus, though bitcoin and other crypto currencies were meant to be a peer to peer system for the frictionless transfer of payments, in practice using these currencies online usually requires trusted third parties necessary to acquire bitcoins, exchange them for goods or services, to find trading partners, and to sell bitcoins. The reason for this is that there are many problems with implementing a pure peer- to- peer system for exchanging bitcoin for fiat currency, including: 1. Finding partners to trade with without a centralized database of buyers and sellers. 2. Negotiating a price without a centralized website. 3. Transferring Bitcoin to some escrow process without a trusted third party escrow agent. 4. Negotiating a method of payment for the transfer of fiat currency online. 5. Transferring the fiat currency from buyer to seller via some online method. 6. Verifying the fiat currency has been exchanged. 7. Releasing the Bitcoin from escrow to the buyer upon verification. 8. Disputing charges if the transaction goes south for some reason. Not all of these problems can be addressed technologically, as some are inherent in today s financial system (including existing methods for transferring money online, and allowing for returns and disputes if credit cards or paypal are used as the transfer mechanism), and some are inherent in the process of escrow itself. Parts of a Transaction. To solve this problem in a general sense, where currency 1 (let s say bitcoin) is being transferred by a seller to a buyer, in exchange for payment in fiat currency 2 (US Dollars). Let us call the currency to be transferred the asset currency (bitcoin), and the currency to be used to pay for it the payment currency (USD). Let us assume that transactions occur in phases: Setup Phase- involves getting set up to do transactions. In the bitcoin world this usually means having a wallet, but it usually also means creating accounts/registering on existing third party sites and exchanges. DRAFT P2P TRADING OF BITCOIN PAGE 3

4 Discovery Phase involves broadcasting that a user would like to be a buyer or seller in a trade. It also involves finding a partner. Negotiation Phase involves agreeing on a price in payment currency and amount of asset currency to be transferred. This also involves agreeing upon the method of payment for the payment currency. Implementation Phase involves transferring payment currency to the seller, and the asset currency to the buyer, usually via some escrow process. The fundamental reason a trusted third party is needed during this transaction is specifically because the parties of the transaction may not trust each other. In fact, one of the problems with buying or selling bitcoin using credit cards or other traditional electronic methods of payment (other than cash) is that the buyer can cancel the transaction after its done via their financial institution. But the bitcoins transaction is final and cannot be reversed. For a peer to peer system to encapsulate this entire collection of phases, there must be a way for each side to find the other, confirm that the transaction is complete and irreversible, and potentially use a third party escrow agent, or have a way for buyers and sellers to validate trust- worthiness. All of these traditionally involve trusted third parties. Anatomy of Trades Today Let s start with a simple transaction where the seller/buyer find each other online, but conduct the transaction in person. Here are the basic steps: 1. Setup Phase. a. Both sides need to have bitcoin wallets. b. Usually, finding one another almost always requires registering with an address on some exchange and this may also require validation of bank accounts, etc. with that site or exchange. 2. Discovery Phase. a. If Buyer initiated: (reverse for Seller initiated) i. Buyer advertises at an online site declaring they want to buy up to X bitcoins. ii. Seller peruses the site and sends a message to the buyer saying that he wants to sell bitcoins. 3. Negotiation Phase. a. Buyer and seller agree on a price, amount of coins, and a place to meet. 4. Implementation Phase. a. Buyer may require seller to place bitcoin into an escrow account (held by a trusted third party). b. Buyer gives seller the payment currency in cash. DRAFT P2P TRADING OF BITCOIN PAGE 4

5 c. Seller transfers the asset currency to the buyer s account (possibly from an escrow account). Because the buyer and seller are physically in the same location, the chances of one party or another backing out are small. If the buyer doesn t provide the payment currency, then the assets (which may be in escrow) are never released to the buyer, and revert to the seller. It is possible, though unlikely, to cheat in an in- person transaction like this. The seller can simply refuse to issue the bitcoin and run away with the buyer s money. The crux of the reason to have a trusted third party is to avoid a dispute, or to help in resolving a dispute. The reason the buyer will require the seller to put assets into escrow before giving payment is to be sure that even if the seller runs away, he will no longer have the assets, creating a disincentive for a dishonest seller. Also, if the buyer never gets the assets, he can complain to the trusted third party and ask for his money back, which won t work in a local cash transfer situation. Let us now consider an entirely online transaction between two trading partners. We will add milestone markers to mark the discrete points in the transaction. We can then see if a purely peer to peer system would allow the transaction to reach these milestone markers. For Markers, we will use the format Marker XX (Person- Label) where XX is an optional number (not needed to identify the marker but useful in a sequential list), and the marker name is a combination of Person and Label. Label is a descriptive label, and Person is the actor(s) who are responsible for reaching the marker. Person can be one of the following: Buyer, Seller, Initiator (could be Buyer or Seller depending on who initiated the trade request), Tradee (could be Buyer or Seller), or Both, or Escrow. 1. Setup Phase a. Buyer and seller set up accounts on third party websites, using , and often some method of verification. (Marker 0: BothAccountSetup). 2. Discovery Phase a. Initiator advertises that he wants to buy or sell bitcoin online and the method of payment he will accept (Marker 1: Initiator- OpenTradeRequest). Trade Status is Open. b. Trading Partner sees transaction and decides to respond 3. Negotiation Phase a. Tradee proposes how many bitcoins he is willing to sell or Buy aand the specific price (Marker 2: Tradee- Proposal) b. Initiator then accepts the price (Marker 3: Initiator- ProposalAcceptance) or rejects (Marker 20: Initiator- RejectProposal). DRAFT P2P TRADING OF BITCOIN PAGE 5

6 If the trade is at marker Initiator- ProposalAcceptance, then this Trade s Status is changed to pending until the implementation is done, or the trade is taken off of the market. If multiple sellers reach Marker: Tradee- Proposal, then first one to reach Marker 5(Initiator- ProposalAcceptance) is considered the winner. If the Initiator rejects the proposal, then we reach the first of a special set of markers which means that the negotiation or trade has ended. We ll start these markers at a higher number, Marker 20:initiator- RejectProposal. 4. Implementation Phase: a. Seller places asset currency in escrow Marker 4(Seller- AssetEscrow) b. Buyer sends payment to seller using agreed upon payment method Marker 5(Buyer- PaymentInitiated). If Buyer does not reach Marker (Buyer- PaymentInitiated) within a certain period of time, then the transaction reaches Marker 21(Buyer- AbortedPrePayment) and the transaction has been considered abandoned by the buyer, and the trade status is moved from Pending to Open i.e. the trade is re- opened. c. If the seller does receive the funds, the seller reaches Marker 6 (Seller- PaymentConfirmed). d. If Marker (Seller- PaymentConfirmed), is reached, then the escrow agent releases the assets, Marker 7 (Escrow- ReleaseToBuyer). e. If the Seller has not received payment after a pre- determined time after the Buyer has initiated payment, then Marker 23(Seller- NoPaymentReceived) is reached, and the trade status ithin a certain number of days, then the transaction is considered in dispute, reaching Marker 12(Escrow- Dispute). f. If Buyer paid through a traditional source, he can cancel payment, and then we reach Marker 23(Both- BuyerRefunded), and this also leads to Marker (Escrow- Dispute). Each of these markers is a discrete state and the flow of the transaction can thus be described as a finite state machine with the two parties in the trade initiating the transition from one state (or Marker) to another. You can see that a trusted intermediary is important for some, but not all, of the steps of an online bitcoin trade. There are many points where an intermediary is currently indispensible. Let s go through these points and see if we can replace trusted intermediaries with a peer to peer system or protocol. Where are Trusted Intermediaries Truly Needed? Note that though trusted intermediaries are used at many points in the life of a transaction, they are really only indispensible on certain markers. DRAFT P2P TRADING OF BITCOIN PAGE 6

7 In considering how to implement a purely peer to peer system, it is important to distill the process down to where a trusted intermediary is truly needed, and where the process can proceed without one. Then, if we can find peer to peer solutions for those situations, it may be possible to dis- intermediate the intermediaries. In the following table we identify if an intermediary is needed for a certain marker and identify a peer- to- peer need that must be filled to get rid of the intermediary. We will identify the specific needs of a peer to peer solution as p2pneed X (requirement). Marker Nature of interaction Peer to peer Comments Marker 0 (Both- AccountSetup) Currently this is done one the web. In a peer to peer system, the wallet may be enough to identify Marker 1 (InitiatorOpenTradeRequest) Buyer à Trusted Intermediary Buyer posts on a website or tells an exchange that they are interested in a transaction. Marker 2: (Tradee- Proposal ) Seller à Trusted Intermediary à Buyer Marker 3 ( Initiator- ProposalAcceptance) Seller ß à Buyer TrustedIntermediary Needs to mark trade as pending and stop other trades from responding. Initators and Tradees. Currently an intermediary is needed either an exchange to act as a market- maker or a matchmaker. In a peer to peer system, this would be p2p need 1 (BroadcastDiscovery) Intermediary is not really needed at this phase, as long as the seller can accept a trade request with an address of the buyer. p2p need2 (Secure Messaging) p2p need 2- (Secure messaging) (p2p need3- BroadcastTradeStatus) If a system can be implemented for broadcasting trades, it can be used to publicy update the status ofa trade. DRAFT P2P TRADING OF BITCOIN PAGE 7

8 Marker 4 (Seller- AssetEscrow ) Marker 5: (Buyer- PaymentInitiated) Marker 21: (Buyer- AbortedPrePayment) Marker 11: (Escrow- RefundtoSeller) Marker 6: (Seller- PaymentConfirmed) Marker 10: (Escrow- ReleaseToBuyer) Intermediary is trusted to put the assets in escrow so that the buyer can safely send payment. Buyer needs a way to send the payment to the server. ThirdPartyBanking Intermediary Needed, Intermediary is trusted to reverse assets if Marker ( Buyer- PaymentInitiated) hasn t been reached within a certain amount of time. Since the confirmation of payment happens outside the system, the seller usually tells the intermediary that payment has been received, and then the intermediary releasese the assets from escrow o p2p need4- (transfer assets to escrow). Existing online systems put the selling assets into an escrow wallet. To accomplish this via peer to peer is a thorny but indispensible issue, addressed below. o p2p need 5- (sending a payment.) This may not be possible to do without intermediaries, but we can get around this by letting buyers and sellers use whatever intermediaries they like in the traditional system (paypal, wire transfer, etc.) p2p need 6 (release escrow- seller). The system would have to be set up in such a way that if the buyer had not reached the Buyer- PaymentInitiated, within a specified timeframe the buyer agent/software would automatically give permission for escrow to be released. P2p need 7 (release escrow- buyer) The system would need to automatically release the assets if Marker 6 (Seller- PaymentConfirmed) has ben reached. DRAFT P2P TRADING OF BITCOIN PAGE 8

9 Marker12 (Seller- NoPaymentReceived) Marker 12- Escrow- Dispute The trusted intermediary would need to see information from buyer and confirm if payment has been sent and if seller is dishonest or has actually not received the funds. A trusted intermediary is usually essential at this stage. In existing systems, the buyer can ask for a refund via existing financial institutions, or the seller can ask the intermediary for the assets back from escrow. P2p need 8 (initate dispute) If seller cannot confirm payment within a period of time, then a dispute condition has arisen. A p2p system needs to be able to put a transaction into a dispute state and provide conditions for resolving the dispute. Either the seller or buyer must be able to put the system into dispute and the two must be able to work together to resolve, or to find a way to flag sellers or buyers (p2p need 9 settle dispute) and (p2p need 10- reputation system) Can you replace Trusted intermediaries with p2p systems? In examining these markers and the role of trusted Intermediaries, the question rises: is it possible for a peer to peer system (such as the bitcoin network of clients, or other peer to peer systems) to solve the p2p needs of doing online transactions for bitcoins without trusted intermediaries? Let s examine the p2p needs one by one and comment on them, and to name the system or subprogram that could possibly take care of such a function, with some high level notes on how it might be done. If it cannot be done in a purely p2p approach, perhaps there are ways to enable the protocol to allow disinterested third parties which are chosen at random from super nodes to assist in a transaction. Alternatively, there may be ways to reduce the motivation of dishonest actors to act dishonestly, which makes honest transactions much more likely. DRAFT P2P TRADING OF BITCOIN PAGE 9

10 We refer to clients which are used today as bitcoin clients, and those which might be enhanced to allow peer to peer trading (buying and selling) as bitcoin trading clients. In reality, the trading client would be software could be appended to an existing client such as MultiBit, or a separate client altogether. P2p need: Description of Need How could it be resolved? p2p need1: (Broadcast System) Need a way for bitcoin holders (wallets) to broadcast the intention to do a trade to either buy bitcoin or sell bitcoin. Moreover, by identifying a trade request with a trading_id, the p2p system can update the status of the trade. Bitcoin already has a way of broadcasting transactions, which become part of blocks, and the full blockchain is available to all p2p clients.. A similar system could be used to broadcast trades requests as part of a trading- blockchain. Bitcion trading clients could see all open trade request, and allow specific wallets to respond to requests by adding to the trading- blockchain. Bitcoin wallets can be used as the starting point for a trade request or for responding to a request, so no new user id s are needed. The trade status would be updated as an update on the original trade in the same way that additional transactions are added to the blockchain and validated. This trading- blockchain doesn t need to be as large as the bitcoin blockchain. All trade requests could be limited in time (i.e. stay open for only 24 hours). After that, are trade requests are cancelled except those that have moved to status pending. By following this convention, there is no need for bitcion trading clients to download the whole trading- DRAFT P2P TRADING OF BITCOIN PAGE 10

11 blockchain, except when it is involved in a specific transaction and needs to go back to validate it. P2p need 2: Secure Messaging P2p need 3: (p2p Trade Sttus) Need buyer and seller to negotiate details of a trade, and to securely send the payment method and information to each other. Essentially same as p2p need 1 The need for excessive negotiation can be minimized by tightening the definition of the original trade request and limiting the types of trades it requests. Then, a response in the trading- blockchain can be restricted to an event which requires a status change of the trade request. However, the payment details do need to be sent from seller to buyer, so that buyer can send payment. For messaging, there are existing peer to peer protocols for sending messages between nodes. One of these could be used as the messaging protocol for the bitcoin trading client. Or a protocol like Bitmessage, which has a similar implementation as bitcoin could be used. Standard formats can be defined for the messages that are required for negotiation of price, amount, and for providing payment details. Assuming that the messaging is integrated into the trading client, it might be appropriate to allow for a more user friendly user- id for messaging than the wallet id, etc. Bitcoin trading clients will add to the trading blockchain, each new trade entry would reference back to the original trading transaction. DRAFT P2P TRADING OF BITCOIN PAGE 11

12 P2P need 4: Holding assets in escrow P2p need 5 Sending a payment p2p need 6 ( release escrow- seller) P2p need 7- If assets are bitcoin or other electronic currency, peers would need to agree to put them into newly generated escrow wallets, and on the protocol for releasing them. Assuming the purchasing of the asset is being done using fiat currency, this isn t a strict requirement of the p2p system. Addressed in the escrow section below. Proof of work can be used to validate which responses came first and are valid. Bitcoin already provides a method for doing this simply creating a new wallet and transferring the bitcoin from the seller to new wallet. However, the real question that needs to be resolved is: who owns the wallet? And under what conditions are the funds to be released from the escrow wallet to the buyer wallet. Or be reverted. In general, the seller s confirmation must be part of this process, or the buyer could get the assets without having sent payment to the seller. Ideally, the buyer s private key might also be needed or the seller could simply revert the assets to himself. Escrow issues are addressed in the next section. Existing financial systems can be used to send payments (paypal, bank transfers, etc.). All that is needed is: 1) Buyer to confirm that payment has been sent. 2) Seller to confirm that payment has been received. These shouldn t just be messages from buyer to seller, but should result in changes to the trade status. See below. DRAFT P2P TRADING OF BITCOIN PAGE 12

13 (release escrow- buyer) P2p need 8 (initiate dispute) P2p need 9 (settle dispute) P2p need 10 (reputation system) If buyer sends payment, but seller doesn t confirm, the buyer should be able to initiate a dispute. If buyer says that they sent payment, but the seller never receives the payment, then the seller should be able to initiate dispute. If the seller receives payment and bitcoins are transferred to the buyer, but the buyer somehow reverses the payment of fiat currency in the existing financial system. Initiating dispute would be a simple change of the trade status. Settling dispute would be more complicated and is addressed in the dispute section below. One way to help this process would be to have a peer to peer reputation system of buyers and sellers, and an easy way to see if a buyer or seller has had disputes in the past. One disincentive in a p2p system with no trusted intermediaries for dishonest actors is that bitcoins in dispute can be locked up via the bitcoin protocol and no longer used. The Thorny Problem of Peer to Peer Escrow The crux of the problem in implementing a truly peer to peer system for exchanging bitcoin for fiat currency is how to implement an escrow system using completely peer to peer methods? Setting up an escrow account is relatively easy a new bitcoin wallet can be created. The tricky part is to be sure that neither party can unlock the funds from escrow without signoff from the other party. 1. Third party escrow services, peer to peer. One possibility is to have third parties in the peer to peer network offer to become the escrow agent and mediate disputes. This could be done with some economic incentive for the escrow agent (.001 BTC for example). This however, still requires trusted intermediary, even thought he intermediaries are other nodes in a peer to peer network. 2. A technical solution to two party escrow and public/private keys. If the seller has the ability to unlock the escrow account, then the possibility exists that he will revert funds to himself, in a dishonest transaction so this is unacceptable. If the buyer has the ability to unlock the escrow account, then the possibility exists that he will take the goods before sending payment. DRAFT P2P TRADING OF BITCOIN PAGE 13

14 One approach would be to set up e escrow wallet (another peer to peer node in the network), but immediately encrypts this key using the public key of the seller, and then encrypts the resulting code using the public key of the buyer to get the seller- buyer encrypted code. Similarly, the same private key of the escrow account is encrypted first by hashing the buyers public key and then the seller s public key. this results in the buyer- seller encrypted code. So there are now two values, both of which have the private key of the escrow account, which can be used to release funds.: - BS code: buyer- seller encrypted key. - SB code: seller- buyer encrypted key While the buyer, using his public key, can unlock the SB code, he will get a value hashed with the public key of the seller and cannot use it. The seller cannot unlock the SB code at all, since it requires the private key of the buyer. Conversely, the seller can unlock the SB code, but will get a value that is hashed with the buyer s public key, and he will be unable to do that. In an honest transaction, at some point, once the seller confirms payment has been received, then he will unlock the BS code, and send the resulting value to the buyer. The buyer can then use his own private key to unlock the escrow account, and can then initiate the transaction to transfer from the escrow account to the buyer s own wallet. Since two keys are naturally required to unlock the escrow account key, this leads to several unique new problems: 1. Ensuring that the party which generates the escrow account doesn t store the escrow key, but just the SB or BS code. 2. A negligent buyer. If the buyer doesn t indicate that payment has been initiated within a certain timeframe, we need a way for the seller to get the bitcoin out of escrow.. 3. A dishonest seller or buyer. a. If the Buyer says that payment was initiated, but the seller never received it (Marker 22: Seller- NoPaymentReceived). This could result from either buyer being dishonest (never initiated the payment), or the seller being dishonest (receiving payment but not wishing to reveal it). 4. A dishonest buyer after- transaction reversal. Using established methods of returns in the legacy financial system, a buyer could ask for his or her money back after the transaction is complete. Point #1 must be addressed in implementation and part of the protocol. However, there should be no way for the seller (or buyer) to be able to also have access to the device or node which creates the escrow account. This would mean that the private DRAFT P2P TRADING OF BITCOIN PAGE 14

15 key of the escrow account is essentially lost except for the hashed versions of it which are sent to the buyer and seller (SB and BS). Actually there may be a way to address this within the bitcoin protocol itself. a bitcoin transaction actually requires not simply a private key to unlock the hash, but an algorithm or script that must check for equality. According to the specification, it is possible for this script to require two private keys to complete the transaction. This is a promising way to do escrow without requiring a separate escrow account. Point #2: A negligent buyer is one who doesn t initiate payment within a certain period of time. If this happens, the seller needs to get back the bitcoin from escrow and the trade is considered cancelled. One way to do this would be to define a way that the transfer to escrow is considered not confirmed until a certain period of time. Of course the blockchain can show if the seller attempts to double- spend the money within this time. It s also possible that the software itself could handle the negligent case - the buyer s software agent, if the buyer hasn t reached Marker 5: Buyer- InitiatedPayment within a certain amount of time after transaction, could automatically unlock the SB key and send it to the seller s agent. However, this brings up an important point of the escrow account being abandoned and the bitcoin are essentially in limbo if certain markers are not reached in the transaction. The default way to solve this is that the bitcoin get transferred back to the seller if the transaction has not proceeded to an appropriate marker within a certain period of time. In terms of how this is accomplished, again it could be done via making the transfer to escrow a non- confirmed transaction, or by the trading software itself which the buyer or seller is using. The special case of dishonest buyers and sellers and dispute resolution If buyer and seller could be assumed to be truthful in sending and receiving payment, then the rest of the system might function well in a peer to peer environment. The main problem involves the cases of dishonest buyers and sellers. In most cases, a dishonest buyer or seller would want to cheat the other party i.e. get the assets without sending money, or get the money without sending assets. The incentives for buyers or sellers to be dishonest can be reduced or nullified using a full p2p escrow system in most cases. Furthermore, a p2p reputation system involving either the actors or the bitcoins themselves could be used to discourage such behavior. A dishonest buyer might tell the seller he has initiated payment, thus the transaction reaches Marker 5, BuyerInitiatedPayment, but he hasn t actually initiated payment. DRAFT P2P TRADING OF BITCOIN PAGE 15

16 Since the Seller must confirm receipt of payment for the transaction to move forward, there is no benefit for a dishonest buyer to claim they have sent payment but not to send it. He or she will never receive the bitcoin in this way; they will still be in escrow, so there is no economic reason for a buyer to do this, unless they are simply trying to get the seller to unload his bitcoin. However, it is possible that a dishonest seller will receive the payment but will not acknowledge receipt. Again, since the buyer s and seller s private keys are required to unlock the bitcoin to transfer it back to the seller or to the buyer, then there is no economic incentive for the seller to not be honest about receiving payment. In this, we may find that one of the main difficulties in trading fiat currency using existing financial systems for bitcoin may actually become a saving grace. In this case, since the dishonest seller is unwilling to release the bitcoin to the buyer, the buyer can simply reverse the transaction on his credit card or paypal or wire transfer. In this isolated case, the large infrastructure for reversing transactions, seen as a disadvantage in the bitcoin world, can actually prove useful. The final case of a dishonest actor would be after the seller has acknowledged receipt and the bitcoin have been released from escrow to the buyer, if the buyer attempts to reverse the financial transaction after the fact. This has happened before in the bitcoin world, which is why some sellers are unwilling to sell via paypal. However, many others are willing to sell via paypal so it s possible this is a smaller problem than some suppose. In this case, a few more items would be needed, since bitcoin transactions are generally irreversible. This would be the classic case of a disputed transaction and exists in all online bitcoin purchases whether they are done through a trusted intermediary website, peer to peer or not. Disputing a Transaction and a p2p reputation system While any case of dishonest actor could be used to change the transaction status to dispute, there is no economic incentive for dishonest actors to handle the first two cases involving dishonest payment (i.e. mark trade as BuyerPaymentInitiated without initiating it, or receiving payment but not marketing the transaction as Seller- PaymentConfirmed). In a p2p system, we could let either the seller or the buyer mark the trade as moving into dispute, and the escrow account thus becomes a disputed account in both of these cases. DRAFT P2P TRADING OF BITCOIN PAGE 16

17 The single case where there is an economic incentive for a dishonest actor would be for the buyer to try to reverse the financial transaction using methods already in place in the existing fiat currency financial system after he or she has received the bitcoin. As we mentioned, this is the case today when finding trading partners online using websites as trusted intermediaries, so it is not unique to a peer to peer system. One approach to handle this general case, we could let the seller mark the bitcoin in question as disputed and since the transaction history of bitcoin can be inferred from the blockchain, this would mark it as dirty currency. The disincentive would have to be strong enough to get a buyer to not act dishonestly after getting the bitcoin. The strongest disincentive would be for disputed bitcoins to not be accepted by any clients, effectively orphaning them. This might require a change of the implementation, but it could also require adding some logic of the script that would be required for the transferring of these bitcoins in the future in its subsequent transaction records in the blockchain. Another approach might be to use a p2p reputation system for traders, but the wallets themselves are not sufficient identification to be used. Each client would have to be tied to a username or account. Of course, while disincentives exist in this system for buyers and sellers to act dishonestly, this doesn t fully address the idea of a malicious actor. A malicious seller might want to put his bitcoin in escrow, get the money, and not let the buyer get access to the bitcoin. In this case, the buyer could reverse the transaction so a malicious seller isn t really a problem. While the disincentive of putting the bitcoin out of circulation or marking them as tainted would discourage a dishonest buyer, it might not stop a malicious buyer from doing it anyways, ok a malicious seller from claiming that the buyer reversed payment even when the buyer did not. We now come back to the need for some reputational element in the system or a third party to mediate. Conclusion Today, while bitcoin can be transferred in a completely peer to peer way, the buying and selling of bitcoin for fiat currency online still requires the use of trusted intermediaries. While many of these are websites and even some VC- backed companies, they often require a significant amount of personal information for doing trades, and they still represent points of failure which would not exist in a purely peer to peer system. DRAFT P2P TRADING OF BITCOIN PAGE 17

18 Most of the needs of a bitcoin trade online can be accommodated by a peer to peer system, including broadcasting intent of trades, changing trading status, putting bitcoin in escrow and releasing them only upon. The cases of dishonest buyers and sellers can be reduced by providing no economic incentive in most cases, or by marking the bitcoin as tainted in other cases. While this paper wasn t meant to give an exact protocol for a peer to peer system for buyers and sellers to find each other, verify payment, and transfer into and release from escrow, the issues discussed here should help anyone wishing to implement such a system. There are still a few thorny issues, such as malicious buyers and sellers, so no peer to peer system can fix these issues in all cases, the logic suggested here should address them in most cases. DRAFT P2P TRADING OF BITCOIN PAGE 18