Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks

[Tier Nolan <tier.nolan@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2652 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 3878 bytes --]