Adding the content in relation to APIs

_pages/apis.md

@@ -0,0 +1,47 @@
+---
+layout: page
+title: APIs
+permalink: /apis/
+---
+* Chainspl.it provides five APIs to make life easy for wallets and exchanges.
+** Taint API
+This API accepts a small payment and a Bitcoin address. Once the payment is confirmed it sends a batch of 100 private keys. Each private key has a 1,000 satoshi balance that is tainted (only valid on one chain). By including a small amount of tainted Bitcoin in a transaction the entire transaction is only valid on the Bitcoin network (for a discussion of how the tainted Bitcoin is created see How we generate Bitcoin only transactions below). This splits your coins because the source address is still full on the fork network, but is emptied on the bitcoin network. 1,000 satoshis (about $.06) because smaller amounts will not be relayed by nodes as it is considered “dust.”
+The API provides a batch of single satoshi private keys for two reasons. First, if a larger tainted balance was provided to the exchange or wallet, all transactions sent by that wallet or exchange could be identified because they would include a satoshi from that issued tainted balance. Second, by providing the private keys directly, we avoid an additional network transaction.
+
+** Ignore For Now API
+When queried, this API responds with the ratio of UTXO size to UTXO balance that is currently economical to split. For example if the API returns 10 millibits per byte UTXOs that have a 11 millibits per byte should be split now, but UTXOs that have 9 millibits per byte should remain unsplit until the value of the forked coin increases or the network fees decrease.
+This ratio is calculated by evaluating the current market price for the forked coin and the current network fees that will be required to split the coins.
+
+** Delayed Relay API
+This API accepts batches of Bitcoin transactions and trickles them out to the network over a 12 hour period. This improves privacy when splitting coins because an attacker can infer ownership, even if UTXOs are not combined, by looking at the timing of transactions. If 50 transactions are split in the same block (using our tainted coins) it could provide strong evidence that they were owned by the same person. By spacing transactions this becomes more difficult (especially if there are a large number of people using our UTXO taint in that period of time).
+
+** Delayed Sell API
+This API is similar to the Delay Relay API except instead of trickling out the split transaction, this API trickles out the sell orders. If you sell a large number of forked coins in the same transaction that would indicate the same owner. Those coins can be traced back to their pre-forked Bitcoins and back to the owner. By delaying the sell orders this API makes that much more difficult.
+
+** Split Transaction API
+This API accepts a UTXO and a destination address and it returns a transaction that spends the UTXO and tainted UTXO (that it pulls in the background from the Taint API). The client can then sign the transaction with the private key associated with the untainted UTXO without knowing how to generate these transactions or storing tainted UTXO.
+
+* How we generate bitcoin only transactions
+We intend to use a variety of techniques to generate coins that can be used to split transactions. And, where possible we intend to combine techniques, to create “defense-in-depth.” We will also be careful to only use techniques that make sense for a given hardfork. 
+
+** New Coinbase Coins
+Bitcoin that is generated by mining after a fork are sent to an address that only exists on one of the forks. Any transactions that include these coins will be rejected by the side of the fork that doesn’t contain these brand new addresses with balances.
+Pros: Simple and relatively secure.
+Cons: Requires that the new coins mature 100 blocks — forces a delay in splitting.
+
+
+** nLockTime Transactions
+By using nLockTime we can generate a transaction that will be immediately valid on one chain and won’t be valid for 100 blocks on the other chain (assuming the chains have diverged more than 100 blocks). This allows us to send a transaction that is fully confirmed on one chain. On the other chain we can spend the balance to zero before nLockTime expires and therefore make that transaction invalid. 
+Pros: Simple and pretty secure (though a little less than new coinbase coins).
+Cons: Need to wait until the chains diverge enough to provide time to invalidate one of the transactions before the nLockTime expires.
+
+
+** Massive Transaction
+If one chain supports larger blocks than the other, a really big transaction (greater than 1MB w/o SegWit) can be created. It would be invalid on the original chain, but would be valid on the new chain. 
+Pros: Can be executed immediately after the fork. No delay “technically required.”
+Cons: Requires participation of a miner to accept the larger than 100 kb transaction. Also involves significant mining expense. The expense could be spread across multiple users, but the cost is still significant.
+
+** High/Low Fees
+If one chain has a big enough divergence in fees a transaction could be created that would have a high enough fee on one chain to be confirmed, but low enough to be ignored on the other chain. Once the first chain confirms the transaction a new transaction could be created to invalidate the transaction on the high fee chain.
+Pros: Cheap. Should be relatively easy. No delay required.
+Cons: May require trial and error. A miner could mine the low fee transaction at a loss to prevent the chain split, which would require you to try again.