From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 6579415D8 for ; 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 ; Mon, 28 Sep 2015 08:30:43 +0000 (UTC) Received: by igbkq10 with SMTP id kq10so47866258igb.0 for ; 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: References: Date: Mon, 28 Sep 2015 10:30:42 +0200 Message-ID: From: Kalle Rosenbaum To: Gregory Maxwell 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 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: 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 : > On Sun, Sep 27, 2015 at 3:10 PM, Kalle Rosenbaum via bitcoin-dev > 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
2015= -09-27 21:50 GMT+02:00 Gregory Maxwell <gmaxwell@gmail.com>= :
On Sun, Sep 27, 2015 at 3:10 PM, Kal= le Rosenbaum via bitcoin-dev
<bitcoin-dev@li= sts.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 tha= t I will
> actually solve the block, so I'm probably just giving away fast pr= opagation
> times to someone else.
> So how does publishing a weak block benefit the producer of it more th= an the
> other miners? Please help me understand this.

Keep in mind, because of efficient differential transmission the cos= t
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.

=C2=A0
Suppose that you've solved a blo= ck 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? 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 "= 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'= s part of the answer to my question.
=C2=A0
Lets imagine an alternative weak-blockless weak block implementation:

Every N seconds, every miner send to every other miner what they're
working on.=C2=A0 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 se= nt is proportional to the improvement you get when finding a block." -= This encapsulates the issue quite well! The more exotic block I'm buil= ding, the more I would benefit from publishing a weak block, but my weak bl= ock would also be larger.
=C2=A0

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?<= br> =C2=A0No 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 blo= ck, the probability of someone extending my weak block would be low-ish, so= I'm not necessarily "giving away fast propagation times to someon= e else" as I first thought.
=C2=A0
You could also ask a question of why would you transitively relay
someone elses announcement-- well if it helped their blocks too=C2=A0 (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<= br> help compared to the weak blocks they already relayed?=C2=A0 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.=C2=A0 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=C2=A0

--089e01184b0c5c3fea0520ca8369--