From: Gregory Maxwell <gmaxwell@gmail•com>
To: Kalle Rosenbaum <kalle@rosenbaum•se>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Weak block thoughts...
Date: Sun, 27 Sep 2015 19:50:22 +0000 [thread overview]
Message-ID: <CAAS2fgRX-LLiNwcmbHtF6ymEX+uUx3SNjqAe4iyxouhHj=4Abw@mail.gmail.com> (raw)
In-Reply-To: <CAPswA9xFNgdbH1JXBx+CqjT5HbkK0WGaWQLrJzm+BJCmrXRQcA@mail.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.
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.
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.
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.
next prev parent reply other threads:[~2015-09-27 19:50 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 [this message]
2015-09-28 8:30 ` Kalle Rosenbaum
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='CAAS2fgRX-LLiNwcmbHtF6ymEX+uUx3SNjqAe4iyxouhHj=4Abw@mail.gmail.com' \
--to=gmaxwell@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=kalle@rosenbaum$(echo .)se \
/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