Jorge Tim贸n [ARCHIVE] on Nostr: 馃搮 Original date posted:2015-12-26 馃摑 Original message:The hashpower is a ...
馃搮 Original date posted:2015-12-26
馃摑 Original message:The hashpower is a function of the block reward (subsidy + fees): it's
economically irrational to have costs greater than the reward (better just
turn off your miners) and in a perfect competition (a theoretical model)
profits tend to zero. That is, the costs tend to equal revenue (block
reward).
On Dec 26, 2015 6:38 PM, "Eric Lombrozo" <elombrozo at gmail.com> wrote:
> For simplicity, assume total network hashpower is constant. Also, assume
> the soft fork activates at the beginning of a retarget period.
>
> At the moment the soft fork activates, the effective difficulty is
> increased (by adding a second independent PoW check that must also be
> satisfied) which means more hashes on average (and proportionally more
> time) are required to find a block. At the end of the retarget period, the
> difficulty is lowered so that if the second PoW difficulty were to be kept
> constant the block interval would again average 10 mins.
>
> If we were to keep the second PoW difficulty constant, we would restore
> the same total PoW-to-time-unit ratio and the retarget difficulty would
> stabilize again so each block would once more require the same number of
> hashes (and same amount of time) on average as before.
>
> But we don't keep the second PoW difficulty constant - we increase it so
> once again more hashes on average are required to find a block by the same
> proportion as before. And we keep doing this.
>
> Now, the assumption that hashpower is constant is obviously unrealistic.
> If this is your bone of contention, then yes, I agree my model is overly
> simplistic.
>
> My larger point was to explore the extent of what's possible with only a
> soft fork - and we can actually go pretty far and even compensate for these
> economic shifts by increasing block size and rewards. The whole thing is
> clearly a huge mess - and I wouldn't recommend actually doing it.
>
>
>
> On December 26, 2015 7:33:53 AM PST, "Jorge Tim贸n" <jtimon at jtimon.cc>
> wrote:
>>
>>
>> On Dec 26, 2015 9:24 AM, "Eric Lombrozo via bitcoin-dev" <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> > Unfortunately, this also means longer confirmation times, lower
>> throughput, and lower miner revenue. Note, however, that confirmations
>> would (on average) represent more PoW, so fewer confirmations would be
>> required to achieve the same level of security.
>> >
>>
>> I'm not sure I understand this. If mining revenue per unit of time drops,
>> total pow per unit of time should also drop. Even if the inter-block time
>> is increased, it's not clear to me that the pow per block would necessarily
>> be higher.
>> What am I missing?
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151226/f9473770/attachment.html>;
馃摑 Original message:The hashpower is a function of the block reward (subsidy + fees): it's
economically irrational to have costs greater than the reward (better just
turn off your miners) and in a perfect competition (a theoretical model)
profits tend to zero. That is, the costs tend to equal revenue (block
reward).
On Dec 26, 2015 6:38 PM, "Eric Lombrozo" <elombrozo at gmail.com> wrote:
> For simplicity, assume total network hashpower is constant. Also, assume
> the soft fork activates at the beginning of a retarget period.
>
> At the moment the soft fork activates, the effective difficulty is
> increased (by adding a second independent PoW check that must also be
> satisfied) which means more hashes on average (and proportionally more
> time) are required to find a block. At the end of the retarget period, the
> difficulty is lowered so that if the second PoW difficulty were to be kept
> constant the block interval would again average 10 mins.
>
> If we were to keep the second PoW difficulty constant, we would restore
> the same total PoW-to-time-unit ratio and the retarget difficulty would
> stabilize again so each block would once more require the same number of
> hashes (and same amount of time) on average as before.
>
> But we don't keep the second PoW difficulty constant - we increase it so
> once again more hashes on average are required to find a block by the same
> proportion as before. And we keep doing this.
>
> Now, the assumption that hashpower is constant is obviously unrealistic.
> If this is your bone of contention, then yes, I agree my model is overly
> simplistic.
>
> My larger point was to explore the extent of what's possible with only a
> soft fork - and we can actually go pretty far and even compensate for these
> economic shifts by increasing block size and rewards. The whole thing is
> clearly a huge mess - and I wouldn't recommend actually doing it.
>
>
>
> On December 26, 2015 7:33:53 AM PST, "Jorge Tim贸n" <jtimon at jtimon.cc>
> wrote:
>>
>>
>> On Dec 26, 2015 9:24 AM, "Eric Lombrozo via bitcoin-dev" <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> > Unfortunately, this also means longer confirmation times, lower
>> throughput, and lower miner revenue. Note, however, that confirmations
>> would (on average) represent more PoW, so fewer confirmations would be
>> required to achieve the same level of security.
>> >
>>
>> I'm not sure I understand this. If mining revenue per unit of time drops,
>> total pow per unit of time should also drop. Even if the inter-block time
>> is increased, it's not clear to me that the pow per block would necessarily
>> be higher.
>> What am I missing?
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151226/f9473770/attachment.html>;