public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Jakob Rönnbäck" <jakob.ronnback@me•com>
To: Angel Leon <gubatron@gmail•com>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Adjusted difficulty depending on relative blocksize
Date: Fri, 14 Aug 2015 16:19:58 +0200	[thread overview]
Message-ID: <D018B1B0-B613-4C05-84BB-02CE6E2FEA3E@me.com> (raw)
In-Reply-To: <CADZB0_YvvDDq4XzfvQeeWJ2oZxPukP0oXYSrEeC3gy9_Fk0ZuA@mail.gmail.com>

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

Hmm… well, yes and no. Mostly no :)

The main idea i was trying to describe was that the actual difficulty for the block could be adjusted according to how much the size of the proposed block differ compared to the average size of blocks in the previous difficulty period. Unless I’m being very dense atm your gist is just about dynamically adjusting the blocksize?


 I’ll give a numeric example to clarify a bit.

Assume the current difficulty was calculated to be 1000, and the average size of the blocks in the period used to calculate the difficulty was 500kb.
Example 1:
I’m now attempting to find a new block with a size of 450 kb, or 450/500 = 10% smaller than average. The difficulty would then be 1000 * 110% = 1100
Example 2:
If I instead was trying to make a block sized 10000 kb, or 10000/500 = 2000% bigger than average the difficulty would be adjusted to 1000*20 = 20000


Why I find this interesting is in a possible future when the block reward is insignificant compared to the transactions fees miners would make bigger blocks as fees rise. A miner could include more transactions into blocks as long as the fees are high enough to offset the reduced chance of actually finding the block. However, I now realize that there wouldn’t be any downward pressure below the average size if the price shrinks (using the particular numbers i have in my examples) though. Maybe this method is only useful on the upside of the blocks, meaning blocks smaller than the average size doesn’t get adjusted difficulty. I need to go for a walk and think this through :)


> 14 aug 2015 kl. 15:32 skrev Angel Leon <gubatron@gmail•com>:
> 
> Like this?
> https://gist.github.com/gubatron/143e431ee01158f27db4 <https://gist.github.com/gubatron/143e431ee01158f27db4>
> 
> http://twitter.com/gubatron <http://twitter.com/gubatron>
> 
> On Fri, Aug 14, 2015 at 5:59 AM, Jakob Rönnbäck <bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote:
> 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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
> 


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

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

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-14  9:59 Jakob Rönnbäck
2015-08-14 13:32 ` Angel Leon
2015-08-14 14:19   ` Jakob Rönnbäck [this message]
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=D018B1B0-B613-4C05-84BB-02CE6E2FEA3E@me.com \
    --to=jakob.ronnback@me$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=gubatron@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