From: Tom Harding <tomh@thinlink.com>
To: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Adjusted difficulty depending on relative blocksize
Date: Fri, 14 Aug 2015 15:12:54 -0700 [thread overview]
Message-ID: <55CE67E6.3020905@thinlink.com> (raw)
In-Reply-To: <CALqxMTGHiQ_EBfquF8T82H6doueaH04DTmGY9wf5nVhD0kcMgg@mail.gmail.com>
Nobody mentioned exchange rates. Those matter to miners too.
Does it make sense for George Soros and every other rich person /
institution to have the power to move difficulty, even pin it to min or
max, just by buying or selling piles of BTC to swing the exchange rate?
On 8/14/2015 8:03 AM, Adam Back via bitcoin-dev wrote:
> There is a proposal that relates to this, see the flexcap proposal by
> Greg Maxwell & Mark Friedenbach, it was discussed on the list back in
> May:
>
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008017.html
>
> and http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008038.html
>
> Adam
>
> On 14 August 2015 at 15:48, Jakob Rönnbäck
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> 14 aug 2015 kl. 16:20 skrev Anthony Towns <aj@erisian.com.au>:
>>
>> On 14 August 2015 at 11:59, Jakob Rönnbäck
>> <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
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
prev parent reply other threads:[~2015-08-14 22:12 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-14 9:59 [bitcoin-dev] Adjusted difficulty depending on relative blocksize 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
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 [this message]
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=55CE67E6.3020905@thinlink.com \
--to=tomh@thinlink.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
/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