public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [Bitcoin-development] death by halving
@ 2014-10-25 18:06 Alex Mizrahi
  2014-10-25 18:12 ` Jeff Garzik
                   ` (3 more replies)
  0 siblings, 4 replies; 29+ messages in thread
From: Alex Mizrahi @ 2014-10-25 18:06 UTC (permalink / raw)
  To: Bitcoin Dev

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

# Death by halving

## Summary

If miner's income margin are less than 50% (which is a healthy situation
when mining hardware is readily available), we might experience
catastrophic loss of hashpower (and, more importantly, catastrophic loss of
security) after reward halving.

## A simple model

Let's define miner's income margin as `MIM = (R-C_e)/R`, where R is the
total revenue miner receives over a period of time, and C_e is the cost of
electricity spent on mining over the same period of time. (Note that for
the sake of simplicity we do not take into account equipment costs,
amortization and other costs mining might incur.)

Also we will assume that transaction fees collected by miner are negligible
as compared to the subsidy.

Theorem 1. If for a certain miner MIM is less than 0.5 before subsidy
halving and bitcoin and electricity prices stay the same, then mining is no
longer profitable after the halving.

Indeed, suppose the revenue after the halving is R' = R/2.
   MIM = (R-C_e)/R < 0.5
   R/2 < C_e.

   R' = R/2 < C_e.

If revenue after halving R' doesn't cover electricity cost, a rational
miner should stop mining, as it's cheaper to acquire bitcoins from the
market.

~~~

Under these assumptions, if the majority of miners have MIM less than 0.5,
Bitcoin is going to experience a significant loss of hashing power.
But are these assumptions reasonable? We need a study a more complex model
which takes into account changes in bitcoin price and difficulty changes
over time.
But, first, let's analyze significance of 'loss of hashpower'.

## Catastrophic loss of hashpower

Bitcoin security model relies on assumption that a malicious actor cannot
acquire more than 50% of network's current hashpower.
E.g. there is a table in Rosenfeld's _Analysis of Hashrate-Based Double
Spending_ paper which shows that as long as the malicious actor controls
only a small fraction of total hashpower, attacks have well-define costs.
But if the attacker-controlled hashrate is higher than 50%, attacks become
virtually costless, as the attacker receives double-spending revenue on top
of his mining revenue, and his risk is close to zero.

Note that the simple model described in the aforementioned paper doesn't
take into account attack's effect on the bitcoin price and the price of the
Bitcoin mining equipment. I hope that one day we'll see more elaborate
attack models, but in the meantime, we'll have to resort to hand-waving.

Consider a situation where almost all available hashpower is available for
a lease to the highest bidder on the open market. In this case someone who
owns sufficient capital could easily pull off an attack.

But why is hashpower not available on the market? Quite likely equipment
owners are aware of the fact that such an attack would make Bitcoin
useless, and thus worthless, which would also make their equipment
worthless. Thus they prefer to do mining for a known mining pools with good
track record.
(Although hashpower marketplaces exist: https://nicehash.com/ they aren't
particularly popular.)

Now let's consider a situation where mining bitcoins is no longer
profitable and the majority of hashpower became dormant, i.e. miners turned
off their equipment or went to mine something else. In this case equipment
is already nearly worthless, so people might as well lease it to the
highest bidder, thus enabling aforementioned attacks.

Alternatively, the attacker might buy obsolete mining equipment from people
who are no longer interested in mining.

## Taking into account the Bitcoin price

This is largely trivial, and thus is left as an exercise for the reader.
Let's just note that the Bitcoin subsidy halving is an event which is known
to market participants in advance, and thus it shouldn't result in
significant changes of the Bitcoin price,

## Changes in difficulty

Different mining devices have different efficiency. After the reward
halving mining on some of these devices becomes unprofitable, thus they
will drop out, which will result in a drop of mining difficulty.

We can greatly simplify calculations if we sum costs and rewards across all
miners, thus calculating average MIM before the halving: `MIM = 1 - C_e/R`.

Let's consider an equilibrium break-even situation where unprofitable
mining devices were turned off, thus resulting in the change in electricity
expenditures: `C_e' = r * C_e`. and average MIM after the halving `MIM' =
0`. In this case:

    r * C_e = R/2
    C_e / R = 1/2r
    (1 - MIM) = 1/2r
    r = 1/(2*(1-MIM))

Let's evaluate this formulate for different before-halving MIM:

1. If `MIM = 0.5`, then `r = 1/(2*0.5) = 1`, that is, all miners can remain
mining.
2. If `MIM = 0.25`, then `r = 1/(2*0.75) = 0.66`, the least efficient
miners consuming 33% of total electricity costs will drop out.
3. If `MIM = 0.1`, then `r = 1/(2*0.9) = 0.55`, total electricity costs
drop by 45%.

We can note that for the before-halving MIM>0, r is higher than 1/2, thus
less than half of total hashpower will drop out.

The worst-case situation is when before-halving MIM is close to zero and
mining devices, as well as cost of electricity in different places, are
nearly identical, in that case approximately a half of all hashpower will
drop out.

## MIM estimation

OK, what MIM do we expect in the long run? Is it going to be less than 50%
anyway?

We can expect that people will keep buying mining devices as long as it is
profitable.

Break-even condition: `R - C_e - P = 0`, where P is the price of a mining
device, R is the revenue it generates over its lifetime, and C_e is the
total cost of required electricity over its lifetime. In this case, `R =
C_e + P`, and thus:

    MIM = 1 - C_e / (C_e + P)

`f = C_e / P` is a ratio of the cost of electricity to the cost of
hardware, `C_e = f * P`, and thus

    MIM = 1 - f * P / (f * P + P) = 1 - f / (f + 1) = 1 / (1 + f)

MIM is less than 0.5 when f > 1.

Computing f is somewhat challenging even for a concrete device, as it's
useful lifetime is unknown.

Let's do some guesstimation:

Spondoolies Tech's SP35 Yukon unit consumes 3.5 KW and costs $4000. If it's
useful lifetime is more than 2 years and a cost of KWh is $0.1, the total
expenditures on electricity will be at least $6135, thus for this device we
have `f > 6135/4000 > 1.5`.

If other devices which will be sold on the market will have similar specs,
we will have MIM lower than 0.5. (Well, no shit.)

## Conclusions

Reward halving is a deficiency in Bitcoin's design, but there is some hope
it won't be critical: in the equilibrium break-even situation hashpower
drop is less than 50%.
Hashrate might drop by more than 50% immediately after the halving (and
before difficulty is updated), thus a combination of the halving and slow
difficulty update pose a real threat.

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

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [Bitcoin-development] death by halving
  2014-10-25 18:06 [Bitcoin-development] death by halving Alex Mizrahi
@ 2014-10-25 18:12 ` Jeff Garzik
  2014-10-25 18:22   ` Alex Mizrahi
  2014-10-25 20:27 ` [Bitcoin-development] " Adam Back
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 29+ messages in thread
From: Jeff Garzik @ 2014-10-25 18:12 UTC (permalink / raw)
  To: Alex Mizrahi; +Cc: Bitcoin Dev

On Sat, Oct 25, 2014 at 2:06 PM, Alex Mizrahi <alex.mizrahi@gmail•com> wrote:
> Hashrate might drop by more than 50% immediately after the halving (and
> before difficulty is updated), thus a combination of the halving and slow
> difficulty update pose a real threat.

"Flag day" herd behavior like this is unlikely for well informed and
well prepared market participants.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/



^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [Bitcoin-development] death by halving
  2014-10-25 18:12 ` Jeff Garzik
@ 2014-10-25 18:22   ` Alex Mizrahi
  2014-10-25 18:31     ` Jeff Garzik
  0 siblings, 1 reply; 29+ messages in thread
From: Alex Mizrahi @ 2014-10-25 18:22 UTC (permalink / raw)
  To: Bitcoin Dev

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

> "Flag day" herd behavior like this is unlikely for well informed and
> well prepared market participants.
>

It is simply rational to turn your mining device off until difficulty
adjusts.
Keeping mining for 2+ weeks when it costs you money is an altruistic
behavior, we shouldn't rely on this.

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

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [Bitcoin-development] death by halving
  2014-10-25 18:22   ` Alex Mizrahi
@ 2014-10-25 18:31     ` Jeff Garzik
  2014-10-25 19:08       ` Alex Mizrahi
  0 siblings, 1 reply; 29+ messages in thread
From: Jeff Garzik @ 2014-10-25 18:31 UTC (permalink / raw)
  To: Alex Mizrahi; +Cc: Bitcoin Dev

It is an overly-simplistic miner model to assume altruism is
necessary.  The hashpower market is maturing in the direction of
financial instruments, where the owner of the hashpower is not
necessarily the one receiving income.  These are becoming tradeable
instruments, and derivatives and hedging are built on top of that.
Risk is hedged at each layer.  Market players also forge agreements
with miners, and receive -negative- value if hashpower is simply shut
down.

Simplistic models cannot predict what hashpower does in the face of
business-to-business medium- and long-term contracts.


On Sat, Oct 25, 2014 at 2:22 PM, Alex Mizrahi <alex.mizrahi@gmail•com> wrote:
>
>>
>> "Flag day" herd behavior like this is unlikely for well informed and
>> well prepared market participants.
>
>
> It is simply rational to turn your mining device off until difficulty
> adjusts.
> Keeping mining for 2+ weeks when it costs you money is an altruistic
> behavior, we shouldn't rely on this.
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/



^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [Bitcoin-development] death by halving
  2014-10-25 18:31     ` Jeff Garzik
@ 2014-10-25 19:08       ` Alex Mizrahi
  2014-10-25 19:16         ` Gavin Andresen
  0 siblings, 1 reply; 29+ messages in thread
From: Alex Mizrahi @ 2014-10-25 19:08 UTC (permalink / raw)
  To: Bitcoin Dev

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

> The hashpower market is maturing in the direction of
> financial instruments, where the owner of the hashpower is not
> necessarily the one receiving income.  These are becoming tradeable

instruments,


Meni Rosenfeld issued tradeable mining bonds back in 2012:

https://bitcointalk.org/index.php?topic=65569.0

So this is hardly new stuff. But it definitely won't help.
The contract specifies how many bitcoins bondholder would get depending on
difficulty and other factors.
But, usually, bondholder doesn't care (and cannot check) where these
bitcoins come from.

Thus the owner of the mining equipment can temporarily turn off that
equipment off, and instead buy them on the market, as he needs to spend
less money than he would spend on electricity. Then he can pocket the
difference.


> Simplistic models cannot predict what hashpower does in the face of
> business-to-business medium- and long-term contracts.
>

Ah, yes, let's forget game theory, business people know it better!

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

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [Bitcoin-development] death by halving
  2014-10-25 19:08       ` Alex Mizrahi
@ 2014-10-25 19:16         ` Gavin Andresen
  2014-10-25 19:53           ` Alex Mizrahi
  2014-10-28 20:17           ` Ferdinando M. Ametrano
  0 siblings, 2 replies; 29+ messages in thread
From: Gavin Andresen @ 2014-10-25 19:16 UTC (permalink / raw)
  To: Alex Mizrahi; +Cc: Bitcoin Dev

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

We had a halving, and it was a non-event.

Is there some reason to believe next time will be different?

-- 
--
Gavin Andresen

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

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [Bitcoin-development] death by halving
  2014-10-25 19:16         ` Gavin Andresen
@ 2014-10-25 19:53           ` Alex Mizrahi
  2014-10-25 21:50             ` Melvin Carvalho
  2014-10-28 20:17           ` Ferdinando M. Ametrano
  1 sibling, 1 reply; 29+ messages in thread
From: Alex Mizrahi @ 2014-10-25 19:53 UTC (permalink / raw)
  To: Gavin Andresen; +Cc: Bitcoin Dev

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

> We had a halving, and it was a non-event.
> Is there some reason to believe next time will be different?
>

Yes.

When the market is rapidly growing, margins can be relatively high because
of limited amounts of capital being invested, or introduction of more
efficient technologies.

However, we should expect market to become more mature with time, and a
mature market will result in lower margins.
The halving can do much more damage when margins are relatively small.

Besides that, there is a difference in ecosystem maturity:

1. Back in 2012, miners weren't so focused on profits, as Bitcoin was
highly experimental: some were mining for the hell of it (it was a novelty
thing back then), others wanted to secure the network, others did it
because it was hard to obtain bitcoins by other means. But now miners are
mostly profit-motivated: they buy expensive dedicated mining equipment and
want to maximize profits. As you might know, at one point ghash.io reached
50% hashrate, and miners didn't care about it enough to switch to a
different pool.

2. Back in 2012, we didn't have multipools. Multipools automatically
switches between mining different alt-chains to maximize miners' profits.
Miners who use multipools do not care how their hashrate is used as long as
they profit off it.
Particularly, check https://nicehash.com/ -- you can easily buy hashrate to
attack a smaller alt-coin, for example.

If the halving will result in a significant hashrate drop (and we did
observe hashrate drop in 2012, although it wasn't that big), it might be
possible to buy enough hashpower to attack Bitcoin.

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

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [Bitcoin-development] death by halving
  2014-10-25 18:06 [Bitcoin-development] death by halving Alex Mizrahi
  2014-10-25 18:12 ` Jeff Garzik
@ 2014-10-25 20:27 ` Adam Back
  2014-10-25 20:43   ` Thomas Zander
  2014-10-25 20:28 ` Thomas Zander
  2014-10-25 22:10 ` Ross Nicoll
  3 siblings, 1 reply; 29+ messages in thread
From: Adam Back @ 2014-10-25 20:27 UTC (permalink / raw)
  To: Alex Mizrahi; +Cc: Bitcoin Dev

Some thoughts about Alex's analysis:

- bitcoin price may increase (though doubling immediately might be
unlikely) after the halving (because the new coins are in short
supply). Apparently there is some evidence of a feedback loop between
number of freshly mined coins sold to cover electrical costs ongoing
(which depends on halving also), in that there are claims that the btc
price experiences some downwards pressure when margins are slim as
miners sell almost all of them when the electrical cost takes most of
the profit, and otherwise tend more to hold coins longer term.

- that people who cant make money mining with 1/2 reward will resort
to attacking the network rather than living with it for 2weeks until
difficulty adjustment).  actually it will be longer than two weeks if
its going to result in a difficulty fall.

- that the miners wont act in their own meta-interest to aim for the
plausible new hashrate supported by the lower reward.  mining
equipment investment horizon being 3-6mo+ so it can easily make
economic sense to subsidise it for a bit to smooth the transition.

- fees might go up to unjam the network also, so the people
benefitting from the transactions utility also help cover the
transition costs.  or maybe someone makes an assurance contract to pay
the short fall and phase it out over a few months to smooth the shift.

- there is a wide range of electrical efficiency, and some are much
worse than others so there maybe a convenient equilibrium where there
are enough left who can still profit.

- alternatively you might say why not 1/100th reward reduction per 2
week period rather than 1/2 every 4 years, a difficulty retarget could
be a convenient point to do that.

Adam

On 25 October 2014 11:06, Alex Mizrahi <alex.mizrahi@gmail•com> wrote:
> # Death by halving
>
> ## Summary
>
> If miner's income margin are less than 50% (which is a healthy situation
> when mining hardware is readily available), we might experience catastrophic
> loss of hashpower (and, more importantly, catastrophic loss of security)
> after reward halving.
>
> ## A simple model
>
> Let's define miner's income margin as `MIM = (R-C_e)/R`, where R is the
> total revenue miner receives over a period of time, and C_e is the cost of
> electricity spent on mining over the same period of time. (Note that for the
> sake of simplicity we do not take into account equipment costs, amortization
> and other costs mining might incur.)
>
> Also we will assume that transaction fees collected by miner are negligible
> as compared to the subsidy.
>
> Theorem 1. If for a certain miner MIM is less than 0.5 before subsidy
> halving and bitcoin and electricity prices stay the same, then mining is no
> longer profitable after the halving.
>
> Indeed, suppose the revenue after the halving is R' = R/2.
>    MIM = (R-C_e)/R < 0.5
>    R/2 < C_e.
>
>    R' = R/2 < C_e.
>
> If revenue after halving R' doesn't cover electricity cost, a rational miner
> should stop mining, as it's cheaper to acquire bitcoins from the market.
>
> ~~~
>
> Under these assumptions, if the majority of miners have MIM less than 0.5,
> Bitcoin is going to experience a significant loss of hashing power.
> But are these assumptions reasonable? We need a study a more complex model
> which takes into account changes in bitcoin price and difficulty changes
> over time.
> But, first, let's analyze significance of 'loss of hashpower'.
>
> ## Catastrophic loss of hashpower
>
> Bitcoin security model relies on assumption that a malicious actor cannot
> acquire more than 50% of network's current hashpower.
> E.g. there is a table in Rosenfeld's _Analysis of Hashrate-Based Double
> Spending_ paper which shows that as long as the malicious actor controls
> only a small fraction of total hashpower, attacks have well-define costs.
> But if the attacker-controlled hashrate is higher than 50%, attacks become
> virtually costless, as the attacker receives double-spending revenue on top
> of his mining revenue, and his risk is close to zero.
>
> Note that the simple model described in the aforementioned paper doesn't
> take into account attack's effect on the bitcoin price and the price of the
> Bitcoin mining equipment. I hope that one day we'll see more elaborate
> attack models, but in the meantime, we'll have to resort to hand-waving.
>
> Consider a situation where almost all available hashpower is available for a
> lease to the highest bidder on the open market. In this case someone who
> owns sufficient capital could easily pull off an attack.
>
> But why is hashpower not available on the market? Quite likely equipment
> owners are aware of the fact that such an attack would make Bitcoin useless,
> and thus worthless, which would also make their equipment worthless. Thus
> they prefer to do mining for a known mining pools with good track record.
> (Although hashpower marketplaces exist: https://nicehash.com/ they aren't
> particularly popular.)
>
> Now let's consider a situation where mining bitcoins is no longer profitable
> and the majority of hashpower became dormant, i.e. miners turned off their
> equipment or went to mine something else. In this case equipment is already
> nearly worthless, so people might as well lease it to the highest bidder,
> thus enabling aforementioned attacks.
>
> Alternatively, the attacker might buy obsolete mining equipment from people
> who are no longer interested in mining.
>
> ## Taking into account the Bitcoin price
>
> This is largely trivial, and thus is left as an exercise for the reader.
> Let's just note that the Bitcoin subsidy halving is an event which is known
> to market participants in advance, and thus it shouldn't result in
> significant changes of the Bitcoin price,
>
> ## Changes in difficulty
>
> Different mining devices have different efficiency. After the reward halving
> mining on some of these devices becomes unprofitable, thus they will drop
> out, which will result in a drop of mining difficulty.
>
> We can greatly simplify calculations if we sum costs and rewards across all
> miners, thus calculating average MIM before the halving: `MIM = 1 - C_e/R`.
>
> Let's consider an equilibrium break-even situation where unprofitable mining
> devices were turned off, thus resulting in the change in electricity
> expenditures: `C_e' = r * C_e`. and average MIM after the halving `MIM' =
> 0`. In this case:
>
>     r * C_e = R/2
>     C_e / R = 1/2r
>     (1 - MIM) = 1/2r
>     r = 1/(2*(1-MIM))
>
> Let's evaluate this formulate for different before-halving MIM:
>
> 1. If `MIM = 0.5`, then `r = 1/(2*0.5) = 1`, that is, all miners can remain
> mining.
> 2. If `MIM = 0.25`, then `r = 1/(2*0.75) = 0.66`, the least efficient miners
> consuming 33% of total electricity costs will drop out.
> 3. If `MIM = 0.1`, then `r = 1/(2*0.9) = 0.55`, total electricity costs drop
> by 45%.
>
> We can note that for the before-halving MIM>0, r is higher than 1/2, thus
> less than half of total hashpower will drop out.
>
> The worst-case situation is when before-halving MIM is close to zero and
> mining devices, as well as cost of electricity in different places, are
> nearly identical, in that case approximately a half of all hashpower will
> drop out.
>
> ## MIM estimation
>
> OK, what MIM do we expect in the long run? Is it going to be less than 50%
> anyway?
>
> We can expect that people will keep buying mining devices as long as it is
> profitable.
>
> Break-even condition: `R - C_e - P = 0`, where P is the price of a mining
> device, R is the revenue it generates over its lifetime, and C_e is the
> total cost of required electricity over its lifetime. In this case, `R = C_e
> + P`, and thus:
>
>     MIM = 1 - C_e / (C_e + P)
>
> `f = C_e / P` is a ratio of the cost of electricity to the cost of hardware,
> `C_e = f * P`, and thus
>
>     MIM = 1 - f * P / (f * P + P) = 1 - f / (f + 1) = 1 / (1 + f)
>
> MIM is less than 0.5 when f > 1.
>
> Computing f is somewhat challenging even for a concrete device, as it's
> useful lifetime is unknown.
>
> Let's do some guesstimation:
>
> Spondoolies Tech's SP35 Yukon unit consumes 3.5 KW and costs $4000. If it's
> useful lifetime is more than 2 years and a cost of KWh is $0.1, the total
> expenditures on electricity will be at least $6135, thus for this device we
> have `f > 6135/4000 > 1.5`.
>
> If other devices which will be sold on the market will have similar specs,
> we will have MIM lower than 0.5. (Well, no shit.)
>
> ## Conclusions
>
> Reward halving is a deficiency in Bitcoin's design, but there is some hope
> it won't be critical: in the equilibrium break-even situation hashpower drop
> is less than 50%.
> Hashrate might drop by more than 50% immediately after the halving (and
> before difficulty is updated), thus a combination of the halving and slow
> difficulty update pose a real threat.
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>



^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [Bitcoin-development] death by halving
  2014-10-25 18:06 [Bitcoin-development] death by halving Alex Mizrahi
  2014-10-25 18:12 ` Jeff Garzik
  2014-10-25 20:27 ` [Bitcoin-development] " Adam Back
@ 2014-10-25 20:28 ` Thomas Zander
  2014-10-25 20:49   ` Alex Mizrahi
  2014-10-25 22:10 ` Ross Nicoll
  3 siblings, 1 reply; 29+ messages in thread
From: Thomas Zander @ 2014-10-25 20:28 UTC (permalink / raw)
  To: bitcoin-development

On Saturday 25. October 2014 21.06.32 Alex Mizrahi wrote:
> If miner's income margin are less than 50% (which is a healthy situation
> when mining hardware is readily available), we might experience
> catastrophic loss of hashpower (and, more importantly, catastrophic loss of
> security) after reward halving.


For the sake of argument, lets assume that somehow (quite unlikely) half the 
mining equipment gets shut off.
The amount of hashes/second is such that it is currently, lets just say, quite 
secure against any takeover.

Your document makes a long series of assumptions about how this can turn out 
bad with each individually is implausible, together are just fiction.

Your research didn't convince me about this being bad somehow. It also 
completely disregards the equilibriums reached by doing so.



^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [Bitcoin-development] death by halving
  2014-10-25 20:27 ` [Bitcoin-development] " Adam Back
@ 2014-10-25 20:43   ` Thomas Zander
  0 siblings, 0 replies; 29+ messages in thread
From: Thomas Zander @ 2014-10-25 20:43 UTC (permalink / raw)
  To: bitcoin-development

On Saturday 25. October 2014 13.27.30 Adam Back wrote:
> - alternatively you might say why not 1/100th reward reduction per 2
> week period rather than 1/2 every 4 years, a difficulty retarget could
> be a convenient point to do that.

mining equipment has a much shorter lifetime than 4 years, so the halving 
makes it easy to base purchases on.
Also, divide by two is the cleanest way to get to zero after a specific amount 
of divisions.



^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [Bitcoin-development] death by halving
  2014-10-25 20:28 ` Thomas Zander
@ 2014-10-25 20:49   ` Alex Mizrahi
  2014-10-25 21:51     ` Alexander Leishman
  0 siblings, 1 reply; 29+ messages in thread
From: Alex Mizrahi @ 2014-10-25 20:49 UTC (permalink / raw)
  To: Bitcoin Dev

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

> For the sake of argument, lets assume that somehow (quite unlikely)


Why is it unlikely? Do you believe that the cost of electricity cannot be
higher than expected mining revenue?
Or do you expect miners to keep mining when it costs them money?


> half the mining equipment gets shut off.
> The amount of hashes/second is such that it is currently, lets just say,
> quite
> secure against any takeover.
>

The equipment won't be simply turned off, it will be up for grabs.

Please check this web sites:

https://nicehash.com/
https://www.multipool.us/

One can use them in the same way he uses normal mining pools, and they
switch between different chains.
Say, multipool.us can switch between BTC and PPC (Peercoin).
Mining BTC will be less profitable after a halving, so a miner who is
willing to maximize his profits might use multipool to auto-switch to
something more profitable.
Which might be attack-on-Bitcoin.
E.g. if 60% of bitcoin's total hashrate is available via "multipools", one
can try to pull of a double-spending attack.


> Your document makes a long series of assumptions about how this can turn
> out
> bad with each individually is implausible, together are just fiction.
>

It sounds like you failed to grasp even basics.

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

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [Bitcoin-development] death by halving
  2014-10-25 19:53           ` Alex Mizrahi
@ 2014-10-25 21:50             ` Melvin Carvalho
  0 siblings, 0 replies; 29+ messages in thread
From: Melvin Carvalho @ 2014-10-25 21:50 UTC (permalink / raw)
  To: Alex Mizrahi; +Cc: Bitcoin Dev

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

On 25 October 2014 21:53, Alex Mizrahi <alex.mizrahi@gmail•com> wrote:

>
> We had a halving, and it was a non-event.
>> Is there some reason to believe next time will be different?
>>
>
> Yes.
>
> When the market is rapidly growing, margins can be relatively high because
> of limited amounts of capital being invested, or introduction of more
> efficient technologies.
>
> However, we should expect market to become more mature with time, and a
> mature market will result in lower margins.
> The halving can do much more damage when margins are relatively small.
>
> Besides that, there is a difference in ecosystem maturity:
>
> 1. Back in 2012, miners weren't so focused on profits, as Bitcoin was
> highly experimental: some were mining for the hell of it (it was a novelty
> thing back then), others wanted to secure the network, others did it
> because it was hard to obtain bitcoins by other means. But now miners are
> mostly profit-motivated: they buy expensive dedicated mining equipment and
> want to maximize profits. As you might know, at one point ghash.io
> reached 50% hashrate, and miners didn't care about it enough to switch to a
> different pool.
>
> 2. Back in 2012, we didn't have multipools. Multipools automatically
> switches between mining different alt-chains to maximize miners' profits.
> Miners who use multipools do not care how their hashrate is used as long as
> they profit off it.
> Particularly, check https://nicehash.com/ -- you can easily buy hashrate
> to attack a smaller alt-coin, for example.
>
> If the halving will result in a significant hashrate drop (and we did
> observe hashrate drop in 2012, although it wasn't that big), it might be
> possible to buy enough hashpower to attack Bitcoin.
>

This is a good point, imho.  Miner sophistication has increased drastically
in 2 years.  Sites like ( http://www.coinwarz.com/ ) can heavily influence
mining, 1-2 orders of magnitude on significant levels of hashing.

I think this is more prevalent with scrypt than sha256, litecoin is set to
half reward in 9 months, and it will be interesting to observe what happens
there.


>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

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

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [Bitcoin-development] death by halving
  2014-10-25 20:49   ` Alex Mizrahi
@ 2014-10-25 21:51     ` Alexander Leishman
  0 siblings, 0 replies; 29+ messages in thread
From: Alexander Leishman @ 2014-10-25 21:51 UTC (permalink / raw)
  To: Alex Mizrahi, Bitcoin Dev

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

Interesting analysis! I think there are a few important effects that aren't
being considered.

1. When the block reward is halved, inflation is halved as well. Is this
halving already priced in by the market or will it result in an upward
pressure on the price?

2. It was acknowledged that the referenced analysis did not take into
account the result of a double-spend attack on the bitcoin price. However,
the effect of a detectable double-spend attack on the Bitcoin network is
not isolated to Bitcoin markets. The price of altcoins often trend with the
price of Bitcoin, so attacking Bitcoin may reduce the profitability of
'multipool' mining. Any alt-coin market vulnerable to the malicious
hash-power would probably go into panic mode.

-Alex Leishman




On Sat Oct 25 2014 at 1:51:10 PM Alex Mizrahi <alex.mizrahi@gmail•com>
wrote:

>
>
>> For the sake of argument, lets assume that somehow (quite unlikely)
>
>
> Why is it unlikely? Do you believe that the cost of electricity cannot be
> higher than expected mining revenue?
> Or do you expect miners to keep mining when it costs them money?
>
>
>> half the mining equipment gets shut off.
>> The amount of hashes/second is such that it is currently, lets just say,
>> quite
>> secure against any takeover.
>>
>
> The equipment won't be simply turned off, it will be up for grabs.
>
> Please check this web sites:
>
> https://nicehash.com/
> https://www.multipool.us/
>
> One can use them in the same way he uses normal mining pools, and they
> switch between different chains.
> Say, multipool.us can switch between BTC and PPC (Peercoin).
> Mining BTC will be less profitable after a halving, so a miner who is
> willing to maximize his profits might use multipool to auto-switch to
> something more profitable.
> Which might be attack-on-Bitcoin.
> E.g. if 60% of bitcoin's total hashrate is available via "multipools", one
> can try to pull of a double-spending attack.
>
>
>> Your document makes a long series of assumptions about how this can turn
>> out
>> bad with each individually is implausible, together are just fiction.
>>
>
> It sounds like you failed to grasp even basics.
> ------------------------------------------------------------
> ------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

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

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [Bitcoin-development] death by halving
  2014-10-25 18:06 [Bitcoin-development] death by halving Alex Mizrahi
                   ` (2 preceding siblings ...)
  2014-10-25 20:28 ` Thomas Zander
@ 2014-10-25 22:10 ` Ross Nicoll
  2014-10-25 22:42   ` Melvin Carvalho
  3 siblings, 1 reply; 29+ messages in thread
From: Ross Nicoll @ 2014-10-25 22:10 UTC (permalink / raw)
  To: bitcoin-development

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

I'd suggest looking at how Dogecoin's mining schedule has worked out, 
for how halvings tend to actually affect the market. Part of Dogecoin's 
design was that it would halve very quickly (around every 75 days, in 
fact), so it's essentially illustrating worst case scenario.

Firstly, miners do not all move/shut down as a batch. Some will stay out 
of loyalty/apathy/optimism, so there's a jolt to hashrate when the 
rewards drop, and then a drift towards a steady-state. In most cases, 
the hardware costs vastly exceed the running costs, so while they may 
never see ROI due to the reward change, there's no benefit in stopping 
mining either.

On the other side, mining hardware update cycles are extremely 
aggressive, and newer hardware runs much faster. Further, those with 
newer hardware are likely to have the best hashrate to power ratio, and 
be less likely to turn off or rent out their hardware.

So, in theory there may be an uncomfortable period where the hashrate 
drops, but I would expect that drop to be much less than 50%, that most 
hardware that's turned off is not cost-effective to rent out, and that 
newer hardware being launched would push the hashrate back up again 
within a sensible timeframe.

Ross


On 25/10/2014 19:06, Alex Mizrahi wrote:
> # Death by halving
>
> ## Summary
>
> If miner's income margin are less than 50% (which is a healthy 
> situation when mining hardware is readily available), we might 
> experience catastrophic loss of hashpower (and, more importantly, 
> catastrophic loss of security) after reward halving.
>
> ## A simple model
>
> Let's define miner's income margin as `MIM = (R-C_e)/R`, where R is 
> the total revenue miner receives over a period of time, and C_e is the 
> cost of electricity spent on mining over the same period of time. 
> (Note that for the sake of simplicity we do not take into account 
> equipment costs, amortization and other costs mining might incur.)
>
> Also we will assume that transaction fees collected by miner are 
> negligible as compared to the subsidy.
>
> Theorem 1. If for a certain miner MIM is less than 0.5 before subsidy 
> halving and bitcoin and electricity prices stay the same, then mining 
> is no longer profitable after the halving.
>
> Indeed, suppose the revenue after the halving is R' = R/2.
>    MIM = (R-C_e)/R < 0.5
>    R/2 < C_e.
>
>    R' = R/2 < C_e.
>
> If revenue after halving R' doesn't cover electricity cost, a rational 
> miner should stop mining, as it's cheaper to acquire bitcoins from the 
> market.
>
> ~~~
>
> Under these assumptions, if the majority of miners have MIM less than 
> 0.5, Bitcoin is going to experience a significant loss of hashing power.
> But are these assumptions reasonable? We need a study a more complex 
> model which takes into account changes in bitcoin price and difficulty 
> changes over time.
> But, first, let's analyze significance of 'loss of hashpower'.
>
> ## Catastrophic loss of hashpower
>
> Bitcoin security model relies on assumption that a malicious actor 
> cannot acquire more than 50% of network's current hashpower.
> E.g. there is a table in Rosenfeld's _Analysis of Hashrate-Based 
> Double Spending_ paper which shows that as long as the malicious actor 
> controls only a small fraction of total hashpower, attacks have 
> well-define costs. But if the attacker-controlled hashrate is higher 
> than 50%, attacks become virtually costless, as the attacker receives 
> double-spending revenue on top of his mining revenue, and his risk is 
> close to zero.
>
> Note that the simple model described in the aforementioned paper 
> doesn't take into account attack's effect on the bitcoin price and the 
> price of the Bitcoin mining equipment. I hope that one day we'll see 
> more elaborate attack models, but in the meantime, we'll have to 
> resort to hand-waving.
>
> Consider a situation where almost all available hashpower is available 
> for a lease to the highest bidder on the open market. In this case 
> someone who owns sufficient capital could easily pull off an attack.
>
> But why is hashpower not available on the market? Quite likely 
> equipment owners are aware of the fact that such an attack would make 
> Bitcoin useless, and thus worthless, which would also make their 
> equipment worthless. Thus they prefer to do mining for a known mining 
> pools with good track record.
> (Although hashpower marketplaces exist: https://nicehash.com/ they 
> aren't particularly popular.)
>
> Now let's consider a situation where mining bitcoins is no longer 
> profitable and the majority of hashpower became dormant, i.e. miners 
> turned off their equipment or went to mine something else. In this 
> case equipment is already nearly worthless, so people might as well 
> lease it to the highest bidder, thus enabling aforementioned attacks.
>
> Alternatively, the attacker might buy obsolete mining equipment from 
> people who are no longer interested in mining.
>
> ## Taking into account the Bitcoin price
>
> This is largely trivial, and thus is left as an exercise for the 
> reader. Let's just note that the Bitcoin subsidy halving is an event 
> which is known to market participants in advance, and thus it 
> shouldn't result in significant changes of the Bitcoin price,
>
> ## Changes in difficulty
>
> Different mining devices have different efficiency. After the reward 
> halving mining on some of these devices becomes unprofitable, thus 
> they will drop out, which will result in a drop of mining difficulty.
>
> We can greatly simplify calculations if we sum costs and rewards 
> across all miners, thus calculating average MIM before the halving: 
> `MIM = 1 - C_e/R`.
>
> Let's consider an equilibrium break-even situation where unprofitable 
> mining devices were turned off, thus resulting in the change in 
> electricity expenditures: `C_e' = r * C_e`. and average MIM after the 
> halving `MIM' = 0`. In this case:
>
>     r * C_e = R/2
>     C_e / R = 1/2r
>     (1 - MIM) = 1/2r
>     r = 1/(2*(1-MIM))
>
> Let's evaluate this formulate for different before-halving MIM:
>
> 1. If `MIM = 0.5`, then `r = 1/(2*0.5) = 1`, that is, all miners can 
> remain mining.
> 2. If `MIM = 0.25`, then `r = 1/(2*0.75) = 0.66`, the least efficient 
> miners consuming 33% of total electricity costs will drop out.
> 3. If `MIM = 0.1`, then `r = 1/(2*0.9) = 0.55`, total electricity 
> costs drop by 45%.
>
> We can note that for the before-halving MIM>0, r is higher than 1/2, 
> thus less than half of total hashpower will drop out.
>
> The worst-case situation is when before-halving MIM is close to zero 
> and mining devices, as well as cost of electricity in different 
> places, are nearly identical, in that case approximately a half of all 
> hashpower will drop out.
>
> ## MIM estimation
>
> OK, what MIM do we expect in the long run? Is it going to be less than 
> 50% anyway?
>
> We can expect that people will keep buying mining devices as long as 
> it is profitable.
>
> Break-even condition: `R - C_e - P = 0`, where P is the price of a 
> mining device, R is the revenue it generates over its lifetime, and 
> C_e is the total cost of required electricity over its lifetime. In 
> this case, `R = C_e + P`, and thus:
>
>     MIM = 1 - C_e / (C_e + P)
>
> `f = C_e / P` is a ratio of the cost of electricity to the cost of 
> hardware, `C_e = f * P`, and thus
>
>     MIM = 1 - f * P / (f * P + P) = 1 - f / (f + 1) = 1 / (1 + f)
>
> MIM is less than 0.5 when f > 1.
>
> Computing f is somewhat challenging even for a concrete device, as 
> it's useful lifetime is unknown.
>
> Let's do some guesstimation:
>
> Spondoolies Tech's SP35 Yukon unit consumes 3.5 KW and costs $4000. If 
> it's useful lifetime is more than 2 years and a cost of KWh is $0.1, 
> the total expenditures on electricity will be at least $6135, thus for 
> this device we have `f > 6135/4000 > 1.5`.
>
> If other devices which will be sold on the market will have similar 
> specs, we will have MIM lower than 0.5. (Well, no shit.)
>
> ## Conclusions
>
> Reward halving is a deficiency in Bitcoin's design, but there is some 
> hope it won't be critical: in the equilibrium break-even situation 
> hashpower drop is less than 50%.
> Hashrate might drop by more than 50% immediately after the halving 
> (and before difficulty is updated), thus a combination of the halving 
> and slow difficulty update pose a real threat.
>
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [Bitcoin-development] death by halving
  2014-10-25 22:10 ` Ross Nicoll
@ 2014-10-25 22:42   ` Melvin Carvalho
  0 siblings, 0 replies; 29+ messages in thread
From: Melvin Carvalho @ 2014-10-25 22:42 UTC (permalink / raw)
  To: Ross Nicoll; +Cc: Bitcoin Dev

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

On 26 October 2014 00:10, Ross Nicoll <jrn@jrn•me.uk> wrote:

>  I'd suggest looking at how Dogecoin's mining schedule has worked out, for
> how halvings tend to actually affect the market. Part of Dogecoin's design
> was that it would halve very quickly (around every 75 days, in fact), so
> it's essentially illustrating worst case scenario.
>

Yes that is an interesting data point, but it's really hard to find
comparables to doge, and most of its hashing is now merge mined with
litecoin.  Comparing doge to btc may be a case of apples and oranges.

>
>
> Firstly, miners do not all move/shut down as a batch. Some will stay out
> of loyalty/apathy/optimism, so there's a jolt to hashrate when the rewards
> drop, and then a drift towards a steady-state. In most cases, the hardware
> costs vastly exceed the running costs, so while they may never see ROI due
> to the reward change, there's no benefit in stopping mining either.
>
> On the other side, mining hardware update cycles are extremely aggressive,
> and newer hardware runs much faster. Further, those with newer hardware are
> likely to have the best hashrate to power ratio, and be less likely to turn
> off or rent out their hardware.
>
> So, in theory there may be an uncomfortable period where the hashrate
> drops, but I would expect that drop to be much less than 50%, that most
> hardware that's turned off is not cost-effective to rent out, and that
> newer hardware being launched would push the hashrate back up again within
> a sensible timeframe.
>
> Ross
>
>
>
> On 25/10/2014 19:06, Alex Mizrahi wrote:
>
>  # Death by halving
>
>  ## Summary
>
>  If miner's income margin are less than 50% (which is a healthy situation
> when mining hardware is readily available), we might experience
> catastrophic loss of hashpower (and, more importantly, catastrophic loss of
> security) after reward halving.
>
>  ## A simple model
>
>  Let's define miner's income margin as `MIM = (R-C_e)/R`, where R is the
> total revenue miner receives over a period of time, and C_e is the cost of
> electricity spent on mining over the same period of time. (Note that for
> the sake of simplicity we do not take into account equipment costs,
> amortization and other costs mining might incur.)
>
>  Also we will assume that transaction fees collected by miner are
> negligible as compared to the subsidy.
>
>  Theorem 1. If for a certain miner MIM is less than 0.5 before subsidy
> halving and bitcoin and electricity prices stay the same, then mining is no
> longer profitable after the halving.
>
>  Indeed, suppose the revenue after the halving is R' = R/2.
>    MIM = (R-C_e)/R < 0.5
>    R/2 < C_e.
>
>     R' = R/2 < C_e.
>
>  If revenue after halving R' doesn't cover electricity cost, a rational
> miner should stop mining, as it's cheaper to acquire bitcoins from the
> market.
>
>  ~~~
>
>  Under these assumptions, if the majority of miners have MIM less than
> 0.5, Bitcoin is going to experience a significant loss of hashing power.
> But are these assumptions reasonable? We need a study a more complex model
> which takes into account changes in bitcoin price and difficulty changes
> over time.
> But, first, let's analyze significance of 'loss of hashpower'.
>
>  ## Catastrophic loss of hashpower
>
>  Bitcoin security model relies on assumption that a malicious actor
> cannot acquire more than 50% of network's current hashpower.
> E.g. there is a table in Rosenfeld's _Analysis of Hashrate-Based Double
> Spending_ paper which shows that as long as the malicious actor controls
> only a small fraction of total hashpower, attacks have well-define costs.
> But if the attacker-controlled hashrate is higher than 50%, attacks become
> virtually costless, as the attacker receives double-spending revenue on top
> of his mining revenue, and his risk is close to zero.
>
>  Note that the simple model described in the aforementioned paper doesn't
> take into account attack's effect on the bitcoin price and the price of the
> Bitcoin mining equipment. I hope that one day we'll see more elaborate
> attack models, but in the meantime, we'll have to resort to hand-waving.
>
>  Consider a situation where almost all available hashpower is available
> for a lease to the highest bidder on the open market. In this case someone
> who owns sufficient capital could easily pull off an attack.
>
>  But why is hashpower not available on the market? Quite likely equipment
> owners are aware of the fact that such an attack would make Bitcoin
> useless, and thus worthless, which would also make their equipment
> worthless. Thus they prefer to do mining for a known mining pools with good
> track record.
> (Although hashpower marketplaces exist: https://nicehash.com/ they aren't
> particularly popular.)
>
>  Now let's consider a situation where mining bitcoins is no longer
> profitable and the majority of hashpower became dormant, i.e. miners turned
> off their equipment or went to mine something else. In this case equipment
> is already nearly worthless, so people might as well lease it to the
> highest bidder, thus enabling aforementioned attacks.
>
>  Alternatively, the attacker might buy obsolete mining equipment from
> people who are no longer interested in mining.
>
>  ## Taking into account the Bitcoin price
>
>  This is largely trivial, and thus is left as an exercise for the reader.
> Let's just note that the Bitcoin subsidy halving is an event which is known
> to market participants in advance, and thus it shouldn't result in
> significant changes of the Bitcoin price,
>
>  ## Changes in difficulty
>
>  Different mining devices have different efficiency. After the reward
> halving mining on some of these devices becomes unprofitable, thus they
> will drop out, which will result in a drop of mining difficulty.
>
>  We can greatly simplify calculations if we sum costs and rewards across
> all miners, thus calculating average MIM before the halving: `MIM = 1 -
> C_e/R`.
>
>  Let's consider an equilibrium break-even situation where unprofitable
> mining devices were turned off, thus resulting in the change in electricity
> expenditures: `C_e' = r * C_e`. and average MIM after the halving `MIM' =
> 0`. In this case:
>
>      r * C_e = R/2
>     C_e / R = 1/2r
>     (1 - MIM) = 1/2r
>     r = 1/(2*(1-MIM))
>
>  Let's evaluate this formulate for different before-halving MIM:
>
>  1. If `MIM = 0.5`, then `r = 1/(2*0.5) = 1`, that is, all miners can
> remain mining.
> 2. If `MIM = 0.25`, then `r = 1/(2*0.75) = 0.66`, the least efficient
> miners consuming 33% of total electricity costs will drop out.
> 3. If `MIM = 0.1`, then `r = 1/(2*0.9) = 0.55`, total electricity costs
> drop by 45%.
>
>  We can note that for the before-halving MIM>0, r is higher than 1/2,
> thus less than half of total hashpower will drop out.
>
>  The worst-case situation is when before-halving MIM is close to zero and
> mining devices, as well as cost of electricity in different places, are
> nearly identical, in that case approximately a half of all hashpower will
> drop out.
>
>  ## MIM estimation
>
>  OK, what MIM do we expect in the long run? Is it going to be less than
> 50% anyway?
>
>  We can expect that people will keep buying mining devices as long as it
> is profitable.
>
>  Break-even condition: `R - C_e - P = 0`, where P is the price of a
> mining device, R is the revenue it generates over its lifetime, and C_e is
> the total cost of required electricity over its lifetime. In this case, `R
> = C_e + P`, and thus:
>
>      MIM = 1 - C_e / (C_e + P)
>
>  `f = C_e / P` is a ratio of the cost of electricity to the cost of
> hardware, `C_e = f * P`, and thus
>
>      MIM = 1 - f * P / (f * P + P) = 1 - f / (f + 1) = 1 / (1 + f)
>
>  MIM is less than 0.5 when f > 1.
>
>  Computing f is somewhat challenging even for a concrete device, as it's
> useful lifetime is unknown.
>
>  Let's do some guesstimation:
>
>  Spondoolies Tech's SP35 Yukon unit consumes 3.5 KW and costs $4000. If
> it's useful lifetime is more than 2 years and a cost of KWh is $0.1, the
> total expenditures on electricity will be at least $6135, thus for this
> device we have `f > 6135/4000 > 1.5`.
>
>  If other devices which will be sold on the market will have similar
> specs, we will have MIM lower than 0.5. (Well, no shit.)
>
>  ## Conclusions
>
>  Reward halving is a deficiency in Bitcoin's design, but there is some
> hope it won't be critical: in the equilibrium break-even situation
> hashpower drop is less than 50%.
> Hashrate might drop by more than 50% immediately after the halving (and
> before difficulty is updated), thus a combination of the halving and slow
> difficulty update pose a real threat.
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Bitcoin-development mailing listBitcoin-development@lists•sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

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

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [Bitcoin-development] death by halving
  2014-10-25 19:16         ` Gavin Andresen
  2014-10-25 19:53           ` Alex Mizrahi
@ 2014-10-28 20:17           ` Ferdinando M. Ametrano
       [not found]             ` <CAAS2fgSiz-XRVQ4V+KbrTUWG4=g=WGf8c-pF4b4fFnfyU9HOqQ@mail.gmail.com>
  1 sibling, 1 reply; 29+ messages in thread
From: Ferdinando M. Ametrano @ 2014-10-28 20:17 UTC (permalink / raw)
  To: Gavin Andresen; +Cc: MANDELLI FRANCESCO, MAZZOCCHI PAOLO, Bitcoin Dev


[-- Attachment #1.1: Type: text/plain, Size: 1304 bytes --]

On Oct 25, 2014 9:19 PM, "Gavin Andresen" <gavinandresen@gmail•com> wrote:
> We had a halving, and it was a non-event.
> Is there some reason to believe next time will be different?

In november 2008 bitcoin was a much younger ecosystem, with less liquidity
and trading, smaller market cap, and the halving happened during a quite
stable positive price trend.

In the next months competition might easily drive down mining margins, and
the reward halving might generate unexpected disruption in mining
operations.

Moreover, halving is not strictly necessary to respect the spirit of
Nakamoto's monetary rule and its 21M limit. At the beginning of the 3rd
reward era (block 420000, in 2017) a new reward function could become
effective R(b)=k*2^(-h*b/210000) where b is the block number and R(b) is
the reward. The parameters h and k can be calibrated so that R(419999)=25
and sum_b{R}=21M


​If the increased issuance speed in the third era is considered
problematic, then each era could have its own R_e(b)=k_e*2^(-h_e*b/210000)
fitted to the amount of coins to be issued in that era according to the
current supply rule, e.g. fitting k_e and h_e to R(419999)=25 and
sum_{b}_e=2,625,000.

Would such a BIP have any chance to be considered? Am I missing something?

Nando

[-- Attachment #1.2: Type: text/html, Size: 1536 bytes --]

[-- Attachment #2: btc-blkzoomed (1).png --]
[-- Type: image/png, Size: 18254 bytes --]

^ permalink raw reply	[flat|nested] 29+ messages in thread

* [Bitcoin-development] Fwd:  death by halving
       [not found]             ` <CAAS2fgSiz-XRVQ4V+KbrTUWG4=g=WGf8c-pF4b4fFnfyU9HOqQ@mail.gmail.com>
@ 2014-10-28 20:36               ` Gregory Maxwell
  2014-10-28 20:57                 ` Alex Mizrahi
  2014-10-28 21:23                 ` [Bitcoin-development] Fwd: death by halving Ferdinando M. Ametrano
  0 siblings, 2 replies; 29+ messages in thread
From: Gregory Maxwell @ 2014-10-28 20:36 UTC (permalink / raw)
  To: Bitcoin Development

On Tue, Oct 28, 2014 at 8:17 PM, Ferdinando M. Ametrano
<ferdinando.ametrano@gmail•com> wrote:
>
> On Oct 25, 2014 9:19 PM, "Gavin Andresen" <gavinandresen@gmail•com> wrote:
> > We had a halving, and it was a non-event.
> > Is there some reason to believe next time will be different?
>
> In november 2008 bitcoin was a much younger ecosystem,

Or very old, indeed, if you are using unsigned arithmetic. [...]

> and the halving happened during a quite stable positive price trend

Hardly,

http://bitcoincharts.com/charts/mtgoxUSD#rg60zczsg2012-10-01zeg2012-12-01ztgSzm1g10zm2g25zv

> Moreover, halving is not strictly necessary to respect the spirit of Nakamoto's monetary rule

It isn't, but many people have performed planning around the current
behaviour. The current behaviour has also not shown itself to be
problematic (and we've actually experienced its largest effect already
without incident), and there are arguable benefits like encouraging
investment in mining infrastructure.

This thread is, in my opinion, a waste of time.  It's yet again
another perennial bikeshedding proposal brought up many times since at
least 2011, suggesting random changes for
non-existing(/not-yet-existing) issues.

There is a lot more complexity to the system than the subsidy schedule.



^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [Bitcoin-development] Fwd: death by halving
  2014-10-28 20:36               ` [Bitcoin-development] Fwd: " Gregory Maxwell
@ 2014-10-28 20:57                 ` Alex Mizrahi
  2014-10-28 21:19                   ` Jérémie Dubois-Lacoste
  2014-10-28 21:23                 ` [Bitcoin-development] Fwd: death by halving Ferdinando M. Ametrano
  1 sibling, 1 reply; 29+ messages in thread
From: Alex Mizrahi @ 2014-10-28 20:57 UTC (permalink / raw)
  To: Gregory Maxwell; +Cc: Bitcoin Development

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

> This thread is, in my opinion, a waste of time.  It's yet again
> another perennial bikeshedding proposal brought up many times since at
> least 2011, suggesting random changes for
> non-existing(/not-yet-existing) issues.
>
> There is a lot more complexity to the system than the subsidy schedule.
>

Well, the main question is what makes Bitcoin secure.
It is secured by proofs of work which are produced by miners.
Miners have economic incentives to play by the rules; in simple terms, that
is more profitable than performing attacks.

So the question is, why and when it works? It would be nice to know the
boundaries, no?

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

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [Bitcoin-development] Fwd: death by halving
  2014-10-28 20:57                 ` Alex Mizrahi
@ 2014-10-28 21:19                   ` Jérémie Dubois-Lacoste
  2014-10-28 21:43                     ` Gregory Maxwell
  0 siblings, 1 reply; 29+ messages in thread
From: Jérémie Dubois-Lacoste @ 2014-10-28 21:19 UTC (permalink / raw)
  Cc: Bitcoin Development

Answering today's concerns with yesterday's facts is dangerous,
especially with bitcoin on a 4 years period. I personally consider all
arguments like "we went through once, and nothing special. So no
disturbance worthy of discussion to expect" baseless.
Also, starting a topic with mentions of "death" is not leading to any
useful discussion.

@Topic starters: don't oversell your topic with that kind of
vocabulary hype. "death by halving", seriously?
@Everybody else: don't focus on the chosen vocabulary, or use it to
discard what might be a relevant discussion topic.

The fact that a topic was brought up many times since a long time,
does not mean it is not relevant. It only means it is a recurring
concern. I read no convincing argument against a significant
disturbance of the mining market to come. The fact that it is known in
advance is no counter argument to me.
Environmental conditions will have changed so much, the next halving
occurence might have nothing to do with the previous one, and it
should be perfectly ok to discuss it instead of putting the whole
thing under the carpet.

What is most important to the discussion to me: the main difference
between the last halving and the one to come is the relative weight of
ideology vs. rationality in miners's motivations. Effectively putting
us closer to the original bitcoin premises (miners fully rational).
Miners were close to being 100% individuals last halving, they are now
largely for-profit companies. This isn't a change we can overlook with
pure maths or with previous experience.


Jeremie DL





2014-10-28 21:36 GMT+01:00 Gregory Maxwell <gmaxwell@gmail•com>:
> On Tue, Oct 28, 2014 at 8:17 PM, Ferdinando M. Ametrano
> <ferdinando.ametrano@gmail•com> wrote:
>>
>> On Oct 25, 2014 9:19 PM, "Gavin Andresen" <gavinandresen@gmail•com> wrote:
>> > We had a halving, and it was a non-event.
>> > Is there some reason to believe next time will be different?
>>
>> In november 2008 bitcoin was a much younger ecosystem,
>
> Or very old, indeed, if you are using unsigned arithmetic. [...]
>
>> and the halving happened during a quite stable positive price trend
>
> Hardly,
>
> http://bitcoincharts.com/charts/mtgoxUSD#rg60zczsg2012-10-01zeg2012-12-01ztgSzm1g10zm2g25zv
>
>> Moreover, halving is not strictly necessary to respect the spirit of Nakamoto's monetary rule
>
> It isn't, but many people have performed planning around the current
> behaviour. The current behaviour has also not shown itself to be
> problematic (and we've actually experienced its largest effect already
> without incident), and there are arguable benefits like encouraging
> investment in mining infrastructure.
>
> This thread is, in my opinion, a waste of time.  It's yet again
> another perennial bikeshedding proposal brought up many times since at
> least 2011, suggesting random changes for
> non-existing(/not-yet-existing) issues.
>
> There is a lot more complexity to the system than the subsidy schedule.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2014-10-28 21:57 GMT+01:00 Alex Mizrahi <alex.mizrahi@gmail•com>:
>
>>
>> This thread is, in my opinion, a waste of time.  It's yet again
>> another perennial bikeshedding proposal brought up many times since at
>> least 2011, suggesting random changes for
>> non-existing(/not-yet-existing) issues.
>>
>> There is a lot more complexity to the system than the subsidy schedule.
>
>
> Well, the main question is what makes Bitcoin secure.
> It is secured by proofs of work which are produced by miners.
> Miners have economic incentives to play by the rules; in simple terms, that
> is more profitable than performing attacks.
>
> So the question is, why and when it works? It would be nice to know the
> boundaries, no?
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>



^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [Bitcoin-development] Fwd: death by halving
  2014-10-28 20:36               ` [Bitcoin-development] Fwd: " Gregory Maxwell
  2014-10-28 20:57                 ` Alex Mizrahi
@ 2014-10-28 21:23                 ` Ferdinando M. Ametrano
  2014-10-28 21:34                   ` Neil
  1 sibling, 1 reply; 29+ messages in thread
From: Ferdinando M. Ametrano @ 2014-10-28 21:23 UTC (permalink / raw)
  To: Gregory Maxwell; +Cc: Bitcoin Development

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

> > In november 2008 bitcoin was a much younger ecosystem,
>
> Or very old, indeed, if you are using unsigned arithmetic. [...]
>
:-) I meant 2012, of course, but loved your wit


> > and the halving happened during a quite stable positive price trend
>
> Hardly,
>
>
> http://bitcoincharts.com/charts/mtgoxUSD#rg60zczsg2012-10-01zeg2012-12-01ztgSzm1g10zm2g25zv


indeed!
http://bitcoincharts.com/charts/mtgoxUSD#rg60zczsg2012-08-01zeg2013-02-01ztgSzm1g10zm2g25zv


> There is a lot more complexity to the system than the subsidy schedule.
>
who said the contrary?

This thread is, in my opinion, a waste of time.
>
it might be, I have some free time right now...

many people have performed planning around the current
> behaviour. The current behaviour has also not shown itself to be
> problematic (and we've actually experienced its largest effect already
> without incident), and there are arguable benefits like encouraging
> investment in mining infrastructure.
>

I would love a proper rebuttal of a basic economic argument. If increased
competition will push mining revenues below 200% of operational costs, then
the halving will suddenly switch off many non profitable mining resources.
As of now the cost per block is probably already about 100USD, probably in
the 50-150USD.
Dismissed mining resources might even become cheaply available for
malevolent agents considering a 51% attack. Moreover the timing would be
perfect for the burst of any existing cloud hashing Ponzi scheme.
From a strict economic point of view allowing the halving jump is looking
for trouble. To each his own.

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

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [Bitcoin-development] Fwd: death by halving
  2014-10-28 21:23                 ` [Bitcoin-development] Fwd: death by halving Ferdinando M. Ametrano
@ 2014-10-28 21:34                   ` Neil
  2014-10-28 21:44                     ` Ferdinando M. Ametrano
  2014-10-28 21:57                     ` Christophe Biocca
  0 siblings, 2 replies; 29+ messages in thread
From: Neil @ 2014-10-28 21:34 UTC (permalink / raw)
  To: Ferdinando M. Ametrano; +Cc: Bitcoin Development

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

Economically a halving is almost the same as a halving in price (as fees
take up more of the pie, less so).

Coincidentally the price has halved since early July to mid-October, and
we've not even seen difficulty fall yet.

I don't think there's much to see here.

Neil

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

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [Bitcoin-development] Fwd: death by halving
  2014-10-28 21:19                   ` Jérémie Dubois-Lacoste
@ 2014-10-28 21:43                     ` Gregory Maxwell
  2014-10-28 22:43                       ` Ferdinando M. Ametrano
  0 siblings, 1 reply; 29+ messages in thread
From: Gregory Maxwell @ 2014-10-28 21:43 UTC (permalink / raw)
  To: Jérémie Dubois-Lacoste; +Cc: Bitcoin Development

On Tue, Oct 28, 2014 at 9:19 PM, Jérémie Dubois-Lacoste
<jeremie.dl@gmail•com> wrote:
> The fact that a topic was brought up many times since a long time,
> does not mean it is not relevant.

I am not saying that it is "not relevant", I'm saying the discussion
is pointless:

No new information has arrived since the very first times that this
has been discussed except
that the first halving passed without incident.
If people were not sufficiently convinced that this was a serious
concern before there was concrete evidence (however small) that it was
okay, then discussion is not likely going to turn out differently the
50th or 100th time it is repeated...
except, perhaps, by wearing out all the most experienced and
knowledgeable among us as we become tired of rehashing the same
discussions over and over again.

On Tue, Oct 28, 2014 at 9:23 PM, Ferdinando M. Ametrano
<ferdinando.ametrano@gmail•com> wrote:
[snip]
> As of now the cost per block is probably already about 100USD, probably in
> the 50-150USD.

This is wildly at odds with reality. I don't mean to insult, but
please understand that every post you make here consumes the time of
dozens (or, hopefully, hundreds) of people. Every minute you spend
refining your post has a potential return of many minutes for the rest
of the users of the list.

At current difficulty, with a SP30 (one of the
leading-in-power-efficiency) marginal break-even is ~1144.8852 * $/kwh
== $/btc.

At $0.10/kwh each block has an expected cost right now, discounting
all one time hardware costs, close to $3000.



^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [Bitcoin-development] Fwd: death by halving
  2014-10-28 21:34                   ` Neil
@ 2014-10-28 21:44                     ` Ferdinando M. Ametrano
  2014-10-28 22:00                       ` Thomas Zander
  2014-10-28 21:57                     ` Christophe Biocca
  1 sibling, 1 reply; 29+ messages in thread
From: Ferdinando M. Ametrano @ 2014-10-28 21:44 UTC (permalink / raw)
  To: Neil; +Cc: Bitcoin Development

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

On Tue, Oct 28, 2014 at 10:34 PM, Neil <kyuupichan@gmail•com> wrote:

> Economically a halving is almost the same as a halving in price (as fees
> take up more of the pie, less so).
>
> Coincidentally the price has halved since early July to mid-October, and
> we've not even seen difficulty fall yet.
>
because mining profits are many times operational costs. This might change
because of competition, in that case halving in price will become
problematic.

It amazes me that basic economic considerations seems completely lost here,
especially when it comes to mining. We should have learned the lesson of
how a small error in the incentive structure has lead from "one CPU, one
vote" to an oligopoly which might easily become a monopoly in the near
future.

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

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [Bitcoin-development] Fwd: death by halving
  2014-10-28 21:34                   ` Neil
  2014-10-28 21:44                     ` Ferdinando M. Ametrano
@ 2014-10-28 21:57                     ` Christophe Biocca
  1 sibling, 0 replies; 29+ messages in thread
From: Christophe Biocca @ 2014-10-28 21:57 UTC (permalink / raw)
  To: Neil; +Cc: Bitcoin Development

> The fact that it is known in advance is no counter argument to me.

But it does change miner behaviour in pretty significant ways.

Unlike difficulty forecasting, which seems near impossible to do
accurately, miners can plan to purchase less hardware as they approach
the revenue drop. You can do some basic cost/benefit calculation and
see that *if* margins are already low as the halving approaches, then
rational miners would cease purchasing any new hardware that wouldn't
be profitable past that point, unless they expect it to pay for itself
by then.

The lower the margins are, the longer in advance they would alter
their buying behaviour. You'd see an increased focus on cost-effective
hashpower (and older units would not be replaced as they break).
Either a significant supply of cost effective hardware shows up
(because it's the only thing that would sell in the last months), or
difficulty would stall long before the halving happens. Either way,
the predictability of the halving can reduce the hashpower on the day.

On Tue, Oct 28, 2014 at 5:34 PM, Neil <kyuupichan@gmail•com> wrote:
> Economically a halving is almost the same as a halving in price (as fees
> take up more of the pie, less so).
>
> Coincidentally the price has halved since early July to mid-October, and
> we've not even seen difficulty fall yet.
>
> I don't think there's much to see here.
>
> Neil
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>



^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [Bitcoin-development] Fwd: death by halving
  2014-10-28 21:44                     ` Ferdinando M. Ametrano
@ 2014-10-28 22:00                       ` Thomas Zander
  2014-10-28 22:38                         ` Ferdinando M. Ametrano
  0 siblings, 1 reply; 29+ messages in thread
From: Thomas Zander @ 2014-10-28 22:00 UTC (permalink / raw)
  To: bitcoin-development

On Tuesday 28. October 2014 22.44.50 Ferdinando M. Ametrano wrote:
> It amazes me that basic economic considerations seems completely lost here,
> especially when it comes to mining.

Please don't confuse people dismissing your thoughts with dismissing the basic 
economic considerations. The fact of the matter is that you didn't read the 
archives where these ideas have been brought forward and discussed, a 
consensus was reached. (it wasn't so basic afterall)

The fact that people don't want to repeat the discussion just for your sake is 
not the same as people not listening to those arguments.





^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [Bitcoin-development] Fwd: death by halving
  2014-10-28 22:00                       ` Thomas Zander
@ 2014-10-28 22:38                         ` Ferdinando M. Ametrano
  0 siblings, 0 replies; 29+ messages in thread
From: Ferdinando M. Ametrano @ 2014-10-28 22:38 UTC (permalink / raw)
  To: Thomas Zander; +Cc: Bitcoin Dev

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

On Tue, Oct 28, 2014 at 11:00 PM, Thomas Zander <thomas@thomaszander•se>
wrote:

> you didn't read the
> archives where these ideas have been brought forward and discussed, a
> consensus was reached. (it wasn't so basic afterall)
> The fact that people don't want to repeat the discussion just for your
> sake is
> not the same as people not listening to those arguments.


I didn't start the thread and so didn't research the archive. Until two
posts ago there was no reference about the issue being discussed before. A
link would have been much kinder than harsh dismissal. I will research and
read.

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

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [Bitcoin-development] Fwd: death by halving
  2014-10-28 21:43                     ` Gregory Maxwell
@ 2014-10-28 22:43                       ` Ferdinando M. Ametrano
  2014-10-29 14:34                         ` [Bitcoin-development] Death by halving (pro-active proposals) Sergio Lerner
  0 siblings, 1 reply; 29+ messages in thread
From: Ferdinando M. Ametrano @ 2014-10-28 22:43 UTC (permalink / raw)
  To: Gregory Maxwell; +Cc: Bitcoin Development

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

On Tue, Oct 28, 2014 at 10:43 PM, Gregory Maxwell <gmaxwell@gmail•com>
wrote:

> > As of now the cost per block is probably already about 100USD, probably
> in
> > the 50-150USD.
>
> This is wildly at odds with reality. I don't mean to insult, but
> please understand that every post you make here consumes the time of
> dozens (or, hopefully, hundreds) of people. Every minute you spend
> refining your post has a potential return of many minutes for the rest
> of the users of the list.
>
> At current difficulty, with a SP30 (one of the
> leading-in-power-efficiency) marginal break-even is ~1144.8852 * $/kwh
> == $/btc.
>
> At $0.10/kwh each block has an expected cost right now, discounting
> all one time hardware costs, close to $3000.
>

yes, you're right I meant about $100USD per BTC, i.e. $2500 per block.
Because of my mistake I'll shut up and go back researching the archive on
this issue.

Thank you for the kind summary of the many good reasons why halving is a
non-issue. Very much appreciated, especially considering how precious is
your time.

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

^ permalink raw reply	[flat|nested] 29+ messages in thread

* [Bitcoin-development] Death by halving (pro-active proposals)
  2014-10-28 22:43                       ` Ferdinando M. Ametrano
@ 2014-10-29 14:34                         ` Sergio Lerner
  2014-10-29 17:25                           ` Jeff Garzik
  0 siblings, 1 reply; 29+ messages in thread
From: Sergio Lerner @ 2014-10-29 14:34 UTC (permalink / raw)
  To: bitcoin-development

Instead of discussing what will happen when the subsidy is halved (which
nobody really knows) maybe we can think about of what we can do to
mitigate any damage in case something unwanted happens. Let's be proactive.

For instance, any form of merged-mining (like higher frequency
side-chains) will end-up increasing miners profit, even by a small
margin. Then that margin can compensate miners not to turn off their
equipment. Then we can encourage merge-mining on SHA-256, instead of
discouraging SHA-256 alt-coins.

Also we can encourage mining during the "trouble" period by creating a
donation pool: suppose we manage to convince miners to donate 1% of
their revenue in order to pay back to the miners for the first month
after the reward halving. If every block pays 1% for 10 months, then
every block during the first month of halving will earn 20% more.  Of
course, convincing miners of this may be difficult, but not impossible.
It could be done automatically with nLockTime freeze of transactions
with high fees, so no TTP is necessary.

So here are two proposals, any other idea?

Best regards,
 Sergio.





^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [Bitcoin-development] Death by halving (pro-active proposals)
  2014-10-29 14:34                         ` [Bitcoin-development] Death by halving (pro-active proposals) Sergio Lerner
@ 2014-10-29 17:25                           ` Jeff Garzik
  0 siblings, 0 replies; 29+ messages in thread
From: Jeff Garzik @ 2014-10-29 17:25 UTC (permalink / raw)
  To: Sergio Lerner; +Cc: Bitcoin Dev

Seconded - IMO a key future use of the chain will be securing other
chains.  I'm interested in pursuing the merged-mining angle.

Getting chain hashes to a miner, and getting that miner payment from
the chain, is key to this.  Consider a future where there are 10,000
chains secured by one block...


On Wed, Oct 29, 2014 at 10:34 AM, Sergio Lerner
<sergiolerner@certimix•com> wrote:
> Instead of discussing what will happen when the subsidy is halved (which
> nobody really knows) maybe we can think about of what we can do to
> mitigate any damage in case something unwanted happens. Let's be proactive.
>
> For instance, any form of merged-mining (like higher frequency
> side-chains) will end-up increasing miners profit, even by a small
> margin. Then that margin can compensate miners not to turn off their
> equipment. Then we can encourage merge-mining on SHA-256, instead of
> discouraging SHA-256 alt-coins.
>
> Also we can encourage mining during the "trouble" period by creating a
> donation pool: suppose we manage to convince miners to donate 1% of
> their revenue in order to pay back to the miners for the first month
> after the reward halving. If every block pays 1% for 10 months, then
> every block during the first month of halving will earn 20% more.  Of
> course, convincing miners of this may be difficult, but not impossible.
> It could be done automatically with nLockTime freeze of transactions
> with high fees, so no TTP is necessary.
>
> So here are two proposals, any other idea?
>
> Best regards,
>  Sergio.
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/



^ permalink raw reply	[flat|nested] 29+ messages in thread

end of thread, other threads:[~2014-10-29 17:25 UTC | newest]

Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-10-25 18:06 [Bitcoin-development] death by halving Alex Mizrahi
2014-10-25 18:12 ` Jeff Garzik
2014-10-25 18:22   ` Alex Mizrahi
2014-10-25 18:31     ` Jeff Garzik
2014-10-25 19:08       ` Alex Mizrahi
2014-10-25 19:16         ` Gavin Andresen
2014-10-25 19:53           ` Alex Mizrahi
2014-10-25 21:50             ` Melvin Carvalho
2014-10-28 20:17           ` Ferdinando M. Ametrano
     [not found]             ` <CAAS2fgSiz-XRVQ4V+KbrTUWG4=g=WGf8c-pF4b4fFnfyU9HOqQ@mail.gmail.com>
2014-10-28 20:36               ` [Bitcoin-development] Fwd: " Gregory Maxwell
2014-10-28 20:57                 ` Alex Mizrahi
2014-10-28 21:19                   ` Jérémie Dubois-Lacoste
2014-10-28 21:43                     ` Gregory Maxwell
2014-10-28 22:43                       ` Ferdinando M. Ametrano
2014-10-29 14:34                         ` [Bitcoin-development] Death by halving (pro-active proposals) Sergio Lerner
2014-10-29 17:25                           ` Jeff Garzik
2014-10-28 21:23                 ` [Bitcoin-development] Fwd: death by halving Ferdinando M. Ametrano
2014-10-28 21:34                   ` Neil
2014-10-28 21:44                     ` Ferdinando M. Ametrano
2014-10-28 22:00                       ` Thomas Zander
2014-10-28 22:38                         ` Ferdinando M. Ametrano
2014-10-28 21:57                     ` Christophe Biocca
2014-10-25 20:27 ` [Bitcoin-development] " Adam Back
2014-10-25 20:43   ` Thomas Zander
2014-10-25 20:28 ` Thomas Zander
2014-10-25 20:49   ` Alex Mizrahi
2014-10-25 21:51     ` Alexander Leishman
2014-10-25 22:10 ` Ross Nicoll
2014-10-25 22:42   ` Melvin Carvalho

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox