Bitsupercoin.txt

Bitsupercoin: Peers‘ Counting and Clearing All-output-spent Transactions On The Disk In Batches Can Agree 

Satoshi Nakamoto 
                           
For an 'all-output-spent' transaction(ispruned, including coinbases), it should be pruned on the disk instead of being removed in coinsDB(Coinsviewcache). Hence the blocks are needed to be stored in the form of 'one file per block', to rewrite and achieve 'Storage Decentralization'. Meanwhile, to solve the problem of 'mining pool centralization' and 'online exchange centralization', we have to launch a new spare decentralized currency. The original goal 'Reclaiming Disk Space' cannot be reached because of no big block all-txs-pruned existing. The transactions' hashes only exist in the memory while a lot of many-to-many transactions with dusts constantly being packaged.

Based on bitcoin-0.10.2, the insecure SegWit is not an adoption. The version of top 1000 blocks of the active chain always keeps 4, which means the transaction data is intact. The version of blocks below 1000 depth mostly keeps 3, which means the 'all-output-spent txs' had been being pruned to "IsNull" each time the block reaches having 250 all-output-spent transactions. The total number of non empty transactions in the version3  will be continuously pruned until it belows 250. Pruning changes the nversion of 'all-output-spent tx' to 0 so that the 'tx' does not serialize 'vin' and 'vout', and will be in 'IsNull' state after being unserialized from disk. The original number of non empty transactions is put into the block header to mine, and the version3 blocks from other peers join via a loose check, but pruning will not affect the block header.

In a presistent vector<unsigned char>, we count the number of 'all-output-spent' transactions in each old block when some block's 'vtx' causing some old transactions being 'all-output-spent'. We always track a block whose depth is 1000 below the current accepted height: if its 'vtx' cause the parent transaction (term called source-tx) to become all-output-spent, then the source-tx's height which corresponds the position of the vector, will increase its byte until the byte reaches 250 and zeros, and then the height will be recorded, waiting to be trimmed, to the state that its 'vtx' being mixed with empty txs. The pruning involve coinbase, but it won't happen double-spending because the mining peers always have 1000 version4 blocks strictly verified at the top section.

Each new block received can make about 5000 old transactions become 'all-output-spent', so about 20 old blocks below 1300 depth will be reconstructed every time. The maturity of all outputs is 300. So the Merkle tree will change due to the pruning reconstruction but won't be checked in version3; The pruning results of peers with different heights are probably corrupt: For example, an entrant first download the blocks from a intentionally reserved  peer and then download the blocks from a honest updated peer, will find that the child transaction has been pruned to be empty before its parent transaction(source-tx), or conversely receive a  block containing a child transaction with missing or wrong inputs. The correct source-txs may also be intentionally cleared and instead by the other fictional txs to keep the 'IsNull' txs number in block version3 is a multiple of 250). But this will not lead to double-spending and no-source-spending, because the mining peers have 1000 version4, which will be strictly verified when accepted, that ensures the security. Accepting to the top has to go via many conflicts, such as corrupt reserved peers spreading blockchain virus, but the peers can repair themselves by an ingenious mode.

Since the number of 'IsNull' transactions in block version3 must be a multiple of 250, and the number of original transactions has been put into the block header, also every transaction‘s fee is fixed to 500 satoshi; then the intentionally reserved counterfeiters can spread the virus by inv messages. They added transactions, and cleared equally, or cleared and added 250 or multiples of 250 transactions at a time. These transactions may be fictitious. The transaction of version3 block is either 'haveInputs' or 'IsNull', and with source-txs existing either or not, rather than from a wrong source-tx. Because this will cause download interruption. So the loose verification of the 'vtx' part of version3 block, allowing coins without source-tx to be updated into viewcache, but for the wrong source-tx (!IsAvailable || prevout IsNull) and wrong source-tx's value will find error, it will still not recognize. If the source-tx coin is missing, it is equivalent to that height had been pruned in advance. After reaching some height, the infected peer will recover and repair itself. If the fictitious source-tx is still mixed in old blocks, it is very difficult for the source-tx to be spent and recognized by other peers, and someday it will be buried. Because the counterfeiter doesn't know how many correct ledgers the other peers have and used to verify. The blockchain virus situation is always that: some correct source-tx is missing and a equal amount of fictitious source-tx is added, or reserve 'all-output-spent txs' and delete non-all-output-spent txs equally, to keep the number of empty transactions is a multiple of 250.

When the source-txs of the received block's 'vtx' cannot be found, the peer will change the block nVersion to 3 ('nVersion' won't serialize to be mined) in preliminary checks. Version3 can pass the loose check and be connected, can update coins, insert the transactions without source-tx into the view(pcionstip) cache. However, if there are no 1000 consecutive 4 version blocks, mining results are not sure to be accepted by honest peers. Once there are 300 version4 accepted, any new block from other peers that has been changed to version3 in preliminary check will be rejected. However, the infected peer can always accept the version3 block which has fictitious tx from the fictitious source-tx , that is to say, the infected peer will never have 300 consecutive version4 up to the tip. It will always change the new version4 received to 3, and then insert the transactions without the source-tx in coinscache. In this way, the virus will be covered automatically after infection. In the future, the infected peer will clear the infection of the missing source-tx, reach having 300 or even 1000 top version4 blocks. But there will still be unspent outputs from the dishonest peers left. The prevouts based on these coins sources will not be recognized by other mining peers unless a small group has been evolved out.

Due to the decentralization on storage, the net scale is very large, and every transaction has at most two inputs and four outputs. In this way, the probability of self-cleaning to cast off 'the version3 tips' is greatly increased. Malicious peers will conflict with each other, but they can not prevent the infected peers' self-recovery. Although mining peers may be corrupt, the fake 'tx' will not be received by a large group. Only the original correct version will be admitted and inserted into the coinscache piecewisely to cover and unify all kinds of infection.

The infected peer can relay the transactions it thinks are correct while listening. The counterfeiter can't affect the correct ledgers that are mining because they have 1000 version4 blocks. The counterfeiters can't participate in the mining either, they can't receive and confirm a corruct-source transaction(they destroyed their data), or he can only mine out the block composed of transactions with source-txs records from common intersection, which doesn't affect the community with huge amount of peers. Even if the counterfeiter continues to mine for empty blocks, it will only let the infected peers have more version4, so as to ban the other peers in advance, and then find their own missing parts.

Every block will be recognized as version3 or 4 by different peers. Finally, after receiving 300 consecutive version4, their infected state will be changed and no version3 block will be received. Fictitious transactions will not be spent, transactions from a missing source-tx(pruned in advance if honest) will repair themselves, and wrong transactions will not be mined undoubtedly. Even if the counterfeiters form clusters and mine according to fictitious transactions, it is only equivalent to persisting an infection, just as the DNA chain has forked and mutated, and the counterfeiting groups have formed a new small community. The final distribution results of all outputs in disk will only take up 10G space and the growth rate is getting lower and lower.

Undo file is still put in the chunk，the max block size is 2M, the block time is in 64 bits, and original non empty transaction number 'orignTx' will be put in block header to mine. The maturity of all outputs is 300, which can reduce the frequency of speculation, allow more peers to maintain their asset value, prevent a centralized online exchange appearing in the world, and limit the settlement delay of the mining pool. Meanwhile, the transaction's inputs number is at most 2, and the outputs number is at most 4, which limits the settlement scale of the mining pool, because the transactions from the mining pool to a quantity of people require many transaction fees. In this way, a centralized mining pool will be weakened eventually and it is easier for infected peers to repair themselves. Bitsupercoin's coinbase value has been being halved from 64, with an interval of 5 years. It still uses sha256, in order to be compatible with ASIC.

Storage centralization, online exchange centralization and mining-pool centralization are solved by a bold way, and the number of peers can increase continuously. And people are more willing to disperse their coins than stay a huge account, which is conducive to consumption and economic mobility. That is very close to the absolute decentralization.

Reference
1.Satoshi Nakamoto, "Bitcoin: A Peer-to-Peer Electronic Cash System", November 2008.
github/holyangel250/bitsupercoin