Philippe (Haskoin) and I stumbled upon an interesting idea during the weekend while attempting to improve the reliability of 0-conf transactions. This is the first written description of the Fastchain proposal.
The motivation behind this was originally to have some way to do partial confirmations on mempool transactions, but it soon became evident that we stumbled upon a mechanism that can be used to increase the size of Bitcoin blocks via a soft-fork. I call this system the Fastchain.
The Fastchain is a parallel blockchain where each Fastchain block is merge-mined into the next Bitcoin block. The difficulty of the Fastchain is much lower than that of the main Bitcoin blockchain, with a ratio set at some established constant. Since this is a soft-fork that proposes changes to the Bitcoin consensus protocol, every miner will be required to merge-mine Fastchain, guaranteeing that Fastchain blocks get the full proof-of-work power of the Bitcoin network, therefore similar security guarantees.
Fastchain blocks do not have a coinbase transaction, as such transaction would not be recognised as a valid Bitcoin transaction by the Bitcoin network. Instead Fastchain blocks contain information about the miner that generated it. A change in the Bitcoin consensus protocol will ensure payouts to Fastchain miners happen in the next Bitcoin block’s coinbase transaction.
Fastchain blocks include only transactions that have not been mined into the Bitcoin blockchain. The Bitcoin consensus rules are changed so that only transactions already mined in the Fastchain can be included in the next Bitcoin block. Mining rewards and fees are split (in some to-be-determined way) towards miners of Fastchain blocks generated between the last Bitcoin block and the current one.
The longest Bitcoin chain is always the valid one, as per current rules, but the new rules state that given two Bitcoin chains at equal heights, the one that anchors the highest Fastchain block is the valid one.
Since miners are guaranteed to be working on merged Fastchain blocks, every block that anchors the Fastchain to the Bitcoin network can count both as confirmation for the Bitcoin transactions contained within that block, and of any transaction mined in the Fastchain blocks up to that one, even when those transactions may not yet be included in any Bitcoin block. The Fastchain can grow faster than the Bitcoin blockchain, while preserving the same security guarantees for its transactions. Older Bitcoin nodes only see transactions as they enter the main chain, and will not be able to get confirmation information for transactions in the Fastchain that have not yet been included in a main chain block. If nodes have mempool synchronisation capabilities, it is possible to relay all Fastchain transactions that are not yet in the Bitcoin blockchain as mempool updates. That would make an old node be aware of Fastchain transactions, but recognise them as unconfirmed. This sort of synchronisation could be prohibitive in terms of memory consumption and bandwidth utilisation if the Fastchain grows significantly larger than the main chain, and can be automatically disabled after this difference reaches a certain size. It is only meant as a convenience while the network is migrating towards Fastchain rules.
The new confirmed UTXO set would be the union of the UTXO set in the main chain and that of the Fastchain. Transactions recognised as valid in the Fastchain would also be valid for non-Fastchain-aware nodes, although they’d look as unconfirmed to them. Some wallets could have problems recognising transactions that have been confirmed in the Fastchain, but for which an unconfirmed double-spend has been recorded previously. These wallets would have to purge their unconfirmed transactions and resync mempools to get the new state.
Fastchain blocks that do not make the difficulty target of a full Bitcoin block can be broadcast partially, without including unnecessary information pertaining to the merge-mined Bitcoin block, saving bandwidth
Some advantages for the Bitcoin/Fastchain system are:
- Smaller more frequent blocks that are easier to propagate across slow restricted networks (Great Firewall)
- Same security as the main chain
- No hard fork required
- Friendly to older nodes
- Transaction fees are eventually claimed by miners as they trickle into the main chain
- Weaker pre-confirmation of 0-conf transactions instead of the current all-or-nothing approach
- No need to broadcast transactions along with main chain blocks, since they are already in the Fastchain
- Decentralisation of mining, since it is easier for smaller mining pools to get more steady mining rewards from Fastchain blocks
Please tear a hole in this proposal. There hasn’t yet been enough review. It can have a mortal flaw that I have not yet seen.