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 --]
next prev parent 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 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$(echo .)se \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=gmaxwell@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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