Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id B391F11B3 for ; Wed, 23 Sep 2015 21:37:28 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BD29D128 for ; Wed, 23 Sep 2015 21:37:27 +0000 (UTC) Received: by lahg1 with SMTP id g1so66734185lah.1 for ; Wed, 23 Sep 2015 14:37:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=k8Yy8ygGCXK/pwjHrnHwTvKJT5kySdp5X3L9ENyO2bA=; b=pu2tjBBXsaJAXr6P86Zql61OCOqiRpl+yHJNa4qVGYkSQC4QJm4P2LpgEzKAeWnxFK mX3Z3V22+gXY/Wm2pKCui/bLrtKd4JQ06T/PsNenirgiMj91DfM0uTAf8OfcsOY+7mm6 7cfcnblhdEdFR5ZDqg81iyaL3KWb4wEFn/dUdyolC6vjfarEgSRPhcfmvvI2nLGNIJb7 NF4b/btdUM72rtFq9bEI7iZ3D+SL4tfPPiNapv4ygSKJGs2EBjvsR6DdCwXiIX5QQuDr XY48QSnbdnMIgOZ8USMEQlkYa3tjbGio1Zuzp/LqxVCD6VpZCv8Lw/M7chmI0zD+ojas ZnKg== MIME-Version: 1.0 X-Received: by 10.152.43.202 with SMTP id y10mr12213085lal.75.1443044246040; Wed, 23 Sep 2015 14:37:26 -0700 (PDT) Received: by 10.25.200.214 with HTTP; Wed, 23 Sep 2015 14:37:25 -0700 (PDT) In-Reply-To: References: Date: Wed, 23 Sep 2015 17:37:25 -0400 Message-ID: From: Gavin Andresen To: Gregory Maxwell Content-Type: multipart/alternative; boundary=001a11c223d8ae3c40052070eb81 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] Weak block thoughts... X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2015 21:37:28 -0000 --001a11c223d8ae3c40052070eb81 Content-Type: text/plain; charset=UTF-8 On Wed, Sep 23, 2015 at 3:24 PM, Gregory Maxwell wrote: > On Wed, Sep 23, 2015 at 3:43 PM, Gavin Andresen via bitcoin-dev > 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 --001a11c223d8ae3c40052070eb81 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Sep 23, 2015 at 3:24 PM, Gregory Maxwell <gmaxwell@gmail.com>= wrote:
On Wed, S= ep 23, 2015 at 3:43 PM, Gavin Andresen via bitcoin-dev
<bitcoin-dev@li= sts.linuxfoundation.org> wrote:
[...]
> A miner could try to avoid validation work by just ta= king a weak block
> announced by somebody else, replacing the coinbase and re-computing th= e
> 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 h= ad
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-c= oded (e.g. using IBLTs) =C2=A0and 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 wea= k blocks are ephemeral, probably purged out of memory as soon as a few full= blocks are found...
=C2=A0
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. Wor= st 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 ru= nning full nodes.

If we did see that behavior, I b= et 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

--001a11c223d8ae3c40052070eb81--