public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Peter R <peter_r@gmx.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Weak block thoughts...
Date: Wed, 23 Sep 2015 09:28:20 -0700	[thread overview]
Message-ID: <64D181DA-05F6-4636-8F44-0FA63B758947@gmx.com> (raw)
In-Reply-To: <CABsx9T2+dG0AE+MgKRAU97KhkHTU1MuxXuwHKv3BgpJswZ5vVg@mail.gmail.com>

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

Hi Gavin,

One thing that's not clear to me is whether it is even necessary--from the perspective of the block size limit--to consider block propagation.  Bitcoin has been successfully operating unconstrained by the block size limit over its entire history (except for in the past few months)--block propagation never entered into the equation.  

Imagine that the limit were raised to significantly above the free market equilibrium block size Q*.  Mining pools and other miners would then have an incentive to work out schemes like "weak blocks," relay networks, IBLTs, etc., in order to reduce the risk of orphaning larger blocks (blocks with more fees that they'd like to produce if it were profitable).  

Shouldn't mining pools and miners be paying you guys for coding solutions that improve their profitability?   

Best regards,
Peter


On 2015-09-23, at 8:43 AM, Gavin Andresen via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

> I've been thinking about 'weak blocks' and SPV mining, and it seems to me weak blocks will make things better, not worse, if we improve the mining code a little bit.
> 
> First:  the idea of 'weak blocks' (hat tip to Rusty for the term) is for miners to pre-announce blocks that they're working on, before they've solved the proof-of-work puzzle. To prevent DoS attacks, assume that some amount of proof-of-work is done (hence the term 'weak block') to rate-limit how many 'weak block' messages are relayed across the network.
> 
> 
> Today, miners are incentivized to start mining an empty block as soon as they see a block with valid proof-of-work, because they want to spend as little time as possible mining a not-best chain.
> 
> 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-- basically, as fast as a single packet can be relayed across the network the whole network could be mining on the new block.
> 
> I don't see any barrier to making accepting the full-difficulty block and CreateNewBlock() insanely fast, and if those operations take just a microsecond or three, miners will have an incentive to create blocks with fee-paying transactions that weren't in the last block, rather than mining empty blocks.
> 
> .................
> 
> 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 validating miners, though, because they WOULD have to mine empty blocks between the time a full block is found and a fully-validating miner announced their next weak block.
> 
> .................
> 
> Weak block announcements are great for the network; they give transaction creators a pretty good idea of whether or not their transactions are likely to be confirmed in the next block. And if we're smart about implementing them, they shouldn't increase bandwidth or CPU usage significantly, because all the weak blocks at a given point in time are likely to contain the same transactions.
> 
> -- 
> --
> Gavin Andresen
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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

  parent reply	other threads:[~2015-09-23 16:28 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
2015-09-28 13:30                 ` Jonathan Toomim (Toomim Bros)
2015-09-23 16:07 ` Btc Drak
2015-09-23 16:28 ` Peter R [this message]
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=64D181DA-05F6-4636-8F44-0FA63B758947@gmx.com \
    --to=peter_r@gmx.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=gavinandresen@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