Gavin Andresen [ARCHIVE] on Nostr: š Original date posted:2015-09-23 š Original message:On Wed, Sep 23, 2015 at ...
š
Original date posted:2015-09-23
š Original message:On Wed, Sep 23, 2015 at 3:24 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Wed, Sep 23, 2015 at 3:43 PM, Gavin Andresen via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> [...]
> > 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.
>
I'm assuming the optimized protocol would be forward-error-coded (e.g.
using IBLTs) and NOT require the full solution (or follow-on weak blocks)
to be exactly the same.
> 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).
>
Yup, although I don't get the 'merge mined' bit; the weak blocks are
ephemeral, probably purged out of memory as soon as a few full blocks are
found...
> 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).
>
I don't see any incentive problems, either. Worst case is more miners
decide to skip validation and just mine a variation of the
highest-fee-paying weak block they've seen, but that's not a disaster--
invalid blocks will still get rejected by all the non-miners running full
nodes.
If we did see that behavior, I bet it would be a good strategy for a big
hashrate miner to dedicate some of their hashrate to announcing invalid
weak blocks; if you can get your lazy competitors to mine it, then you
win....
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150923/4ef4ac54/attachment.html>;
š Original message:On Wed, Sep 23, 2015 at 3:24 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Wed, Sep 23, 2015 at 3:43 PM, Gavin Andresen via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> [...]
> > 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.
>
I'm assuming the optimized protocol would be forward-error-coded (e.g.
using IBLTs) and NOT require the full solution (or follow-on weak blocks)
to be exactly the same.
> 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).
>
Yup, although I don't get the 'merge mined' bit; the weak blocks are
ephemeral, probably purged out of memory as soon as a few full blocks are
found...
> 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).
>
I don't see any incentive problems, either. Worst case is more miners
decide to skip validation and just mine a variation of the
highest-fee-paying weak block they've seen, but that's not a disaster--
invalid blocks will still get rejected by all the non-miners running full
nodes.
If we did see that behavior, I bet it would be a good strategy for a big
hashrate miner to dedicate some of their hashrate to announcing invalid
weak blocks; if you can get your lazy competitors to mine it, then you
win....
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150923/4ef4ac54/attachment.html>;