<unnamed>

Public Key

npub1s6kl564nallpxservsjs0up8w62ztzlzv06765kzmj85mtscmd0qstds2a

Profile Code

nprofile1qqsgdt06d2e7llsngv3kgfg87qnhd9p9303x8a0d2tpder6d4cvdkhspzpmhxue69uhkummnw3ezuamfdejsz9rhwden5te0wfjkccte9ejxzmt4wvhxjmcpp4mhxue69uhkummn9ekx7mqc9asf2

Publishing to

nostr.wine

relay.damus.io

nos.lol

Last Notes

2023-06-07 15:46:58 UTC

- reply

📅 Original date posted:2015-08-14
📝 Original message:Ah, there we go. I should have dug deeper into the mailing list
Thanks
/jakob
> 14 aug 2015 kl. 17:03 skrev Adam Back <adam at cypherspace.org>:
>
> 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

2023-06-07 15:46:57 UTC

- reply

📅 Original date posted:2015-08-14
📝 Original message:> 14 aug 2015 kl. 16:20 skrev Anthony Towns <aj at erisian.com.au <mailto:aj at erisian.com.au>>:
>
> On 14 August 2015 at 11:59, Jakob Rönnbäck <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150814/855d7a2f/attachment.html>

2023-06-07 15:46:56 UTC

- reply

📅 Original date posted:2015-08-14
📝 Original message: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 at 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 at lists.linuxfoundation.org <mailto:bitcoin-dev at 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 at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150814/d57e6dc3/attachment.html>

2023-06-07 15:46:56 UTC

- reply

📅 Original date posted:2015-08-14
📝 Original message: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