Hi Peter, thank you for the review.  See below

On Mon, Nov 6, 2017 at 11:50 AM Peter Todd <pete@petertodd.org> wrote:
On Wed, Nov 01, 2017 at 05:48:27AM +0000, Devrandom via bitcoin-dev wrote:

Some quick thoughts...

> Hi all,
>
> Feedback is welcome on the draft below.  In particular, I want to see if
> there is interest in further development of the idea and also interested in
> any attack vectors or undesirable dynamics.
>
> (Formatted version available here:
> https://github.com/devrandom/btc-papers/blob/master/aux-pow.md )
>
> # Soft-fork Introduction of a New POW

First of all, I don't think you can really call this a soft-fork; I'd call it a
"pseudo-soft-fork"

My reasoning being that after implementation, a chain with less total work than
the main chain - but more total SHA256^2 work than the main chain - might be
followed by non-supporting clients. It's got some properties of a soft-fork,
but it's security model is definitely different.

The interesting thing is that the cost of attack varies smoothly as you vary the POW weights.
To attack non-upgraded nodes, you still have to "51%" the original POW.
The reward going to that POW will vary smoothly between 1.0 * block_reward and whatever
target value (e.g. 0.5 * block_reward) and the difficulty of attack will tend to be proportional to that.

In a real hard-fork, your software just breaks at the fork point.  In this case, it's just the non-upgraded
node security level declining from 100% to 50% over a long period of time.

I envision the transition of POW weights will be over 1-3 years, which leaves plenty of time to
upgrade after the fork activates.
 

> ### Aux POW intermediate block
>
> Auxiliary POW blocks are introduced between normal blocks - i.e. the chain
> alternates between the two POWs.
> Each aux-POW block points to the previous normal block and contains
> transactions just like a normal block.
> Each normal block points to the previous aux-POW block and must contain all
> transactions from the aux-POW block.

Note how you're basically proposing for the block interval to be decreased,
which has security implications due to increased orphan rates.

Note that the total transaction rate and block size don't materially change, so I don't
see why the orphan rate will change.  Normal blocks are constrained to have
all of the txs of the aux blocks, so propagation time should stay the same.  Am I missing
something?
 

> ### Heaviest chain rule change
>
> This is a semi-hard change, because non-upgraded nodes can get on the wrong
> chain in case of attack.  However,

Exactly! Not really a soft-fork.

"smooth-fork" perhaps? :)
 

--
https://petertodd.org 'peter'[:-1]@petertodd.org