Hi benjyz, Giannis, Tom, woolly_sammoth, Cybnate, desrever, CoinGame, pennybreaker, Ben and sigmike,
I have prepared a draft design of a decentralised exchange that would be a fork of the NuBit code repository. Before presenting it to the public, I would like your comments on it. Feel free to comment on the technical design, how you think it will be received by our core community as well as the broader Bitcoin community, what the major risks and barriers to project success are, what effect you think it will have on the NuShare price, how effective you think it will be as a vehicle for cheap NuBit liquidity, etc.
Here it is. Sorry in advance for the poor Bitmessage formatting:
Bitswap: A decentralised exchange built on the Peershare platform
The arrival of a decentralised exchange has been eagerly anticipated within the cryptoasset community. Exchange hackings and defaults have been a major problem discouraging use of cryptoassets. To date, no decentralised exchanges have emerged. There are a number of networks such as NXT Multigateway, Bitshares and Ripple that allow the exchange of proxy assets, but they do not facilitate direct exchange of real blockchain Bitcoin, Litecoin or NuBits. SuperNET, while placing real blockchain assets under multisig escrow, still plans to use a proxy asset on NXT Multigateway for actual trading. This means the number of NXT proxy assets cannot equal the number of assets in multisig escrow. A NXT proxy asset may not be backed by and made exchangeable for real blockchain assets.
I will present the design for Bitswap, intended to be the first decentralised exchange where real blockchain assets are traded and where the chances of theft and default will be orders of magnitude lower than traditional centralized exchanges. Bitswap will add tremendous value to the Nu network because it can be used to provide very cheap and secure NuBit liquidity. Multiple LPCs will make it the primary place the NuBit peg is kept. The costs of exchange default risk will be almost completely eliminated. For this reason, I believe it is in the interest of NuShare holders to fund its development in exchange for giving most of the initial Bitswap equity to NuShare holders. The funding proposal is detailed in the funding section below.
First, let's take a brief look at the system from a user perspective, and then I will provide a summary of the architecture. Sam thinks the price of Bitcoin is headed down in the short term, so he would like to exchange his Bitcoin for stably priced NuBits. He can choose to do this on Bitswap using either a desktop client or a web client. Let's assume Sam is using the desktop client. An exchange account is a public / private Bitswap share key pair, which is created by default upon client start up. Sam transfers a small quantity of Bitswap shares to his address to be used for exchange transaction fees. He then associates a Bitcoin deposit address with his Bitswap address, simply by selecting Bitcoin from a drop down list and clicking a New Address button. Sam transfers 1 BTC to his Bitcoin deposit address. He adds a NuBit withdrawal address which is under his control. After his Bitcoin deposit has 3 confirmations, Sam then enters an order for 250 NuBits at 250 on the BTC/NBT trading pair. Once this order has three confirmations on the Bitswap blockchain (taking 2 or 3 minutes), the trade occurs because there is a buy BTC limit order on the order book that immediately matches Sam's sell BTC order. All the reputed signers for Sam's Bitcoin deposit address can see the order match, and they sign and broadcast a transaction transferring the Bitcoin from Sam to the buyer's Bitcoin withdrawal address. Similarly, reputed signers transfer NuBits from the seller's NuBit deposit address to Sam's NuBit withdrawal address. Within seconds, Sam receives direct possession of his NuBits at his NuBit withdrawal address. He has paid a small transaction fee in Bitswap shares when he requested a deposit address, a withdrawal address and placed an order. The actual fill was free of charge.
Summary of Architecture
The infrastructure required for the exchange to function are Bitswap peers with reputed signers also needing to run clients of foreign blockchains for which they sign. There are no privileged nodes, although certain Bitswap addresses will be assigned a reputation score by minters, and those with the best reputation will be chosen by default as deposit address signers. Deposited funds will be quite safe because they will be controlled by a network configurable number of reputed multisig signers. In order for funds to be lost in the case of a 8 of 15 multsig deposit address, 8 reputed pseudonymous signers would need to conspire to steal funds or 8 signers would need to fail to sign valid transfers. A good reputation score permits a future and ongoing income doing nothing more than running a Bitswap client and in most cases one or more foreign blockchains, so signers will have incentive to act in a responsible, predictable and reliable manner to maintain their reputation, which is adjusted every minute. Reputed signers may place a security deposit of funds held by other reputed signers, typically in Bitswap shares. If shareholders felt a reputed signer engaged in misconduct, a motion could be passed to burn part or all of their security deposit. Before having their security deposit returned in the event of winding down operations, the reputed signer would need to prove the signing keys have been transferred to another reputed signer. A highly responsive reputation system combined with security deposits and a tolerance of up to 7 rogue reputed signers in the case the network is configured to use 8 of 15 multisig addresses means the chance of exchange default is exceedingly low.
There will be seven types of new messages placed on the blockchain as OP_RETURN transactions. Each of these will be accompanied by a transaction fee (which is burned as network revenue) except the fill message (which is unsigned):
Reputed signer deposit public key list
Non-reputed signer deposit address request
Non-reputed signer withdrawal address request
Fill (not signed and no transaction fee)
Withdraw from deposit address
The current 80 byte limitation on OP_RETURN should be removed, leaving the existing size restriction that a single transaction can't consume more than 20% of a block.
The only distinction between a reputed signer and a non-reputed signer is that by default a client will select signers with the highest reputations to have control of their deposit addresses, although any combination of signers could be chosen manually by RPC. This means non-reputed signers and reputed signers can do exactly the same actions, making them true peers. However, in general, only reputed signers will sign deposit addresses. In order to sign for foreign blockchain deposit addresses, a client must be connected to the foreign blockchain. One signer may choose to sign for Bitcoin deposit addresses, which means his client must be able to connect to a Bitcoin client. Another signer may choose to only sign Litecoin deposit addresses, which means his client must be able to connect to a Litecoin client. People who just want to use exchange services don't need to have their Bitswap client connect to any foreign blockchain, such as Bitcoin or Litecoin.
The Bitswap code base will be a fork of the Nu 2.0 code base. Features of Nu that will be disabled completely:
park rate voting and parking
The following voting will be added:
uint16 number of confirmations required by blockchain ID
uint8 number of total reputed signers of deposit addresses
uint8 number of required reputed signers of deposit addresses to effect a transfer
Reputation voting will also be added, which consists of up to three upvotes or downvotes, each associated with a Bitswap share address. Details are included in the Reputation voting section.
All of the new voting types will apply a protocol rule that an abstention will be interpreted as the value currently enforced by the protocol. This means if a shareholder likes the current network settings, they should abstain from voting to prevent blockchain bloat. The median vote in the last 2000 blocks will be used. Like Nu 2.0, the protocol values applied to the current block should be the consensus 60 blocks deep, so that there is a time window in which the applied values can be predicted.
There will be a second block reward (in addition to the minting reward) given in a psuedo-random fashion to a single deposit address signer.
Reputation voting will also be added, which consists of up to three upvotes or downvotes, each associated with a Bitswap share address.
Transaction fees will be adjustable like Nu 2.0 but charged on a per byte basis instead of per kilobyte.
With these limited changes to the Nu code base, it is expected implementation of Bitswap will be easier than the original Nu network implementation. The majority of coding work will consist of processing the six new message types listed above.
In addition to the Bitswap solution being a fork of the NuBit code repository, the Nu production blockchain will also be forked. This will have no impact on the Nu network. All NuShare holders will receive Bitswap shares in proportion to their NuShare holdings. By doing this it is hoped that the Nushare holders will have incentive to provide initial funding for Bitswap development via the NuBit custodial grant mechanism, with the expectation that Bitswap shares will have value. Therefore, it is proposed that NuShare holders pass a custodial grant of 300,000 NBT to develop Bitswap along with a commitment to create and sell 50,000 NBT worth of NSR each month for 6 months to offset the NBT grant. Ongoing Bitswap development would be funded with grants of Bitswap shares, which will work the same as NSR or NBT custodial grants. This means initial distribution of Bitswap shares is fully automated and very straight forward. It is really just a separate copy of the Nu network, communicating on different ports with a substantially modified protocol.
It is expected that the initial Bitswap shares will be created when the network is ready for exchange operations. So, the best way to receive the first Bitswap shares will be to purchase NuShares. It is expected that the initial Bitswap market cap will be priced into the NuShare market cap prior to the creation of the Bitswap blockchain. For example, if the market prices the value of Bitswap at 5 million NBT at the time of launch, then we could expect that entire valuation to be contained in the NuShare market cap just prior to launch. The NuShare market cap may fall a little after Bitswap is released, but its enduring value will be tremendously enhanced as Bitswap provides an extremely cheap and secure way to provide NuBit liquidity and defend the peg. A fall in the NuShare market cap just after granting Bitswap shares could be mitigated by awarding Bitswap shares to NuShare holders multiple times, for example, 3 times at 60 day intervals. In this scenario, Bitswap shares would be awarded to those who could sign a message from a NuShare address. Similarly, Bitswap shares could be awarded to Bitcoin holders by having them sign and broadcast a message signed by their Bitcoin address, which could be verified by the reputed signers that process Bitcoin deposit addresses. This would be done to enlarge the Bitswap community by providing a monetary to incentive to all Bitcoiners to promote and use it. In this way initial share distribution would be completely automated and a matter of protocol.
An exchange account is simply a Bitswap share address used for signing. No reputation is needed to effect trades. Deposit address requests, withdrawal address requests and orders (which are detailed below) are all signed using this key.
In order to prepare the way for deposits, some individuals must decide to become reputed signers for deposit addresses on one or more blockchains. Initially, it is expected that the Bitcoin, Bitswap and Nu blockchains will be supported, though many others will be added iteratively. A particular individual might choose to be a reputed signer for the Nu blockchain. To do so effectively, he will need to make sure his Bitswap client is always running and always able to connect to his Nu client. He will need to convince shareholders to upvote his reputed Bitswap signing address. This reputed address will only be used to sign reputed signer deposit public key lists, or deposit key lists to be brief. This is a blockchain record subject to transaction fees that contains the following information:
reputed public address of signer
signature using reputed address
a blockchain ID
an asset ID
a list of public addresses of the asset type referenced
When a reputed signer posts such a message, he is promising to keep the addresses listed in a wallet connected to the blockchain client referenced, which can in turn be contacted by his Bitswap client at all times in the future, except if he transfers the keys to another reputed signer as described in the Signer incentives section. Each address in the list may be used once and only once in a non-reputed signer deposit address request, or deposit address request to be brief.
When making a deposit address request, depositors can choose which reputed signers will handle their deposits and how many signers are required to move their funds. For ease of use, the network must automate these choices by default. Shareholders will vote on the default number of signers and the default number required to move funds (such as 4 out of 7 or 6 out of 10), up to 15. The default signers will be the ones with the highest reputation score (derived from upvotes and downvotes placed on the blockchain). The more signers there are the higher the fee will be and the more blockchain space is required.
A request for a deposit address will need be to broadcast through the network accompanied by a fee. The request will contain the public keys of the proposed signers. So through blockchain voting, shareholders may define defaults of 8 signers to move funds, 15 signers total. The default in effect will be determined by the median vote in the last 2000 blocks. If a shareholder likes the current network settings, he should abstain from voting for this and the protocol will interpret an abstention as a vote for the current median values.
So, from a user perspective a new deposit address for a specific exchange asset such as Bitcoin or NuBits is requested. That is all the end user needs to be aware of. The client can build the multisig deposit address locally using the public keys of the signers chosen. The deposit address request is broadcast and placed on the blockchain. It contains the following data:
multisig deposit address
public asset specific address of each reputed signer
asset ID (Bitcoin, NuBit)
signer address controlled by entity requesting the deposit address (used to sign orders); may be multisig; this is the equivalent of an exchange account
signature using the exchange account address
transaction fee as a burn
To construct this, a client must first determine which reputed signers it will use, which by default will be the ones with the highest reputation score. Once these signing candidates are determined, the blockchain must be searched for a deposit address list published by a particular signer which matches the asset ID of the deposit address request. An address must be confirmed to have not been used before, which means it does not appear in any other deposit address request on the blockchain. If a reputed signing candidate does not have an eligible and valid address the requester can use, another signer should be chosen (the one with the next best reputation).
The deposit address request will then be broadcast and the deposit address will be displayed in the local client. Reputed signers who have a key to sign the multisig address will broadcast a signed acknowledgement they have received the deposit address request (using their key for the deposit address, not their reputed address). Only valid deposit address requests with the required fee and only acknowledgements from the top 30 signers (by reputation score and per blockchain) will be broadcast by clients. The number of acknowledgements received will be displayed in the client next to the deposit address. Deposit address requests should be stored in the appropriate wallet of all reputed signers using the addmultisigaddress RPC. Acknowledgement counts and the public multisig address with blockchain ID and asset ID should be stored in the requester's Bitswap wallet. Once the deposit address request is broadcast and an acceptable number of acknowledgements have been received, the user can feel comfortable depositing funds to the multisig address. Discovering which reputed signers failed to acknowledge should be easy so they can be appropriately downvoted.
The protocol must ensure that each exchange account (Bitswap share address) is associated with at most one deposit address. Later iterations of Bitswap will allow the account holder to change the deposit address.
Order books have been implemented in Ripple, NXT and Bitshares, so it is an established technology. For this reason a full specification will not be described here. The order book implementations of these networks should be studied and the best elements of each should be implemented. Order messages should contain the following data:
signature using the exchange account address
exchange account public address
numerator asset type
denominator asset type
quantity in numerator asset
buy or sell, in reference to the numerator asset type
order ID as random GUID (not subject to transaction malleability)
The protocol will ensure that the necessary deposit and withdrawal addresses to complete the order are associated with the exchange account. When an order is received, sufficient funds must be verified. Nodes that are signers of the appropriate deposit address (for buy orders it will be the denominator deposit address, for sell orders it will be the numerator asset) will broadcast a signed message confirming or denying sufficient funds for the order. They must check the deposit address for sufficient funds on the appropriate blockchain but they must also check the orders already in their memory pool and on the Bitswap blockchain and subtract the amount of those orders from available funds. Submitting multiple orders based on the same deposit is similar to double spends, and the same established techniques must be used to defend against it. Verification must be received from enough signers to accomplish the appropriate transfers from deposit addresses plus one signer in order to be valid. Ways to produce an eventual blockchain consensus in the case that a client does not receive this validations needs to be considered, because these validations are not placed on the blockchain. Perhaps an order with insufficient validations from signers should be accepted when the protocol required number of confirmations required on the Bitswap blockchain have accumulated. For instance, if shareholders are currently voting for this to be six blocks, a poorly connected client that didn't receive enough validations might fork for six blocks, but then join the main chain again.
Just like deposits will only be considered valid with a minimum number of confirmations as a matter of protocol, an order will only be considered valid with a minimum number of confirmations as a matter of protocol. The relevant minimum number of order confirmations is the voted setting for the Bitswap blockchain.
Of the seven new types of messages included in Bitswap, fills are the only message type that isn't signed. This is because fills are merely the consequence of matching orders. Each node has all the information (from the blockchain) it needs to determine an order fill is occurring, so order fills do not need to be broadcast. They should simply be added as an OP_RETURN transaction to the memory pool by all clients. The protocol should permit zero transaction fees for valid order fill transactions. This won't allow for abusive overuse of blockchain space because orders must be paid for, which are the only thing that can result in order fills.
Order fills need to be placed on the blockchain because they impact the validity of orders. The network is unable to rigorously track the validity of orders without a blockchain record of order fills.
Each time an order is received, the order book will be checked to see if there is a matching order on the books. If one is detected, then an order fill transaction will be created by the client. An order fill message references exactly two signed orders and contains exactly two transfer messages. A transfer message consists of the following data:
source order ID
destination order ID
There is a risk that not enough signers for one transfer will be available at a particular time, but enough will be available for the complimentary transfer. This would result in one exchanger receiving value without paying the other exchange partner. To prevent this, signers must confirm they are ready and prepared to sign just before an order fill is considered valid. Therefore, when matching orders are detected the appropriate wallet must be checked to see if the client is a signer for the order fill. If they are, they must sign a message indicating they are prepared to sign the transfer and broadcast it. For an order fill to be considered valid, the client must have received signed validations enough signers to transfer plus an alternate signer. The same rules as described in the Orders section should be applied to ensure transactions will be signed and that consensus is maintained long term.
Signed multisig messages that do not yet have enough signatures can be broadcast through the network if the message is signed using the key that is part of the multisig address. This broadcast but off blockchain message should include the the signed raw transaction with metadata about who has signed it. Specifically, it should contain the multisig deposit address, as well as a list of all addresses that have signed it.
Is there any permanent record of an order fill besides the blockchain transfer of assets? Yes, order fills should be placed on blockchain, because it lets nodes know if orders are relevant or partially relevant.
A cancel order is broadcast, placed on the blockchain, and requires a fee. It contains the following data:
order ID of the order to be cancelled
signature of the exchange account used to sign the original order
Withdrawal address request
The withdrawal address request is broadcast and recorded in the blockchain. It contains the following data:
withdrawal address (may or may not be multisig)
blockchain ID (Nu, NXT)
asset ID (Counterparty, NuBit)
public address of exchange account; may be multisig
signature using the exchange account address
The protocol must ensure that each exchange account (Bitswap address) is associated with at most one withdrawal address. Later iterations of Bitswap will allow the account holder to change the withdrawal address.
Withdrawal from deposit addresses
An exchange account address can be used to broadcast a withdrawal request from the associated deposit address if a withdrawal address request with the same asset ID has been successfully included in the blockchain. While it is not really necessary for it to be in the blockchain, it is necessary for there to be a fee charged to prevent denial of service attacks, and the fee must be assessed on the blockchain. Therefore, a blockchain record with the following elements should be made:
address of exchange account
signature of exchange account
amount to be withdrawn
No confirmations are needed as the relevant blockchain can successfully handle multiple withdrawal requests that would constitute a double spend.
Reputed signer incentives
Each block will have a reputed signer reward given to a single signer. The signer will be chosen using the block hash of the block 60 blocks below the current height and the public key of the minter. When the minter uses these criteria to decide which signer receives the reward, it is functionally random but also verifiable by other nodes. The winning signer should be randomly chosen, but the selection of a winner cannot be verified as random if clients select a winner using a typical random number generator. A block hash is functionally random in this context and also verifiable by all nodes. Using only a block hash would allow signers to possibly predict if their transaction would be the winner of a particular block. Adding in the public key used to sign a block makes the value unknowable in advance to all besides the finder of the block. The finder of the block can only be a finder of that block, so they can't gain by trying to delay their transactions to be put in a later block, because they would lose the block minting reward. Like a block hash, a block minter address is known to all nodes so they can verify the random winner was chosen fairly. Public addresses can be thought of as being between a minimum and maximum value. The block hash should be divided so that the result always resides within the possible range for a public address. Then the divided block hash and public address of the minter should be added together and then divided by two. The result will be in the range of valid public addresses. The eligible signing address closest to that value gets the block reward. Each address that could have signed a reputed signer transfer is eligible to win. When a winner is chosen, the reputed signer that controls the winning address must be looked up on the blockchain, and that is the address that receives the reward. Transactions or message types that are eligible for the reward are deposit address requests,
fills and withdrawals from deposit address because these require action from reputed signers. It is the list of signers in a deposit address request that will be used to form a list of eligible winners. For fills, the two related deposit address requests will be used, and for withdrawals from deposit addresses the relevant deposit address request will also be used. When a signing public address is chosen as the winner, this address must be found in a reputed signer deposit public key list. The coinbase reward will be placed at the reputed signing address (this is the same share address that will be a target of upvoting and downvoting). The amount of the reward shall be 100% of the transaction fees paid by the three eligible message types. Other transaction fees will be network revenues.
If a signer wishes to cease operations, their private keys can be sold (they have value in proportion to the block reward it will earn). The new operator could then continue operations, although it would be possible for the original operator to also sign requests. Selling a signing key will accordingly reduce its value as it is likely to have its reputation reduced as a result. Signing key sales are likely to occur in secret as a result. If the original owner signs in addition to the new owner, this can be detected and shareholders will likely down vote the signing address. The risks involved in covert signing key sales are modest and are mitigated by the distributed trust model of using many signers.
Minting and reputed signing nodes
Minting nodes are such because they have Bitswap shares eligible for minting. Reputed signing nodes are such because they are capable of signing transactions on deposit addresses. A client may be neither a minting nor signing node, one or the other, or both. Furthermore, being a signing node will only be in reference to a specific non-native blockchain. So, a particular node may a Bitcoin signing node, but not a Peercoin signing node, while another node may play the role of a Bitcoin signing node, Peercoin signing node and minter.
Protocol changes regarding currency
The only native token will be Bitswap shares. Because NuBits will be in the copied Nu blockchain, all currency transactions will be prohibited by protocol. NuBits on the native blockchain will be ignored. NuBits on the original Nu blockchain will be handled just like any other blockchain such as Bitcoin or Litecoin.
Reputation voting and scoring
When a block is minted, the minter may enter up to three upvotes or downvotes, each associated with share address, presumably that of a reputed signer.
Voting would be weighted most heavily toward recent votes. The last 5000 blocks of votes would receive full weight, the next most recent 10000 blocks would receive half weight, and the 20000 before that would receive quarter weight.
Transaction fees will be variable and subject to shareholder voting, just as in Nu version 2.0. Transaction fees will be priced per byte, not kilobyte as in Nu. This creates the incentive to keep transactions small, even when below 1 kilobyte. Deposit address requests and multisig transactions are large in size, but typically under 1 kilobyte, so an incentive needs to be provided to use a more compact 3 out of 5 multisig rather than 10 out of 15 if it is demonstrated that the counterparty risk is similar.
Future business applications
The Bitswap architecture is well suited to provide reversible or escrowed transactions on any supported blockchain. It can do this without any prot
--- Display of the remainder of the message truncated because it is too long.
--- To see the full message, right-click in the Inbox view and select "View HTML code as formatted text",
--- or select "Save message as..." to save it to a file, or select "Reply" and view the full message in the quote.