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