I am a long-time developer and I have some experience in process groups. I am going to try to keep this short. If you are interested in pursuing this idea please reply to me privately so we don't put a burden on the list.

As per Satoshi's paper, the blockchain implements a distributed timestamp service. It defeats double-spending by establishing a "total order" on transactions. The "domain" on which the ordering takes place is the entire coin, the money supply. It's obvious to me that total ordering does not scale well as a use case, it's not a matter of implementation details or design. It's the requirement which is a problem. Therefore when I see mention of the many clever schemes proposed to make Bitcoin scalable I already know that by using that proposal we are going to give up something. And in some cases I see lengthy and complex proposals, and just what the user is giving up is not easy to see.

I think that the user has to give up something in order for electronic cash to really scale, and that something has to be non-locality. At the moment Bitcoin doesn't know whether I am buying a laptop from 3,000 miles away or 300. This is a wonderful property, but this property makes it impossible to partition the users geographically. I think that a simple and effective way to do this is to partition the address using a hash. A convention could be adopted whereby there is a well-known partition number for each geographic location. Most users would use third-party clients and the client could generate Bitcoin addresses until it hits one in the user's geographical area.

The partitioning scheme could be hierarchical. For example there could be partitions at the city, state, and country level. A good way to see how this works in real life is shopping at Walmart, which is something like 4,000 stores. Walmart could have users pay local addresses, and then move the money "up" to a regional or country level.

The problem is what to do when an address in partition A wants to pay an address in partition B. This should be done by processing the transaction in partition A first, and once the block is made a hash of that block should be included in some block in partition B. After A has made the block the coin has left A, it cannot be spent. Once B has made its block the coin has "arrived" in B and can be spent. It can be seen that some transactions span a longer distance than others, in that they require two or more blocks. These transactions take longer to execute, and I think that that is entirely okay.

Transaction verification benefits because a small merchant can accept payments from local addresses only. Larger merchants can verify transactions across two or more partitions.

Some will be concerned about 51% attacks on partitions. I would point out that nodes could process transactions at random, so that the majority of the computing power is well-balanced across all partitions.

Regards,

Akiva