public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Tom Zander <tomz@freedommail.ch>
To: bitcoin-dev@lists.linuxfoundation.org,
	Btc Ideas <btcideas@protonmail.com>
Subject: Re: [bitcoin-dev] Encouraging good miners
Date: Mon, 27 Mar 2017 19:29:57 +0200	[thread overview]
Message-ID: <7350662.8AQMRkRU5C@cherry> (raw)
In-Reply-To: <uQBxE-Qbd-osime4uulMZZHdF_D7usA2EKsPjkTyXCHM0OakN2Wdoeriyrc73yWp5c5ULQNkIsRXAM64cCom7ecPvdwmatOyc9Kh1sTDpl4=@protonmail.com>

For some time now the relation between block size and propagation speed has 
been decoupled. Using xthin/compact blocks miners only send a tiny version 
of a block which then causes the receiving node to re-create it using the 
memory pool.  Immediately getting double benefits by including pre-verified 
transactions from the memory pool you avoid the old problem of having to 
validate them again when a block was mined.

As such there is no downside to a miner creating a bigger block, as long as 
all the transactions they include are actually in the mempool.

As such I'm personally convinced that the problem you are trying to solve 
has already been solved.

Cheers!


On Monday, 27 March 2017 18:12:19 CEST Btc Ideas via bitcoin-dev wrote:
> Add a preference for mined blocks to be the one with more transactions.
> This comes into play when 2 blocks of the same height are found. The
> first good block mined would be orphaned if it had less transactions than
> another. Optionally, have this rule apply to the current block and the
> previous one.
> 
> This increases incentive for full blocks because a miner thinking the
> faster propagation of a smaller block will win him the reward, but that
> would no longer be a good assumption.


-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel


  parent reply	other threads:[~2017-03-27 17:27 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-27 16:12 [bitcoin-dev] Encouraging good miners Btc Ideas
2017-03-27 16:29 ` Jameson Lopp
     [not found] ` <WM!6b16e14ff3d44b0c6c0030538191fb22c33a979bb09131ef246ffc477e216212e64cfae815c6af871886f74be6b38d7f!@mailhub-mx4.ncl.ac.uk>
     [not found]   ` <VI1PR0701MB2240F0890E5F19E53CF94B43B5330@VI1PR0701MB2240.eurprd07.prod.outlook.com>
     [not found]     ` <WM!1f99375705714ae4f8b1288ea47707c53f573e0597317337d41d22e28f801234a0d946b8ef05335cccb825f27bdd72da!@mailhub-mx2.ncl.ac.uk>
2017-03-27 16:29       ` Btc Ideas
2017-03-27 17:29 ` Tom Zander [this message]
2017-03-27 20:01   ` Eric Voskuil
2017-03-27 17:50 ` Stian Ellingsen
2017-03-28 14:38   ` Juan Garavaglia
2017-03-27 20:56 ` Antoine Le Calvez

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=7350662.8AQMRkRU5C@cherry \
    --to=tomz@freedommail.ch \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=btcideas@protonmail.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