public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Kalle Rosenbaum <kalle@rosenbaum.se>
To: Gregory Maxwell <gmaxwell@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Weak block thoughts...
Date: Mon, 28 Sep 2015 10:30:42 +0200	[thread overview]
Message-ID: <CAPswA9xei1UNMeNqi=XzSnZU=SeroaeKN_6xHJ0HfhgXBzY_mw@mail.gmail.com> (raw)
In-Reply-To: <CAAS2fgRX-LLiNwcmbHtF6ymEX+uUx3SNjqAe4iyxouhHj=4Abw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4893 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 6520 bytes --]

  reply	other threads:[~2015-09-28  8:30 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-23 15:43 [bitcoin-dev] Weak block thoughts Gavin Andresen
2015-09-23 16:07 ` Bryan Bishop
2015-09-23 19:24   ` Gregory Maxwell
2015-09-23 21:37     ` Gavin Andresen
2015-09-23 22:16       ` Jonathan Toomim (Toomim Bros)
2015-09-24  1:11       ` Rusty Russell
2015-09-27  1:39       ` Gregory Maxwell
2015-09-27  9:42         ` Tier Nolan
2015-09-27 15:10           ` Kalle Rosenbaum
2015-09-27 19:50             ` Gregory Maxwell
2015-09-28  8:30               ` Kalle Rosenbaum [this message]
2015-09-28 13:30                 ` Jonathan Toomim (Toomim Bros)
2015-09-23 16:07 ` Btc Drak
2015-09-23 16:28 ` Peter R
2015-09-23 17:40   ` Gavin
2015-09-23 17:49     ` Peter R
2015-09-23 18:48 ` Tier Nolan
2015-09-24  1:32 ` Rusty Russell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAPswA9xei1UNMeNqi=XzSnZU=SeroaeKN_6xHJ0HfhgXBzY_mw@mail.gmail.com' \
    --to=kalle@rosenbaum.se \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=gmaxwell@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox