path: root/4c/73b343ab1e10868305ebb1d94a05220afbf47a

Return-Path: <peter_r@gmx.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id DFE7E1A1D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 23 Sep 2015 16:28:30 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 293D6160
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 23 Sep 2015 16:28:29 +0000 (UTC)
Received: from [192.168.50.29] ([69.50.179.106]) by mail.gmx.com (mrgmx101)
	with ESMTPSA (Nemesis) id 0MW8PN-1aC16P14ED-00XP2p;
	Wed, 23 Sep 2015 18:28:24 +0200
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_10FA6FBE-C1D2-4081-B884-5AF085C04FFF"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Peter R <peter_r@gmx.com>
In-Reply-To: <CABsx9T2+dG0AE+MgKRAU97KhkHTU1MuxXuwHKv3BgpJswZ5vVg@mail.gmail.com>
Date: Wed, 23 Sep 2015 09:28:20 -0700
Message-Id: <64D181DA-05F6-4636-8F44-0FA63B758947@gmx.com>
References: <CABsx9T2+dG0AE+MgKRAU97KhkHTU1MuxXuwHKv3BgpJswZ5vVg@mail.gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
X-Mailer: Apple Mail (2.1510)
X-Provags-ID: V03:K0:B7he1h9R3dFgc16YKhWh5X8gRqINS+V7JtmAjR137rWg+rcLAso
	JRdQfFNwCIhunYoiI5nXV9aiSuqaLD/wkltzyLMU2g8JsU5cnusYBX0bV87LuCwmB8O1oNC
	9ni8DtRq/gJF+QqSoJqO8qYrlbPBWJ26cbGx9IKZjrUnkHSB3m1OGTS6B1affzA5aHhSm2j
	DTUiLUTIKiGKtW/UMm1sg==
X-UI-Out-Filterresults: notjunk:1;V01:K0:WGtMyIBV1QY=:qJ+BSADEIh8OQlF2YvbcSb
	uCQaGSMAYJTnqX6lkhQcpJk/XGZf853bhhJVmd0nTunR21tYTyFK5+jcpSFBF/6NpoKUIg8UJ
	0se0r7uVIzp3VqwhTWupdUz5JzxywVMHZkZ7utj/UMpe0MRyh78PIA8WWrMG50ScX6yUslQOe
	8rAfF3KAa6Lf7f5CS7eN98EFBhwUtFEwkIAVRjS23e/Vey40egz9Z7N02xhj388EM8pJ2X2aw
	XWFZ6gExSlwZ7B9qM3WEsNsnmbxm7qdM64kScjNpUoWxOPsc82euY/w+49SbnIqaDwrQijEhB
	59PFBB9HBdPsziNzqRGY9C8XGS2ZRazDgAUhVD6sawofIDTWN1qZdN8qcIaDZfRuVfN7mEPgu
	qWrRy/ProyuRCKKO2zcrNRgKUE9HnbXZoBNzunW4NUuWZDvR39RQ6F8GtqGcWGhNyPTbgZCfj
	sOkrR3IREzSfYjfZBzD26GRUC7OjBTB6QnqdZfllYEI8aI6QHiwY4ymnoteIfCsGtlvVjTF6Z
	fx7ovg+6Lx68Y7rAogDZaRAIPPv/AP7sCU5ACqagDMCM6b4cbQey/lowcTZ+d5iU8BbGSkZob
	OmhH7TMFSZmItpWeXRtF2Fg6H5JqqfT8UMxPzyyXHP0uoVQ/qFJrZYYXGKGFuj1Gu3RnP9tUd
	hBiL7Vu0RFOz0ErmJmK4McC8LjWdhrLxKCtyrMJ+yxN+1O6/OpvvePB1tUQi9CBR9mwfgeZxq
	eNsjFqPW0S/WSN6DrK6CoLYRvlUhemBW4WMbAQ==
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 <bitcoin-dev@lists.linuxfoundation.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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Sep 2015 16:28:31 -0000


--Apple-Mail=_10FA6FBE-C1D2-4081-B884-5AF085C04FFF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi Gavin,

One thing that's not clear to me is whether it is even necessary--from =
the perspective of the block size limit--to consider block propagation.  =
Bitcoin has been successfully operating unconstrained by the block size =
limit over its entire history (except for in the past few months)--block =
propagation never entered into the equation. =20

Imagine that the limit were raised to significantly above the free =
market equilibrium block size Q*.  Mining pools and other miners would =
then have an incentive to work out schemes like "weak blocks," relay =
networks, IBLTs, etc., in order to reduce the risk of orphaning larger =
blocks (blocks with more fees that they'd like to produce if it were =
profitable). =20

Shouldn't mining pools and miners be paying you guys for coding =
solutions that improve their profitability?  =20

Best regards,
Peter


On 2015-09-23, at 8:43 AM, Gavin Andresen via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:

> I've been thinking about 'weak blocks' and SPV mining, and it seems to =
me weak blocks will make things better, not worse, if we improve the =
mining code a little bit.
>=20
> First:  the idea of 'weak blocks' (hat tip to Rusty for the term) is =
for miners to pre-announce blocks that they're working on, before =
they've solved the proof-of-work puzzle. To prevent DoS attacks, assume =
that some amount of proof-of-work is done (hence the term 'weak block') =
to rate-limit how many 'weak block' messages are relayed across the =
network.
>=20
>=20
> Today, miners are incentivized to start mining an empty block as soon =
as they see a block with valid proof-of-work, because they want to spend =
as little time as possible mining a not-best chain.
>=20
> 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.
>=20
> 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-- basically, as fast as a single packet can be =
relayed across the network the whole network could be mining on the new =
block.
>=20
> I don't see any barrier to making accepting the full-difficulty block =
and CreateNewBlock() insanely fast, and if those operations take just a =
microsecond or three, miners will have an incentive to create blocks =
with fee-paying transactions that weren't in the last block, rather than =
mining empty blocks.
>=20
> .................
>=20
> 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 validating miners, though, because they WOULD have to mine empty =
blocks between the time a full block is found and a fully-validating =
miner announced their next weak block.
>=20
> .................
>=20
> Weak block announcements are great for the network; they give =
transaction creators a pretty good idea of whether or not their =
transactions are likely to be confirmed in the next block. And if we're =
smart about implementing them, they shouldn't increase bandwidth or CPU =
usage significantly, because all the weak blocks at a given point in =
time are likely to contain the same transactions.
>=20
> --=20
> --
> Gavin Andresen
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


--Apple-Mail=_10FA6FBE-C1D2-4081-B884-5AF085C04FFF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi =
Gavin,<div><br></div><div>One thing that's not clear to me is whether it =
is even necessary--from the perspective of the block size limit--to =
consider block propagation. &nbsp;Bitcoin has been successfully =
operating unconstrained by the block size limit over its entire history =
(except for in the past few months)--block propagation never entered =
into the equation. &nbsp;</div><div><br></div><div>Imagine that the =
limit were raised to significantly above the free market equilibrium =
block size Q*. &nbsp;Mining pools and other miners would then have an =
incentive to work out schemes like "weak blocks," relay networks, IBLTs, =
etc., in order to reduce the risk of orphaning larger blocks (blocks =
with more fees that they'd like to produce if it were profitable). =
&nbsp;</div><div><br></div><div>Shouldn't mining pools and miners be =
paying <i>you guys</i> for coding solutions that improve <i>their</i> =
profitability? &nbsp;&nbsp;</div><div><br></div><div>Best =
regards,</div><div>Peter</div><div><br></div><div><br><div><div>On =
2015-09-23, at 8:43 AM, Gavin Andresen via bitcoin-dev &lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.li=
nuxfoundation.org</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div =
dir=3D"ltr">I've been thinking about 'weak blocks' and SPV mining, and =
it seems to me weak blocks will make things better, not worse, if we =
improve the mining code a little bit.<div><br></div><div>First: =
&nbsp;the idea of 'weak blocks' (hat tip to Rusty for the term) is for =
miners to pre-announce blocks that they're working on, before they've =
solved the proof-of-work puzzle. To prevent DoS attacks, assume that =
some amount of proof-of-work is done (hence the term 'weak block') to =
rate-limit how many 'weak block' messages are relayed across the =
network.</div><div><br><div><br></div><div>Today, miners are =
incentivized to start mining an empty block as soon as they see a block =
with valid proof-of-work, because they want to spend as little time as =
possible mining a not-best chain.</div><div><br></div><div>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.</div><div><br></div><div>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-- basically, as fast =
as a single packet can be relayed across the network the whole network =
could be mining on the new block.</div><div><br></div><div>I don't see =
any barrier to making accepting the full-difficulty block and =
CreateNewBlock() insanely fast, and if those operations take just a =
microsecond or three, miners will have an incentive to create blocks =
with fee-paying transactions that weren't in the last block, rather than =
mining empty =
blocks.</div><div><br></div><div>.................</div><div><br></div><di=
v>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 validating miners, though, because they WOULD have to mine empty =
blocks between the time a full block is found and a fully-validating =
miner announced their next weak =
block.</div><div><br></div><div>.................</div><div><br></div><div=
>Weak block announcements are great for the network; they give =
transaction creators a pretty good idea of whether or not their =
transactions are likely to be confirmed in the next block. And if we're =
smart about implementing them, they shouldn't increase bandwidth or CPU =
usage significantly, because all the weak blocks at a given point in =
time are likely to contain the same =
transactions.</div><div><div><br></div>-- <br><div =
class=3D"gmail_signature">--<br>Gavin Andresen<br></div><div =
class=3D"gmail_signature"><br></div>
</div></div></div>
_______________________________________________<br>bitcoin-dev mailing =
list<br><a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.li=
nuxfoundation.org</a><br>https://lists.linuxfoundation.org/mailman/listinf=
o/bitcoin-dev<br></blockquote></div><br></div></body></html>=

--Apple-Mail=_10FA6FBE-C1D2-4081-B884-5AF085C04FFF--