Re: [bitcoin-dev] Weak block thoughts...

[Gregory Maxwell <gmaxwell@gmail.com>]

On Wed, Sep 23, 2015 at 4:07 PM, Bryan Bishop via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> more recently:
> http://gnusha.org/bitcoin-wizards/2015-09-20.log
> http://diyhpl.us/wiki/transcripts/scalingbitcoin/roundgroup-roundup-1/
> http://diyhpl.us/wiki/transcripts/scalingbitcoin/bitcoin-block-propagation-iblt-rusty-russell/

See also my response to Peter R's paper that was republished to the
list at http://pastebin.com/jFgkk8M3
(See sections at "For example, imagine if miners only include
transactions that were previously committed" and especially "Miners
volutarily participate in a fast consensus mechenism which commits to
transactions")

On Wed, Sep 23, 2015 at 3:43 PM, Gavin Andresen via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Imagine miners always pre-announce the blocks they're working on to their
> peers, and peers validate those 'weak blocks' as quickly as they are able.
>
> Because weak blocks are pre-validated, when a full-difficulty block based on
> a previously announced weak block is found, block propagation should be
> insanely fast--
[...]
> A miner could try to avoid validation work by just taking a weak block
> announced by somebody else, replacing the coinbase and re-computing the
> merkle root, and then mining. They will be at a slight disadvantage to fully

Take care, here-- if a scheme is used where e.g. the full solution had
to be exactly identical to a prior weak block then the result would be
making mining not progress free because bigger miners would have
disproportionately more access to the weak/strong one/two punch. I
think what you're thinking here is okay, but it wasn't clear to me if
you'd caught that particular potential issue.

Avoiding this is why I've always previously described this idea as
merged mined block DAG (with blocks of arbitrary strength) which are
always efficiently deferentially coded against prior state. A new
solution (regardless of who creates it) can still be efficiently
transmitted even if it differs in arbitrary ways (though the
efficiency is less the more different it is).

There is a cost to these schemes-- additional overhead from
communicating the efficiently encoded weak blocks. But participation
in this overhead is optional and doesn't impact the history.

I'm unsure of what approach to take for incentive compatibility
analysis. In the worst case this approach class has no better delays
(and higher bandwidth); but it doesn't seem to me to give rise to any
immediate incrementally strategic behavior (or at least none worse
than you'd get from just privately using the same scheme).

On Wed, Sep 23, 2015 at 4:28 PM, Peter R via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Shouldn't mining pools and miners be paying you guys for coding solutions
> that improve their profitability?

The income to miners as a whole doesn't depend on these sorts of
optimizations, competitive advantages do... so better common open
infrastructure helps mostly in the case of putting propagation
disadvantaged miners on an equal playing field. You'll note that none
of them are exactly sharing their SPV mining source code right now....
in any case, there are simple, expedient, and low risk ways to improve
their equality in that respect: centralize (e.g. use bigger pools).