MIME-Version: 1.0
In-Reply-To: <CABsx9T2+dG0AE+MgKRAU97KhkHTU1MuxXuwHKv3BgpJswZ5vVg@mail.gmail.com>
References: <CABsx9T2+dG0AE+MgKRAU97KhkHTU1MuxXuwHKv3BgpJswZ5vVg@mail.gmail.com>
From: Btc Drak <btcdrak@gmail.com>
Date: Wed, 23 Sep 2015 17:07:31 +0100
Message-ID: <CADJgMzt9xYdaVnvj96YicrcNGj_RWObKTFUsCeWUaP7Apnzwjw@mail.gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=001a1149af1a00d65a05206c5180
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Weak block thoughts...
Precedence: list

--001a1149af1a00d65a05206c5180
Content-Type: text/plain; charset=UTF-8

For anyone who missed the discussions of weak blocks, here are the Scaling
Bitcoin's transcripts:

http://diyhpl.us/wiki/transcripts/scalingbitcoin/bitcoin-block-propagation-iblt-rusty-russell/

http://diyhpl.us/wiki/transcripts/scalingbitcoin/roundgroup-roundup-1/
(under Network Propagation).

On Wed, Sep 23, 2015 at 4:43 PM, 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.
>
> 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.
>
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> .................
>
> 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.
>
> .................
>
> 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.
>
> --
> --
> Gavin Andresen
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

--001a1149af1a00d65a05206c5180
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">For anyone who missed the discussions of weak blocks, here=
 are the Scaling Bitcoin&#39;s transcripts:<div><br></div><div><a href=3D"h=
ttp://diyhpl.us/wiki/transcripts/scalingbitcoin/bitcoin-block-propagation-i=
blt-rusty-russell/">http://diyhpl.us/wiki/transcripts/scalingbitcoin/bitcoi=
n-block-propagation-iblt-rusty-russell/</a>=C2=A0<br></div><div><a href=3D"=
http://diyhpl.us/wiki/transcripts/scalingbitcoin/roundgroup-roundup-1/">htt=
p://diyhpl.us/wiki/transcripts/scalingbitcoin/roundgroup-roundup-1/</a> (un=
der Network Propagation).<br></div></div><div class=3D"gmail_extra"><br><di=
v class=3D"gmail_quote">On Wed, Sep 23, 2015 at 4:43 PM, Gavin Andresen via=
 bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linu=
xfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a=
>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I=
9;ve been thinking about &#39;weak blocks&#39; and SPV mining, and it seems=
 to me weak blocks will make things better, not worse, if we improve the mi=
ning code a little bit.<div><br></div><div>First: =C2=A0the idea of &#39;we=
ak blocks&#39; (hat tip to Rusty for the term) is for miners to pre-announc=
e blocks that they&#39;re working on, before they&#39;ve solved the proof-o=
f-work puzzle. To prevent DoS attacks, assume that some amount of proof-of-=
work is done (hence the term &#39;weak block&#39;) to rate-limit how many &=
#39;weak block&#39; 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 w=
ant 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&#39;re wo=
rking on to their peers, and peers validate those &#39;weak blocks&#39; 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 ne=
twork could be mining on the new block.</div><div><br></div><div>I don&#39;=
t see any barrier to making accepting the full-difficulty block and CreateN=
ewBlock() insanely fast, and if those operations take just a microsecond or=
 three, miners will have an incentive to create blocks with fee-paying tran=
sactions that weren&#39;t in the last block, rather than mining empty block=
s.</div><div><br></div><div>.................</div><div><br></div><div>A mi=
ner could try to avoid validation work by just taking a weak block announce=
d by somebody else, replacing the coinbase and re-computing the merkle root=
, and then mining. They will be at a slight disadvantage to fully validatin=
g 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 nex=
t weak block.</div><div><br></div><div>.................</div><div><br></di=
v><div>Weak block announcements are great for the network; they give transa=
ction creators a pretty good idea of whether or not their transactions are =
likely to be confirmed in the next block. And if we&#39;re smart about impl=
ementing them, they shouldn&#39;t increase bandwidth or CPU usage significa=
ntly, because all the weak blocks at a given point in time are likely to co=
ntain the same transactions.</div><span class=3D"HOEnZb"><font color=3D"#88=
8888"><div><div><br></div>-- <br><div>--<br>Gavin Andresen<br></div><div><b=
r></div>
</div></font></span></div></div>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div>

--001a1149af1a00d65a05206c5180--