path: root/36/4c82f3fdb04fd92c2c8f7bafe81d5bdb297bc8

Return-Path: <kalle@rosenbaum.se>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 6579415D8
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 28 Sep 2015 08:30:44 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com
	[209.85.213.173])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7518E1D6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 28 Sep 2015 08:30:43 +0000 (UTC)
Received: by igbkq10 with SMTP id kq10so47866258igb.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 28 Sep 2015 01:30:43 -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:cc:content-type;
	bh=xrqwaDGO0qtO421Fb0h3/BQJmdqAupnLnbht86ZtYZo=;
	b=LWFDct2Wp63M+sFmBU6M8AKA/2vLv8TMk2qNOHsUN0veTMuohVTJPYB8xHIcYhB2wl
	EdcwkYsbfGMyHcYgxVAHHNRIzQbLRc3ORePoMP+Q/m+rxyjRm6w35Iuq/bvcVrU+kBGX
	XaIln9otWIDCso7PkocjOZqxPLAbNn86IG3R3/ppZBzgoLpBwKNa8h6CIPjl+/mDsy67
	+uvBwRlBu6XoiYB8XVNw/SO/iOiS22hfhvsawwEsNWwhMQuwrKUYKCwB98CbqnA0aC3h
	QAY3HxHQ61W/CL6j6L4RNu2O4FotYP/HY52GDrOiGA3OKTezlhYRyN0uxjU8Ck1P9o9d
	njMA==
X-Gm-Message-State: ALoCoQmmEK699GgPwE5N2j1qGxIJKqXixGNEh2zRrQZ+zH1grB89DI31T7TnQ0A8Qix+EBIIsRDi
MIME-Version: 1.0
X-Received: by 10.50.43.134 with SMTP id w6mr4574657igl.74.1443429042880; Mon,
	28 Sep 2015 01:30:42 -0700 (PDT)
Received: by 10.107.189.195 with HTTP; Mon, 28 Sep 2015 01:30:42 -0700 (PDT)
In-Reply-To: <CAAS2fgRX-LLiNwcmbHtF6ymEX+uUx3SNjqAe4iyxouhHj=4Abw@mail.gmail.com>
References: <CABsx9T2+dG0AE+MgKRAU97KhkHTU1MuxXuwHKv3BgpJswZ5vVg@mail.gmail.com>
	<CABaSBaxcDRzw0X7-fAfxPJyLcWxTHigpHuAPb4aNQ5zk5NoDCQ@mail.gmail.com>
	<CAAS2fgTr-OuL3T6mXX-4xFC_LHnAiogTTcPMbcjsM7WtRisQEQ@mail.gmail.com>
	<CABsx9T3NFRO5nw3z=jrs0Hu3caVNkkTTTb1ibqR7LMWsoou9RQ@mail.gmail.com>
	<CAAS2fgRj+fE+znXZzFsXXBivKSxnJ2Lheo_g9us4FXN_yCLhgw@mail.gmail.com>
	<CAE-z3OU50cZBR27QrQsRT5Gtb0AVkE6K33XR0GebsyNWNrbf+w@mail.gmail.com>
	<CAPswA9xFNgdbH1JXBx+CqjT5HbkK0WGaWQLrJzm+BJCmrXRQcA@mail.gmail.com>
	<CAAS2fgRX-LLiNwcmbHtF6ymEX+uUx3SNjqAe4iyxouhHj=4Abw@mail.gmail.com>
Date: Mon, 28 Sep 2015 10:30:42 +0200
Message-ID: <CAPswA9xei1UNMeNqi=XzSnZU=SeroaeKN_6xHJ0HfhgXBzY_mw@mail.gmail.com>
From: Kalle Rosenbaum <kalle@rosenbaum.se>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: multipart/alternative; boundary=089e01184b0c5c3fea0520ca8369
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
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: Mon, 28 Sep 2015 08:30:44 -0000

--089e01184b0c5c3fea0520ca8369
Content-Type: text/plain; charset=UTF-8

2015-09-27 21:50 GMT+02:00 Gregory Maxwell <gmaxwell@gmail.com>:

> On Sun, Sep 27, 2015 at 3:10 PM, Kalle Rosenbaum via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > 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.
>
> Keep in mind, because of efficient differential transmission the cost
> to you is effectively nothing if your transaction acceptance policy is
> predictable, it's a hand-full of bytes sent. And by failing to send
> yours you do little to nothing to deny others the improvement.
>
>
Suppose that you've solved a block Z (weak or not) and you want to
propagate it using a previous weak block Y. With "efficient differential
transmission", I assume that you refer to the transmission of the
differences between Y and Z to a peer? What encodings are discussed? I
guess IBLTs are a hot candidate, but are there other schemes in the making?
I suppose that sending something like "weak block Y plus transactions A, B,
C minus transaction ids h(D), h(E)" is not considered an efficient
differential transmission. Then that's part of the answer to my question.


> Lets imagine an alternative weak-blockless weak block implementation:
>
> Every N seconds, every miner send to every other miner what they're
> working on.  This isn't totally crazy-- efficient differential
> transmission will keep the amount transmitted small.
>
> Any block found can be referenced to any of these earlier worklists.
>
> What the effect be of not transmitting yours?
>
> If your block is unlike everyone elses, you would suffer great delays
> in the event you found a block.
> If your block is mostly like everyone elses, you wouldn't suffer as
> much delay-- but the transmission costs would be negligible in that
> case. ... the size sent is proportional to the improvement you get
> when finding a block.
>

"the size sent is proportional to the improvement you get when finding a
block." - This encapsulates the issue quite well! The more exotic block I'm
building, the more I would benefit from publishing a weak block, but my
weak block would also be larger.


>
> In either case, no one else is harmed by you not sending yours... they
> still send their lists.
>
> A problem with that scheme is that unless you've layered an identity
> based access control system on it anyone can DOS attack it, because
> anyone can send as much as they want, they don't even have to be
> actual miners.
>
> What weak blocks adds to that is using hashcash as a rate limiting
> mechanism-- a coordination free lottery weighed by hash-power decides
> who can transmit.
>
> What if you don't participate in the lottery and share your solutions?
>  No major harm for the other users... the other users will just choose
> a somewhat lower weak-block threshold to get the updates at the
> desired rate than they would otherwise. To the extent that what you
> were working on was different from anyone else, you'll suffer because
> you failed to make use of your chance to influence what could be
> efficiently transmitted to include your own blocks.
>

Makes perfect sense. Also, if I'm working on an exotic block, the
probability of someone extending my weak block would be low-ish, so I'm not
necessarily "giving away fast propagation times to someone else" as I first
thought.


> You could also ask a question of why would you transitively relay
> someone elses announcement-- well if it helped their blocks too  (by
> reflecting things they also want to mine) the answer is obvious. But
> what if it was disjoint from the things they wanted to mine and didn't
> help compared to the weak blocks they already relayed?  In that case
> it's still in likely in their interest to relay it because if a block
> similar to it is produced and they extend that block they may end up
> orphaned because of propagation delays their parent block suffered.
> What if they receive an announcement which is so "ugly" that they
> wouldn't extend the chain with the strong block version of it (they'd
> intentionally try to fork it off?)-- in that case they wouldn't want
> to relay it.  So much the same logic as why you relay other parties
> blocks applies, including-- relaying helps the network, but if you
> don't it'll still get along fine without you.
>

Thank you very much for your explanation.

/Kalle

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2015=
-09-27 21:50 GMT+02:00 Gregory Maxwell <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:gmaxwell@gmail.com" target=3D"_blank">gmaxwell@gmail.com</a>&gt;</span>=
:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:so=
lid;padding-left:1ex"><span class=3D"">On Sun, Sep 27, 2015 at 3:10 PM, Kal=
le Rosenbaum via bitcoin-dev<br>
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.linuxfoundation.org</a>&gt; wrote:<br>
&gt; I was mansplaining weak blocks to my wife. She asked a simple question=
:<br>
&gt;<br>
&gt; Why would I, as a miner, publish a weak block if I find one?<br>
&gt;<br>
&gt; I don&#39;t know.<br>
&gt; Sure, I will get faster propagation for my solved block, should I find=
 one.<br>
&gt; On the other hand everybody else mining a similar block will enjoy the=
 same<br>
&gt; benefit. Assuming that I&#39;m not a huge miner, it&#39;s unlikely tha=
t I will<br>
&gt; actually solve the block, so I&#39;m probably just giving away fast pr=
opagation<br>
&gt; times to someone else.<br>
&gt; So how does publishing a weak block benefit the producer of it more th=
an the<br>
&gt; other miners? Please help me understand this.<br>
<br>
</span>Keep in mind, because of efficient differential transmission the cos=
t<br>
to you is effectively nothing if your transaction acceptance policy is<br>
predictable, it&#39;s a hand-full of bytes sent. And by failing to send<br>
yours you do little to nothing to deny others the improvement.<br>
<br></blockquote><div>=C2=A0</div><div>Suppose that you&#39;ve solved a blo=
ck Z (weak or not) and you want to propagate it using a previous weak block=
 Y. With &quot;efficient differential transmission&quot;, I assume that you=
 refer to the transmission of the differences between Y and Z to a peer? Wh=
at encodings are discussed? I guess IBLTs are a hot candidate, but are ther=
e other schemes in the making? I suppose that sending something like &quot;=
weak block Y plus transactions A, B, C minus transaction ids h(D), h(E)&quo=
t; is not considered an efficient differential transmission. Then that&#39;=
s part of the answer to my question.<br></div><div>=C2=A0</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1=
px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:=
1ex">
Lets imagine an alternative weak-blockless weak block implementation:<br>
<br>
Every N seconds, every miner send to every other miner what they&#39;re<br>
working on.=C2=A0 This isn&#39;t totally crazy-- efficient differential<br>
transmission will keep the amount transmitted small.<br>
<br>
Any block found can be referenced to any of these earlier worklists.<br>
<br>
What the effect be of not transmitting yours?<br>
<br>
If your block is unlike everyone elses, you would suffer great delays<br>
in the event you found a block.<br>
If your block is mostly like everyone elses, you wouldn&#39;t suffer as<br>
much delay-- but the transmission costs would be negligible in that<br>
case. ... the size sent is proportional to the improvement you get<br>
when finding a block.<br></blockquote><div><br></div><div>&quot;the size se=
nt is proportional to the improvement you get when finding a block.&quot; -=
 This encapsulates the issue quite well! The more exotic block I&#39;m buil=
ding, the more I would benefit from publishing a weak block, but my weak bl=
ock would also be larger.</div><div>=C2=A0</div><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-=
color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
In either case, no one else is harmed by you not sending yours... they<br>
still send their lists.<br>
<br>
A problem with that scheme is that unless you&#39;ve layered an identity<br=
>
based access control system on it anyone can DOS attack it, because<br>
anyone can send as much as they want, they don&#39;t even have to be<br>
actual miners.<br>
<br>
What weak blocks adds to that is using hashcash as a rate limiting<br>
mechanism-- a coordination free lottery weighed by hash-power decides<br>
who can transmit.<br>
<br>
What if you don&#39;t participate in the lottery and share your solutions?<=
br>
=C2=A0No major harm for the other users... the other users will just choose=
<br>
a somewhat lower weak-block threshold to get the updates at the<br>
desired rate than they would otherwise. To the extent that what you<br>
were working on was different from anyone else, you&#39;ll suffer because<b=
r>
you failed to make use of your chance to influence what could be<br>
efficiently transmitted to include your own blocks.<br></blockquote><div><b=
r></div><div>Makes perfect sense. Also, if I&#39;m working on an exotic blo=
ck, the probability of someone extending my weak block would be low-ish, so=
 I&#39;m not necessarily &quot;giving away fast propagation times to someon=
e else&quot; as I first thought.</div><div>=C2=A0</div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;borde=
r-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
You could also ask a question of why would you transitively relay<br>
someone elses announcement-- well if it helped their blocks too=C2=A0 (by<b=
r>
reflecting things they also want to mine) the answer is obvious. But<br>
what if it was disjoint from the things they wanted to mine and didn&#39;t<=
br>
help compared to the weak blocks they already relayed?=C2=A0 In that case<b=
r>
it&#39;s still in likely in their interest to relay it because if a block<b=
r>
similar to it is produced and they extend that block they may end up<br>
orphaned because of propagation delays their parent block suffered.<br>
What if they receive an announcement which is so &quot;ugly&quot; that they=
<br>
wouldn&#39;t extend the chain with the strong block version of it (they&#39=
;d<br>
intentionally try to fork it off?)-- in that case they wouldn&#39;t want<br=
>
to relay it.=C2=A0 So much the same logic as why you relay other parties<br=
>
blocks applies, including-- relaying helps the network, but if you<br>
don&#39;t it&#39;ll still get along fine without you.<br>
</blockquote></div><br></div><div class=3D"gmail_extra"><div class=3D"gmail=
_extra">Thank you very much for your explanation.</div><div class=3D"gmail_=
extra"><br></div><div class=3D"gmail_extra">/Kalle=C2=A0</div></div><div cl=
ass=3D"gmail_extra"><br></div></div>

--089e01184b0c5c3fea0520ca8369--