Ok, when I posted this yesterday my main purpose was that I thought that it was important to discuss because it positions BIP101 on equal footing with SW -- no hard fork required.
However, as I've been thinking about it I've realized that this is a way to soft-fork in a scaling idea that I originally thought could only be applicable to an alt-coin I which call distributed trustless merkle trees. The advantage is that this proposal actually scales beyond the capabilities of any portion of the network or of a single computer -- in other words, every wire or CPU does not have to see every transaction. So it solves scalability forever. Within that context, I've changed my mind -- yes its a bit more "messy" then BIP101 but its also much more powerful. If we are going to use the power of ANYONECANPAY, we should use it for this.
I was working on a more formal writeup last summer without much focus because I am not that interested in alt-coins until it becomes clear that Bitcoin will never be allowed to scale. Here is the proposal informally:
Let me propose that the extended block be replaced with 10 extended blocks each containing addresses prefixed with 20 to 29. And block with prefix address 20, directly contains addresses 200 and could contain sub-blocks (in theory) consisting of addresses 201 to 209, recursively. So we have a merkle block tree, and POW in the bitcoin blockchain is inherited by all blocks in that tree. Subblocks have their own coinbase txn that pays 0 reward but defines where the transaction fees go.
Paying between 2 addresses with the same prefix is just a transaction within a single block. Paying across address prefixes would require a transaction in the common parent, and in the "legacy" (today's blockchain) case we use the ANYONECANPAY "trick" and put the transaction in the children too (as described in my original post).
An individual's wallet could choose to limit itself to a particular set of leaf blocks (typically 1) and all parent blocks simply by generating the appropriately prefixed recipient addresses just like we generate vanity addreses today.
The security model is the same as Bitcoin for all blocks that the individual's wallet chooses to download the block's complete history.
Let us assume 3 main payment models in the world -- P2P, fan-in (starbucks), and fan-out (ad networks). Individuals use P2P and send into fan-in models. I believe that P2P use is highly localized -- its a scaled network of friends, family, and localized "yard-sale" like transactions. In these cases, if the sub-blocks were more-or-less geographically localized (this may happen naturally, or it may happen with some "help" via explicit coding in the client), most of the P2P transactions would occur within a block (remember that a single block can handle the ENTIRE bitcoin economic activity happening today). Companies with fan-in or fan-out models could keep track of and hold balances in many or all the address blocks, and in the fan-in case, the QR code could be extended to offer several recipient address choices, allowing the sender to choose an address block that he has a balance in. With these strategies, most of the transactions can occur in sub-blocks. This is not a requirement -- we will allow transactions to cross blocks as described next -- but companies might do so for efficiency reasons. With a lot of sub-blocks there could be heavy demand for cross-block transactions, resulting in higher fees to use space in blocks closer to the root (today's bitcoin blockchain) block.
But there will be times when a transaction must cross blocks. If txouts included the source block hash in the transaction (Ranvier's fraud proofs), it would be the individual's choice as to how deeply he wants to validate the coin history in a block history that his client is not tracking. He could rely entirely on miners for validation and therefore be essentially a SPV-client for txouts coming from those addresses, he could trace N weeks back in the blockchain, or he could have a trust relationship with a 3rd party service that is tracking the entire blockchain (well, blocktree). This is no worse of a security model than today's SPV clients.
Originally I thought that Mining pools would need to track all blocks. Let's assume this is the case for now... the advantages are that this tracking is naturally decomposable -- the mining pool can split tracking of particular address blocks to separate servers (located near where most transactions on that block originate to eliminate network use) and each server submits the block hash to its parent server to be assembled into a merkle tree of blocks that ultimately is placed in the bitcoin blockchain. This requires a trust relationship between the mining pool and the servers assembling blocks -- or to put it another way, the mining pool has to run multiple servers to handle the transaction load. This is no worse than the centralization that happens today -- the mining pool handles all blocks.
However, now I don't think that mining pools need to handle all the blocks in the tree. They could simply not mine some of the sub-blocks and not add them into the merkle block tree. This would reduce the rate of transaction commitment in those sub-blocks. How can users encourage a sub-block to be regularly mined? Offer more in transaction fees! So we get a fee market. You could even offer an ANYONECANPAY transaction to explicitly encourage mining.
Miners do not need to see any of the data in the sub-blocks. They only need to see the original bitcoin block, since it contains a merkle tree of the hashes of (essentially pointers to) the sub-blocks. This means that bandwidth to the hashing factories remains what it is today.
Finally, mining pools may not need to generate all the sub-blocks themselves. They could choose to accept a sub-block without validating it. If they do so, there is a danger that this subblock will be invalid and rejected by the rest of the network. In this case, the rest of the network could present a succinct fraud proof which the mining pool could validate without having to sync the entire sub-block chain. But there are several incentives for the submission of valid subblocks:
1. transaction fees go to the sub-block coinbase addresses -- presumably some of these are the sub-block validator's addresses, and some amount could also pay out to the mining pool to encourage it to include this sub-block rather than a competitor's.
2. the sub-block validator could "mine" the sub-block. In other words, the validator could use POW to prove to a mining pool that it has significant investment in the block.
With these last 2 observations, you end up with the trustless part in the "distributed trustless merkle tree". However this trustless "feature" does not seem that important in today's network, given the fact that mining pools are ALREADY quite centralized. The proposal above makes them no more so, and in fact may help to decentralize them by allowing trustless sub-block assembly. The most important feature is the "permissionless" aspect -- anyone can create a new mining pool and compete with the existing ones.
TLDR:
1. Infinite scalability
2. User clients do not require more bandwidth than today. They can be "full nodes" for regional transaction and SPV nodes (or full nodes if they want) for others.
3. Competition for cross block space creates transaction fees -> fee market
4. Encouraging mining pools to include sub-blocks creates transaction fees -> fee market
5. Miners (hashers) do not need higher bandwidth than today
6. Mining pools can distribute the validation work across multiple servers
7. Mining pools can choose to include sub-blocks from 3rd party providers and there are mechanisms to ensure that these sub-blocks are valid.
8. User clients with a lot of activity (corporations, exchanges, etc) can validate any/all regions and can naturally distribute this validation to a network of machines.
