From: "Jakob Rönnbäck" <jakob.ronnback@me•com>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Adjusted difficulty depending on relative blocksize
Date: Fri, 14 Aug 2015 16:48:48 +0200 [thread overview]
Message-ID: <116B26BD-D8E8-4AFD-A619-2EAC348DA5E6@me.com> (raw)
In-Reply-To: <A6B32C22-4006-434E-9B89-D7C99B5743A8@me.com>
[-- Attachment #1: Type: text/plain, Size: 1757 bytes --]
> 14 aug 2015 kl. 16:20 skrev Anthony Towns <aj@erisian•com.au <mailto:aj@erisian•com.au>>:
>
> On 14 August 2015 at 11:59, Jakob Rönnbäck <bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote:
> 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)
>
> That would mean that as usage grew, blocksize could increase, but confirmation times would also increase (though presumably less than linearly). That seems like a loss?
>
Would that really be the case though? If it takes 5% to find a block, but it contains 5% more transactions would that not mean it’s the same? That would argue against the change if not for the fact that the blocks will be bigger for the next difficulty period.
> If you also let the increase in confirmation time (due to miners finding harder blocks rather than a reduction in hashpower) then get reflected back as decreased difficulty, it'd probably be simpler to just dynamically adjust the max blocksize wouldn't it?
>
I guess that could make the difficulty fluctuate a bit depending on the amount of transactions and the fees being paid. Would it really matter in the long run though? Since it’s the same amount of miners, doesn’t that just mean it’s just the number that is lower, not the actual investment needed to mine the blocks? Not sure if this would open up some forms of attacks on the system for someone willing to lose money though…
Very good feedback though, thanks a lot :)
/jakob
[-- Attachment #2: Type: text/html, Size: 3470 bytes --]
next prev parent reply other threads:[~2015-08-14 14:49 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
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 [this message]
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=116B26BD-D8E8-4AFD-A619-2EAC348DA5E6@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