public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Jakob Rönnbäck" <jakob.ronnback@me•com>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: [bitcoin-dev] Adjusted difficulty depending on relative blocksize
Date: Fri, 14 Aug 2015 11:59:32 +0200	[thread overview]
Message-ID: <09C8843E-8379-404D-8357-05BDB1F749C1@me.com> (raw)

Greetings,

a thought occurred to me that I would love to hear what some bitcoin experts think about.

What if one were to adjust the difficulty (for individual blocks) depending on the relative size to the average block size of the previous difficulty period? (I apologize if i’m not using the correct terms, I’m not a real programmer, and I’ve only recently started to subscribe to the mailing list)


In practice:

1. calculate average block size for the previous difficulty period (is it 2016-blocks?)
2. when trying to find a new block adjust the difficulty by adding the relative size difference. For instance, if i’m trying to create a block half (or double) the size of the average block size for the previous difficulty period then my difficulty will be 2x the normal one… if I’m trying to make one that is 30% bigger (or smaller) then the difficulty is 1.3 times the normal one


Right now this would force miners to make blocks as close to 1mb as possible (since the block reward >> fees). But unless I’m mistaken sometime in the future the block size should be adjusted to maximize the fees…


Could the concept be useful somehow?

I apologize if it’s been discussed before or if it’s a stupid idea, I would have run it by some other people, but I’m afraid I don’t know anyone that have any interest in bitcoin.

Regards
/jakob

             reply	other threads:[~2015-08-14 11:00 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-14  9:59 Jakob Rönnbäck [this message]
2015-08-14 13:32 ` Angel Leon
2015-08-14 14:19   ` Jakob Rönnbäck
2015-08-14 16:37     ` [bitcoin-dev] libconsensus assertion fails if used in multiple threads Tamas Blummer
2015-08-14 21:10       ` Cory Fields
2015-08-18  5:03         ` Cory Fields
2015-08-18 10:31           ` Tamas Blummer
2015-08-18 17:25             ` Cory Fields
2015-08-18 17:50               ` Cory Fields
2015-08-18 21:40             ` Eric Voskuil
2015-08-14 14:20 ` [bitcoin-dev] Adjusted difficulty depending on relative blocksize Anthony Towns
     [not found]   ` <A6B32C22-4006-434E-9B89-D7C99B5743A8@me.com>
2015-08-14 14:48     ` Jakob Rönnbäck
2015-08-14 15:00       ` Anthony Towns
2015-08-14 15:03       ` Adam Back
2015-08-14 15:14         ` Jakob Rönnbäck
2015-09-09  3:27           ` Tom Harding
2015-09-09 18:59             ` Warren Togami Jr.
2015-09-09 19:53               ` Tom Harding
2015-08-14 22:12         ` Tom Harding

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=09C8843E-8379-404D-8357-05BDB1F749C1@me.com \
    --to=jakob.ronnback@me$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    /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