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>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Weak block thoughts...
Precedence: list


--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--