From: Gregory Maxwell <gmaxwell@gmail•com>
To: Bryan Bishop <kanzure@gmail•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Weak block thoughts...
Date: Wed, 23 Sep 2015 19:24:06 +0000 [thread overview]
Message-ID: <CAAS2fgTr-OuL3T6mXX-4xFC_LHnAiogTTcPMbcjsM7WtRisQEQ@mail.gmail.com> (raw)
In-Reply-To: <CABaSBaxcDRzw0X7-fAfxPJyLcWxTHigpHuAPb4aNQ5zk5NoDCQ@mail.gmail.com>
On Wed, Sep 23, 2015 at 4:07 PM, Bryan Bishop via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> more recently:
> http://gnusha.org/bitcoin-wizards/2015-09-20.log
> http://diyhpl.us/wiki/transcripts/scalingbitcoin/roundgroup-roundup-1/
> http://diyhpl.us/wiki/transcripts/scalingbitcoin/bitcoin-block-propagation-iblt-rusty-russell/
See also my response to Peter R's paper that was republished to the
list at http://pastebin.com/jFgkk8M3
(See sections at "For example, imagine if miners only include
transactions that were previously committed" and especially "Miners
volutarily participate in a fast consensus mechenism which commits to
transactions")
On Wed, Sep 23, 2015 at 3:43 PM, Gavin Andresen via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> Imagine miners always pre-announce the blocks they're working on to their
> peers, and peers validate those 'weak blocks' as quickly as they are able.
>
> Because weak blocks are pre-validated, when a full-difficulty block based on
> a previously announced weak block is found, block propagation should be
> insanely fast--
[...]
> A miner could try to avoid validation work by just taking a weak block
> announced by somebody else, replacing the coinbase and re-computing the
> merkle root, and then mining. They will be at a slight disadvantage to fully
Take care, here-- if a scheme is used where e.g. the full solution had
to be exactly identical to a prior weak block then the result would be
making mining not progress free because bigger miners would have
disproportionately more access to the weak/strong one/two punch. I
think what you're thinking here is okay, but it wasn't clear to me if
you'd caught that particular potential issue.
Avoiding this is why I've always previously described this idea as
merged mined block DAG (with blocks of arbitrary strength) which are
always efficiently deferentially coded against prior state. A new
solution (regardless of who creates it) can still be efficiently
transmitted even if it differs in arbitrary ways (though the
efficiency is less the more different it is).
There is a cost to these schemes-- additional overhead from
communicating the efficiently encoded weak blocks. But participation
in this overhead is optional and doesn't impact the history.
I'm unsure of what approach to take for incentive compatibility
analysis. In the worst case this approach class has no better delays
(and higher bandwidth); but it doesn't seem to me to give rise to any
immediate incrementally strategic behavior (or at least none worse
than you'd get from just privately using the same scheme).
On Wed, Sep 23, 2015 at 4:28 PM, Peter R via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> Shouldn't mining pools and miners be paying you guys for coding solutions
> that improve their profitability?
The income to miners as a whole doesn't depend on these sorts of
optimizations, competitive advantages do... so better common open
infrastructure helps mostly in the case of putting propagation
disadvantaged miners on an equal playing field. You'll note that none
of them are exactly sharing their SPV mining source code right now....
in any case, there are simple, expedient, and low risk ways to improve
their equality in that respect: centralize (e.g. use bigger pools).
next prev parent reply other threads:[~2015-09-23 19:24 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 [this message]
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
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=CAAS2fgTr-OuL3T6mXX-4xFC_LHnAiogTTcPMbcjsM7WtRisQEQ@mail.gmail.com \
--to=gmaxwell@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=kanzure@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