Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 778941AAE for ; Sun, 27 Sep 2015 15:10:25 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com [209.85.213.176]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BD8FFB0 for ; Sun, 27 Sep 2015 15:10:24 +0000 (UTC) Received: by igbkq10 with SMTP id kq10so40314094igb.0 for ; Sun, 27 Sep 2015 08:10:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=aYDgzAD0MucpdqYRkupdx4+h4x/PJhmW+cWYVhhAEq4=; b=Wa0RsMq2okiwYaWXsPsqLZT704vX+cRXJCuN8RS4WqJzGCxQJH7xXtaD9VwbIpeOzX vlDTui73kgBmWl4OgY3v/+JVB0eYQZOq/d3tH4EvnYolmCbsduPIUuuL2dCgB5EWtXbv 9yYXMnYocxU8yWjwF7y18Sak0+Mf3FbYt2CqvoTlg6e2wtdVjS3xhAwFqYdN3s6fBCyC irvMpHXLkAmuxwzIAEzme8w9UcEE9d7rJC5VZsB9OgtxzSBHN/UZk0jLz3zDHZpDXAVg CnEIp8Yss9J0Djnxmp3p5HJi1ohQiargxBpVYHJjm6H4lOmoS+9QlLmoVg58qfX34qC5 Zt8g== X-Gm-Message-State: ALoCoQn+VsPWIfwDtb/wa/k/j/QSCl+ytYIFph1RxXgCcjfo2zuMYCtdrWpMJYUX4R1ahrd2y3iN MIME-Version: 1.0 X-Received: by 10.50.143.1 with SMTP id sa1mr12387392igb.32.1443366624191; Sun, 27 Sep 2015 08:10:24 -0700 (PDT) Received: by 10.107.189.195 with HTTP; Sun, 27 Sep 2015 08:10:24 -0700 (PDT) In-Reply-To: References: Date: Sun, 27 Sep 2015 17:10:24 +0200 Message-ID: From: Kalle Rosenbaum To: Bitcoin Dev Content-Type: multipart/alternative; boundary=001a1134bdaaea87b00520bbfaed X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 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: Sun, 27 Sep 2015 15:10:25 -0000 --001a1134bdaaea87b00520bbfaed Content-Type: text/plain; charset=UTF-8 I was mansplaining weak blocks to my wife. She asked a simple question: Why would I, as a miner, publish a weak block if I find one? I don't know. Sure, I will get faster propagation for my solved block, should I find one. On the other hand everybody else mining a similar block will enjoy the same benefit. Assuming that I'm not a huge miner, it's unlikely that I will actually solve the block, so I'm probably just giving away fast propagation times to someone else. So how does publishing a weak block benefit the producer of it more than the other miners? Please help me understand this. /Kalle Rosenbaum 2015-09-27 11:42 GMT+02:00 Tier Nolan via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org>: > > > On Sun, Sep 27, 2015 at 2:39 AM, Gregory Maxwell via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Unless the weak block transaction list can be a superset of the block >> transaction list size proportional propagation costs are not totally >> eliminated. >> > > The POW threshold could be dynamic. The first weak-block that builds on a > new block could be forwarded with a smaller target. > > This reduces the window size until at least one weak block is > propagated. > > The change in threshold could be time based (for the first 30 seconds or > so). This would cause a surge of traffic when a new block once a new block > has propagated, so perhaps not so good an idea. > > >> As even if the weak block criteria is MUCH lower than the block >> criteria (which would become problematic in its own right at some >> point) the network will sometimes find blocks when there hasn't been >> any weak block priming at all (e.g. all prior priming has made it into >> blocks already). >> > > If there is a transaction backlog, then miners could forward merkle > branches with transactions in the memory pool with a commitment in the > coinbase. > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --001a1134bdaaea87b00520bbfaed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I was mansplaining weak blocks to my wife. She asked a sim= ple question:=C2=A0

Why would I, as a miner, publish a w= eak block if I find one?

I don't know.
Sure, I will get faster propagation for my solved block, should= I find one. On the other hand everybody else mining a similar block will e= njoy the same benefit. Assuming that I'm not a huge miner, it's unl= ikely that I will actually solve the block, so I'm probably just giving= away fast propagation times to someone else.

So h= ow does publishing a weak block benefit the producer of it more than the ot= her miners? Please help me understand this.

/Kalle= Rosenbaum


2015-09-27 11:42 GMT+02:00 Tier Nolan via bitcoin-dev <= span dir=3D"ltr"><bitcoin-dev@lists.linuxfoundation.org>:<= br>


On Sun, Sep 27, 2015 at 2:39 AM= , Gregory Maxwell via bitcoin-dev <bitcoin-dev@lists.l= inuxfoundation.org> wrote:
= Unless the weak block transaction list can be a superset of the bloc= k
transaction list size proportional propagation costs are not totally
eliminated.

The POW threshold co= uld be dynamic.=C2=A0 The first weak-block that builds on a new block could= be forwarded with a smaller target.

This reduces=C2=A0 t= he window size until at least one weak block is propagated.=C2=A0

<= /div>
The change in threshold could be time based (for the first 30 sec= onds or so).=C2=A0 This would cause a surge of traffic when a new block onc= e a new block has propagated, so perhaps not so good an idea.


As even if the weak block criteria is MUCH lower than the block
criteria (which would become problematic in its own right at some
point) the network will sometimes find blocks when there hasn't been any weak block priming at all (e.g. all prior priming has made it into
blocks already).

If there is a t= ransaction backlog, then miners could forward merkle branches with transact= ions in the memory pool with a commitment in the coinbase.
<= /div>

_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev


--001a1134bdaaea87b00520bbfaed--