On Wed, Apr 23, 2014 at 10:39 PM, Gregory Maxwell <gmaxwell@gmail.com> wrote:
You can see me proposing this kind of thing in a number of places (e.g.
http://download.wpsoftware.net/bitcoin/wizards/2014-04-15.txt "p2pool
only forces the subsidy today, but the same mechnism could instead
force transactions..

Interesting.  You set the share-block size to 16kB and set the share POW to 1/64 of the main target.

Each share-block would be allowed to append up to 16kB on the previous share-block.

This would keep the bandwidth the same, but on average blocks would be only 512kB.

e.g. to get you fast confirmation.", or
previously on BCT for the last couple years) but there are still
limits here:  If you don't follow the fast-confirmation share chain
you cannot mine third party transactions because you'll be at risk of
mining a double spend that gets you orphaned, or building on a prior
block that other miners have decided is bad.  This means that if the
latency or data rate requirements of the share chain are too large
relative to ordinary mining it may create some centralization
pressure.

This effect could be reduced by having "colours" for blocks and transactions.

The block colour would be a loop based on block height.

You could have 16 transaction "colours" based on the lowest 4 bits in the txId.

A transaction is only valid if all inputs into the transaction are the correct colour for that block.

This allows blocks to be created in advance.  If you are processing colour 7 at the moment, you can have a colour 8 block ready.

16 colours is probably to many.   It would only be necessary for things like 1 second block rates.

The disadvantage is that wallets would have to make sure that they have coins for each of the 16 colours.

If you spend the wrong colour, you add 16 block times of latency.
 

That said, I think using a fast confirmation share-chain is much
better than decreasing block times and could be a very useful tool if
we believe that there are many applications which could be improved
with e.g. a 30 second or 1 minute interblock time.  Mostly my thinking
has been that these retail applications really want sub-second
confirmation, which can't reasonably be provided in this manner so I
didn't mention it in this thread.

In a shop setting, you could set it up so that the person scans a QR-code to setup a channel with the shop.

They can then scan all their stuff and by the time they have done that, the channel would be ready.

If there was a queue, it could be done when the person enters the queue.

In fact, there could be QR-codes at multiple locations.