Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm

[Peter Todd via bitcoin-dev]

On Wed, Mar 02, 2016 at 11:01:36AM -0800, Eric Voskuil via bitcoin-dev wrote:
> > A 6 month investment with 3 months on the high subsidy and 3 months on low 
> > subsidy would not be made…
> 
>  
> 
> Yes, this is the essential point. All capital investments are made based on 
> expectations of future returns. To the extent that futures are perfectly 
> knowable, they can be perfectly factored in. This is why inflation in Bitcoin 
> is not a tax, it’s a cost. These step functions are made continuous by their 
> predictability, removing that predictability will make them -- unpredictable.

You know, I do agree with you.

But see, this is one of the reasons why we keep reminding people that
strictly speaking a hardfork *is* an altcoin, and the altcoin can change
any rule currently in Bitcoin.

It'd be perfectly reasonable to create an altcoin with a 22-million-coin
limit and an inflation schedule that had smooth, rather than abrupt,
drops. It'd also be reasonable to make that altcoin start with the same
UTXO set as Bitcoin as a means of initial coin distribution.

If miners choose to start mining that altcoin en-mass on the halving,
all the more power to them. It's our choice whether or not we buy those
coins. We may choose not to, but if 95% of the hashing power decides to
go mine something different we have to accept that under our current
chosen rules confirmations might take a long time.


Of course, personally I agree with Gregory Maxwell: this is all fairly
unlikely to happen, so the discussion is academic. But we'll see.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org
04d430e1daab776bc1c194589b0326924220faa00efc50cf


signature.asc
Description: Digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm

[Eric Voskuil via bitcoin-dev]

On 03/02/2016 12:08 PM, Paul Sztorc wrote:
> On 3/2/2016 2:01 PM, Eric Voskuil via bitcoin-dev wrote:
>>> A 6 month investment with 3 months on the high subsidy and 3 months on
>> low subsidy would not be made…
>>
>> Yes, this is the essential point. All capital investments are made based
>> on expectations of future returns. To the extent that futures are
>> perfectly knowable, they can be perfectly factored in. This is why
>> inflation in Bitcoin is not a tax, it’s a cost. These step functions are
>> made continuous by their predictability, removing that predictability
>> will make them -- unpredictable.
> 
> The Ministry of Truth is taking job applications in the doublespeak
> department...

Not sure how you interpret a tautology as doublespeak.

>> Changing these futures punishes those who have planned properly and
>> favors those who have not. Sort of like a Bitcoin bail-in; are some
>> miners are too big to fail? It also creates the expectation that it may
>> happen again. This infects the money with the sort of uncertainty that
>> Bitcoin is designed to prevent.
> 
> Coinbase-smoothing can be done via soft fork (soft forks typically only
> move "one way" toward stability).

I'm addressing the hard fork proposal (see subject line).

> Moreover, the effect *costs* miners,
> it does not benefit them. Finally, it can be done so that the economic
> impact on miners is minimized.

Changes to consensus rules change the value of coins, which are property
of their owners. Nobody owes a miner a promise of consistent revenue for
future work. Cost or benefit to miners is relevant only to the extent
that those who hold money believe it will affect their value and
therefore consider it in their decision to consent.

> You'll just have to weigh the risks -- some vague, tiny effect on
> expectations today, vs the need for a small group of experts to
> emergency hard fork once every four years.

How is the small group of experts today different from the small group
of experts tomorrow?

> I'm sure those experts are completely reliable, and won't get threatened
> or assassinated!

This is precisely the issue. The precedent of hard-forking to "fix" the
money is a precedent for establishing authority over the money.

>> A 6 month investment with 3 months on the high subsidy and 3 months on
>> low subsidy would not be made if it only generated a small profit for
>> the first 3 and then massive losses for the 2nd period of 3 months.  For
>> it to be made, there needs to be large profit during the first period to
>> compensate for the losses in the 2nd period.
> 
> The word "loss" is of utmost importance here...if they are operational
> losses, it should be obvious to everyone that the best "compensation for
> losses in the 2nd period" is to just shut them off (thus reducing losses
> to zero).

But of course the losses would not be entirely operational, since
hardware (at a minimum) does not depreciate to zero because of a
halving. The ability to plan does not change this fact. There are
certainly similar considerations for labor, bandwidth, space and even
electrical/cooling costs (contracts). To the extent that these costs are
sunk (as Tier said) *any* earnings are better than none.

> So you must be arguing that miners have made an investment 3 months
> prior, knowing that it would pay for itself despite the reward halving.

Of course, how could they not?

> That's nice, but it ignores the fact that, if that investment is made
> everyone, by all miners, the *difficulty* will have increased 2 weeks
> afterward...such that operating profits are tending *immediately* toward
> zero, and will be zero by the time the first set of 3 months is over.

... which also ignores fees.

e



signature.asc
Description: OpenPGP digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm

[David A. Harding via bitcoin-dev]

On Wed, Mar 02, 2016 at 05:53:46PM +, Gregory Maxwell wrote:
> What you are proposing makes sense only if it was believed that a very
> large difficulty drop would be very likely.
>
> This appears to be almost certainly untrue-- consider-- look how long
> ago since hashrate was 50% of what it is now, or 25% of what it is
> now-- this is strong evidence that supermajority of the hashrate is
> equipment with state of the art power efficiency.

To avoid duplication of looking up this statistic among readers, here
are the various recent difficulties:

$ for i in $( seq 0 2016 6 ) ; do echo -n $i blocks ago:' ' ; 
bitcoin-cli getblock $( bitcoin-cli getblockhash $(( 400857 - i )) ) | jshon -e 
difficulty ; done | column -t
0  blocks  ago:  163491654908.95929
2016   blocks  ago:  144116447847.34869
4032   blocks  ago:  120033340651.237
6048   blocks  ago:  113354299801.4711
8064   blocks  ago:  103880340815.4559
10080  blocks  ago:  93448670796.323807
12096  blocks  ago:  79102380900.225983
14112  blocks  ago:  72722780642.54718
16128  blocks  ago:  65848255179.702606
18144  blocks  ago:  62253982449.760818
20160  blocks  ago:  60883825480.098282
22176  blocks  ago:  60813224039.440353
24192  blocks  ago:  59335351233.86657
26208  blocks  ago:  56957648455.01001
28224  blocks  ago:  54256630327.889961
30240  blocks  ago:  52699842409.347008
32256  blocks  ago:  52278304845.591682
34272  blocks  ago:  51076366303.481934
36288  blocks  ago:  49402014931.227463
38304  blocks  ago:  49692386354.893837
40320  blocks  ago:  47589591153.625008
42336  blocks  ago:  48807487244.681381
44352  blocks  ago:  47643398017.803436
46368  blocks  ago:  47610564513.47126
48384  blocks  ago:  49446390688.24144
50400  blocks  ago:  46717549644.706421
52416  blocks  ago:  47427554950.6483
54432  blocks  ago:  46684376316.860291
56448  blocks  ago:  44455415962.343803
58464  blocks  ago:  41272873894.697021

<50% of current hash rate was last seen roughly six retarget periods (12
weeks) ago and <25% of current hash rate was last seen roughly 29 periods
(58 weeks) ago.

I think that's reasonably strong evidence for your thesis given that
the increases in hash rate from the introduction of new efficient
equipment are likely partly offset by the removal from the hash rate of
lower efficiency equipment, so the one-year tail of ~25% probably means
that less than 25% of operating equipment is one year old or older.

However, it is my understanding that most mining equipment can be run at
different hash rates. Is there any evidence that high-efficiency miners
today are using high clock speeds to produce more hashes per ASIC than
they will after halving?  Is there any way to guess at how many fewer
hashes they might produce?

> If a pre-programmed ramp and drop is set then it has the risk of
> massively under-setting difficulty; which is also strongly undesirable
> (e.g. advanced inflation and exacerbating existing unintentional
> selfish mining)

Maybe I'm not thinking this through thoroughly, but I don't think it's
possible to significantly advance inflation unless the effective hash
rate increases by more than 300% at the halving.  With the proposal
being replied to, if all mining equipment operation before the
halving continued operating after it, the effective increase would be
200%. That doubling in effective hash rate would've been offset in
advance through a reduction in the effective hash rate in the weeks
before the halving.

Exacerbated unintentional selfish mining is a much more significant
concern IMO, even if it's only for a short retarget period or two. This
is especially the case given the current high levels of centralization
and validationless mining on the network today, which we would not want
to reward by making those miners the only ones effectively capable of
creating blocks until difficulty adjusted. I had not thought of this
aspect; thank you for bringing it up.

> and that is before suggesting that miners voluntarily take a loss of
> inflation now.

Yes, I very much don't like that aspect, which is why I made sure to
mention it.

> So while I think this concern is generally implausible; I think it's
> prudent to have a difficulty step patch (e.g. a one time single point
> where a particular block is required to lower bits a set amount) ready
> to go in the unlikely case the network is stalled.

I think having that code ready in general is a good idea, and a one-time
change in nBits is sounds like a good and simple way to go about it.

Thank you for your insightful reply,

-Dave
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm

[Eric Voskuil via bitcoin-dev]

> A 6 month investment with 3 months on the high subsidy and 3 months on low 
> subsidy would not be made…

 

Yes, this is the essential point. All capital investments are made based on 
expectations of future returns. To the extent that futures are perfectly 
knowable, they can be perfectly factored in. This is why inflation in Bitcoin 
is not a tax, it’s a cost. These step functions are made continuous by their 
predictability, removing that predictability will make them -- unpredictable.

 

Changing these futures punishes those who have planned properly and favors 
those who have not. Sort of like a Bitcoin bail-in; are some miners are too big 
to fail? It also creates the expectation that it may happen again. This infects 
the money with the sort of uncertainty that Bitcoin is designed to prevent.

 

e

 

From: bitcoin-dev-boun...@lists.linuxfoundation.org 
[mailto:bitcoin-dev-boun...@lists.linuxfoundation.org] On Behalf Of Tier Nolan 
via bitcoin-dev
Sent: Wednesday, March 2, 2016 10:08 AM
Cc: Bitcoin Dev 
Subject: Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm

 

On Wed, Mar 2, 2016 at 4:27 PM, Paul Sztorc via bitcoin-dev 
 > wrote:

For example, it is theoretically possible that 100% of miners (not 50%
or 10%) will shut off their hardware. This is because it is revenue
which ~halves, not profit.

 

It depends on how much is sunk costs and how much is marginal costs too.

If hashing costs are 50% capital and 50% marginal, then the entire network will 
be able to absorb a 50% drop in subsidy.

50% capital costs means that the cost of the loan to buy the hardware 
represents half the cost.

Assume that for every $100 of income, you have to pay $49 for the loan and $49 
for electricity giving 2% profit.  If the subsidy halves, then you only get $50 
of income, so lose $48.  

But if the bank repossesses the operation, they might as well keep things 
running for the $1 in marginal profit (or sell on the hardware to someone who 
will keep using it).

Since this drop in revenue is well known in advance, businesses will spend less 
on capital.  That means that there should be less mining hardware than 
otherwise.

A 6 month investment with 3 months on the high subsidy and 3 months on low 
subsidy would not be made if it only generated a small profit for the first 3 
and then massive losses for the 2nd period of 3 months.  For it to be made, 
there needs to be large profit during the first period to compensate for the 
losses in the 2nd period.

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm

[Tier Nolan via bitcoin-dev]

On Wed, Mar 2, 2016 at 4:27 PM, Paul Sztorc via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> For example, it is theoretically possible that 100% of miners (not 50%
> or 10%) will shut off their hardware. This is because it is revenue
> which ~halves, not profit.


It depends on how much is sunk costs and how much is marginal costs too.

If hashing costs are 50% capital and 50% marginal, then the entire network
will be able to absorb a 50% drop in subsidy.

50% capital costs means that the cost of the loan to buy the hardware
represents half the cost.

Assume that for every $100 of income, you have to pay $49 for the loan and
$49 for electricity giving 2% profit.  If the subsidy halves, then you only
get $50 of income, so lose $48.

But if the bank repossesses the operation, they might as well keep things
running for the $1 in marginal profit (or sell on the hardware to someone
who will keep using it).

Since this drop in revenue is well known in advance, businesses will spend
less on capital.  That means that there should be less mining hardware than
otherwise.

A 6 month investment with 3 months on the high subsidy and 3 months on low
subsidy would not be made if it only generated a small profit for the first
3 and then massive losses for the 2nd period of 3 months.  For it to be
made, there needs to be large profit during the first period to compensate
for the losses in the 2nd period.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm

[Peter Todd via bitcoin-dev]

On Wed, Mar 02, 2016 at 02:56:14PM +, Luke Dashjr via bitcoin-dev wrote:
> To alleviate this risk, it seems reasonable to propose a hardfork to the 
> difficulty adjustment algorithm so it can adapt quicker to such a significant 
> drop in mining rate. BtcDrak tells me he has well-tested code for this in his 
> altcoin, which has seen some roller-coaster hashrates, so it may even be 
> possible to have such a proposal ready in time to be deployed alongside 
> SegWit 
> to take effect in time for the upcoming subsidy halving. If this slips, I 
> think it may be reasonable to push for at least code-readiness before July, 
> and possibly roll it into any other hardfork proposed before or around that 
> time.
> 
> I am unaware of any reason this would be controversial, so if anyone has a 
> problem with such a change, please speak up sooner rather than later. Other 
> ideas or concerns are of course welcome as well.

Changing the difficulty adjustment algorithm significantly changes the
security of the whole system, as it lets attackers create fake chains
with a lot less hashing power.

Given as tx fees rise this problem will hopefully be a one-time issue, a
simple fixed difficulty adjustment probably makes sense. No need to
bring in new algorithms here with controversial new security tradeoffs.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org
045a03e0e551c4e674f301e0a8eeb217a31ad13580446626


signature.asc
Description: Digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm

[David A. Harding via bitcoin-dev]

On Wed, Mar 02, 2016 at 02:56:14PM +, Luke Dashjr via bitcoin-dev wrote:
> To alleviate this risk, it seems reasonable to propose a hardfork to the 
> difficulty adjustment algorithm so it can adapt quicker to such a significant 
> drop in mining rate.

Having a well-reviewed hard fork patch for rapid difficulty adjustment
would seem to be a useful reserve for all sorts of possible problems.
That said, couldn't this specific potential situation be dealt with by a
relatively simple soft fork?

Let's say that, starting soon, miners require that valid block header
hashes be X% below the target value indicated by nBits. The X% changes
with each block, starting at 0% and increasing to 50% just before block
420,000 (the halving). This means the before the halving, every two
hashes are being treated as one hash, on average.

For blocks 420,000 and higher the code is disabled, immediately doubling
the effective hash rate at the same time the subsidy is halved,
potentially roughly canceling each other out to make a pre-halving hash
equal in economic value to a post-halving hash.

Of course, some (perhaps many) miners will not be profitable at the
post-halving subsidy level, so the steady increase in X% will force them
off the network at some point before the halving, hopefully in small
numbers rather than all at once like the halving would be expected to do.

For example, if the soft fork begins enforcement at block 410,000, then
X% can be increased 0.01% per block. Alice is a miner whose costs are
24BTC per block and she never claims tx fees for some reason, so her
profits now are always 25BTC per block. During the first difficulty
period after the soft fork is deployed, the cost to produce a hash will
increase like this,

0: 0%   500: 5% 1000: 10%   1500: 15%   2000: 20%
100: 1% 600: 6% 1100: 11%   1600: 16%
200: 2% 700: 7% 1200: 12%   1700: 17%
300: 3% 800: 8% 1300: 13%   1800: 18%
400: 4% 900: 9% 1400: 14%   1900: 19%

Somewhere around block 417, Alice will need to drop out because her
costs are now above 25BTC per block.  With the loss of her hash rate,
the average interblock time will increase and the capacity will decrease
(all other things being equal). However, Bob whose costs are 20BTC per
block can keep mining through the period.

At the retarget, the difficulty will go down (the target goes up) to
account for the loss of Alice's hashes. It may even go down enough
that Alice can mine profitably for a few more blocks early in the new
period, but the increasing X% factor will make her uneconomical again,
and this time it might even make Bob uneconomical too near the end of
the period. However, Charlie whose costs are 12BTC per block will
never be uneconomical as he can continue mining profitably even after
the halving. Alice and Bob mining less will increase the percentage of
blocks Charlie produces before the retarget, steadily shifting the
dynamics of the mining network to the state expected after the halving
and hopefully minimizing the magnitude of any shocks.

This does create the question about whether this soft fork would be
ethical, as Alice and Bob may have invested money and time on the
assumption that their marginal hardware would be usable up until the
halving and with this soft fork they would become uneconomical earlier
than block 420,000. A counterargument here is such an investment was
always speculative given the vagaries of exchange rate fluctuation, so
it could be permissible to change the economics slightly in order to
help ensure all other Bitcoin users experience minimal disruption during
the halving.

Unless I'm missing something (likely) I think this proposal has the
advantage of fast rollout (if the mechanism of an adjusted target is as
simple as I think it could be) in a non-emergency manner without a hard
fork that would require all full nodes upgrade (plus maybe some SPV
software that check nBits, which they probably all should be doing
given it's in the block headers that they download anyway).

-Dave

P.S. I see Tier Nolan proposed something similar while I was writing
 this. I think this proposal differs in its analysis to warrant a
 possible duplicate posting.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Guarantees Strong, not Eventual, Consistency.

[Emin Gün Sirer via bitcoin-dev]

> The entire point of the definition of eventually consistency is that your
> computer system is running continously and DO NOT have a final state, and
> therefore you must be able to describe the behavior when your system either
> may give responses to queries across time that are either perfectly
> consistent *or not* perfectly consistent.
>
This is not the definition of eventual consistency. From
https://en.wikipedia.org/wiki/Eventual_consistency:
Eventual consistency is a consistency model used in distributed computing
to achieve high availability that informally guarantees that, if no new
updates are made to a given data item, eventually all accesses to that item
will return the last updated value.

The actual definition makes it quite clear that a system need not have a
final state to be evaluated for its consistency properties. Almost all
practical database systems execute continuously without a final state.

> And Bitcoin by default *does not* ignore the contents of the last X
> blocks. A Bitcoin node being queried about the current blockchain state
> WILL give inconsistent answers when there's block rearrangements = no
> strong consistency.


One could split hairs here by pedantically defining "Bitcoin by default" --
you could refer to just the reference client code and ignore the shim code
in the app that interfaces with the client -- but that'd drag us into a
fruitless email-list-style discussion from which no one would emerge any
wiser. I'll avoid that, and will instead dryly note that the reference
client's listreceivedbyaddress will return the number of confirmations by
default, and every application will then check the confirmations value to
confirm that it exceeds that application's own omega, while
getbalance,getreceivedbyaddress will take a number of confirmations as an
argument, shielding the app from reorgs of the suffix. That is precisely
the point made in the post.

> Not to mention that your definition ignores the nonzero probability of a
> block rearrangement extending beyond your constant omega.
>
The post covers this case. Technically, there is a difference between 0
probability and epsilon probability -- this is the reason why Nakamoto
Consensus was an exciting breakthrough result; the same reason why
Lamport's results regarding a 3f+1 bound on the Byzantine Generals Problem
do not apply to Nakamoto Consensus; and the same reason it took our paper
(Majority is Not Enough) to show that Nakamoto consensus has a similar 33%
bound as Lamport-style consensus when it comes to tolerating Byzantine
actors.

Practically, however, there is little difference between 0 and a value that
exponentially approximates 0, given that we operate on hardware subject to
random errors. The post makes the case that one can pick an omega such that
the probability of your processor mis-executing your code is larger than
the probability of observing a reorganization.

Bitcoin provides a probabilistic, accumulative probability. Not a perfect
> one.
>
Sometimes, non-technical people get confused about the difference between
very very very small probabilities that approximate 0 and 0. For instance,
some people get very worried about hash collisions, on which Bitcoin relies
for its correctness, whose probability also drops exponentially but is not
exactly 0. Your overall point seems to be an analogous concern that
Bitcoin's exponentially dropping probability of reorganization isn't quite
a "perfect" 0. If so, I agree and the original post made this quite clear.
Though I hope we can avoid that kind of discussion on this particular list.

- egs
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm

[Bryan Bishop via bitcoin-dev]

On Wed, Mar 2, 2016 at 8:56 AM, Luke Dashjr wrote:

> We are coming up on the subsidy halving this July, and there have been some
>

Luke,

One reason "hard-fork to fix difficulty drop algorithm" could be
controversial is that the proposal involves a hard-fork (perhaps
necessarily so, at my first and second glance). There are a number of
concerns with hard-forks including security, deployment, participation,
readiness measurement, backwards incompatibility, etc. In fact, some
Bitcoin Core developers believe that hard-forks are not a good idea and
should not be used.

# Hard-forks

An interesting (unspoken?) idea I’ve heard from a few people has been “we
should try to avoid all hard-forks because they are backwards
incompatible”, another thought has been "there should only be one more
hard-fork if any" and/or "there should only be one hard-fork every 30
years". I also recognize feedback from others who have mentioned "probably
unrealistic to expect that the consensus layer can be solidified this early
in Bitcoin's history". At the same time there are concerns about “slippery
slopes”

Also, if you are going to participate in a hard-fork then I think you
should make up some proposals for ensure minimal monetary loss on the old
(non-hard-forked) chain, especially since your proposed timeline is so
short seems reasonable to expect even more safety-related due diligence to
minimize money loss (such as using a new address prefix on the hard-forked
upgrade). Anyway, it should be clear that hard-forks are an unsettled issue
and are controversial in ways that I believe you are already aware about.

# Have miners gradually reduce their hashrate instead of using a step
function cliff

adam3us recently proposed that miners who are thinking of turning off
equipment should consider gradually ramping down their hashrate, as a show
of goodwill (and substantial loss to themselves, similar to how they would
incur losses from no longer mining after the halving). This is not
something the consensus algorithm can enforce at the moment, and this
suggestion does not help under adversarial conditions. Since this
suggestion does not require a hard-fork, perhaps some effort should be made
to query miners and figure out if they need assistance with implementing
this (if they happen to be interested).

# Contingency planning

Having said all of the negative things above about hard-forks, I will add
that I do actually like the idea of having backup plans available and
tested and gitian-built many weeks ahead of expected network event dates.
Unfortunately this might encourage partial consensus layer hard-forks in
times of extreme uncertainty such as "emergencies" creating an even
further emergency.

# "Indefinite backlog growth"

You write "the backlog would grow indefinitely until the adjustment
occurs". This seems to be expected behavior regardless of difficulty
adjustment (in fact, a backlog could continue to grow even once difficulty
adjusts downward), and the consensus protocol does not commit to
information regarding that backlog anyway...

# Difficulty adjustment taking time is expected

This is an expected part of the protocol, it's been mentioned since
forever, it's well known and accounted for. Instead, we should be providing
advice to users about which alternative payment systems they should be
using if they expect instantaneous transaction confirmations. This has been
a long-standing issue, and rolling out a hard-fork is not going to fix
mistaken assumptions from users. They will still think that confirmations
were meant to be instantaneous regardless of how many hard-forks you choose
to deploy.

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm

[Dave Hudson via bitcoin-dev]

I think the biggest question here would be how would the difficulty retargeting 
be changed?  Without seeing the algorithm proposal it's difficult to assess the 
impact that it would have, but my intuition is that this is likely to be 
problematic.

Probabilistically the network sees surprisingly frequent swings of +/-20% in 
terms of the block finding rate on any given day, while the statistical noise 
over a 2016 block period can be more than +/-5%.  Any change would still have 
to require a fairly significant period of time before there would be a 
reasonable level of confidence that the hash rate really had fallen as opposed 
to just seeing statistical noise 
(http://hashingit.com/analysis/29-lies-damned-lies-and-bitcoin-difficulties and 
http://hashingit.com/analysis/28-reach-for-the-ear-defenders).

How long would be required to deem that the hash rate had dramatically fallen?  
Would such a change be a one-time event or would it be ever-present?

If we were to say that if the hash rate dropped 50% in one day (which could, of 
course be a 30% real drop and 20% variance) and the difficulty was retargeted 
to 50% lower then that would have to be matched with a similar rapid retarget 
if it were to increase by a similar amount.  Failing to do this both ways this 
would introduce an economic incentive for large miners to suppress the 
difficulty and gain dramatically larger numbers of block rewards.  The current 
fixed block count per difficulty change prevents this because the daily losses 
while suppressing hashing outweigh the potential gains when it's re-added.


Cheers,
Dave


> On 2 Mar 2016, at 14:56, Luke Dashjr via bitcoin-dev 
>  wrote:
> 
> We are coming up on the subsidy halving this July, and there have been some 
> concerns raised that a non-trivial number of miners could potentially drop 
> off 
> the network. This would result in a significantly longer block interval, 
> which 
> also means a higher per-block transaction volume, which could cause the block 
> size limit to legitimately be hit much sooner than expected. Furthermore, due 
> to difficulty adjustment being measured exclusively in blocks, the time until 
> it adjusts to compensate would be prolonged.
> 
> For example, if 50% of miners dropped off the network, blocks would be every 
> 20 minutes on average and contain double the transactions they presently do. 
> Even double would be approximately 850-900k, which potentially bumps up 
> against the hard limit when empty blocks are taken into consideration. This 
> situation would continue for a full month if no changes are made. If more 
> miners drop off the network, most of this becomes linearly worse, but due to 
> hitting the block size limit, the backlog would grow indefinitely until the 
> adjustment occurs.
> 
> To alleviate this risk, it seems reasonable to propose a hardfork to the 
> difficulty adjustment algorithm so it can adapt quicker to such a significant 
> drop in mining rate. BtcDrak tells me he has well-tested code for this in his 
> altcoin, which has seen some roller-coaster hashrates, so it may even be 
> possible to have such a proposal ready in time to be deployed alongside 
> SegWit 
> to take effect in time for the upcoming subsidy halving. If this slips, I 
> think it may be reasonable to push for at least code-readiness before July, 
> and possibly roll it into any other hardfork proposed before or around that 
> time.
> 
> I am unaware of any reason this would be controversial, so if anyone has a 
> problem with such a change, please speak up sooner rather than later. Other 
> ideas or concerns are of course welcome as well.
> 
> Thanks,
> 
> Luke
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm

[Tier Nolan via bitcoin-dev]

If a hard-fork is being considered, the easiest is to just step the
difficulty down by a factor of 2 when the adjustment happens.

This means that miners still get paid the same minting fee per hash as
before.  There isn't that much risk.  If the hashing power stays constant,
then there will be 5 minute blocks for a while until everything readjusts.

Nearly the same can be accomplished by a soft fork.

Proposal:

If 900 of the last 1000 blocks are block version X or above, then the
smooth change rule applies.

The adjustment is as follows

big_number get_new_target(int height, big_number old_target) {
if (height < 405000)
return old_target;
else if (height < 42)
return (old_target * 15000) / (height - 39);
else
return old_target;
}

What this does is ramp up the difficulty slowly from 405,000 to 420,000.
It ends up with a target that is 50% of the value stored in target bits.
These blocks are valid since they have twice as much POW as normally
required.

For block 42, the difficulty drops by 2 and the reward drops by 2 at
the same time.  This means that miners still get paid the same BTC per
hash.  It would mean 5 minute blocks until the next adjustment though.

If 90% of the network are mining the artificially hard blocks, then a  10%
fork still loses.  The 90% has an effective hash rate of 45% vs the 10%.

It is unlikely that miners would accept the fork, since they lose minting
fees.  It effectively brings the subsidy reduction forward in time.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm

[Jérémie Dubois-Lacoste via bitcoin-dev]

> BtcDrak tells me he has well-tested code for this in his altcoin
Could you be more explicit, which altcoin is that?

> I am unaware of any reason this would be controversial
Probably not until you get to the details of any proposal. What is
your exact proposal here? Algorithm? Parameters?
As you likely know a too short time window would be dangerous for
other reasons. Getting to an agreement as to what is reasonable or not
is not necessarily trivial.

Jeremie


2016-03-02 16:14 GMT+01:00 Luke Dashjr via bitcoin-dev
:
> On Wednesday, March 02, 2016 3:05:08 PM Pavel Janík wrote:
>> > the network. This would result in a significantly longer block interval,
>> > which also means a higher per-block transaction volume, which could
>> > cause the block size limit to legitimately be hit much sooner than
>> > expected.
>>
>> If this happens at all (the exchange rate of the coin can accomodate such
>> expectation),
>
> The exchange rate is not significantly influenced by these things.
> Historically, it seems fairly obvious that the difficulty has followed value,
> not value following difficulty.
>
>> the local fee market will develop, fees will raise and complement mined
>> coins, thus bringing more miners back to the game (together with expected
>> higher exchange rate).
>
> Depends on the hashrate drop, and tolerance for higher fees, both of which are
> largely unknown at this time. At least having code prepared for the negative
> scenarios in case of an emergency seems reasonable, even if we don't end up
> needing to deploy it.
>
> Luke
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm

[Luke Dashjr via bitcoin-dev]

On Wednesday, March 02, 2016 3:05:08 PM Pavel Janík wrote:
> > the network. This would result in a significantly longer block interval,
> > which also means a higher per-block transaction volume, which could
> > cause the block size limit to legitimately be hit much sooner than
> > expected.
> 
> If this happens at all (the exchange rate of the coin can accomodate such
> expectation),

The exchange rate is not significantly influenced by these things. 
Historically, it seems fairly obvious that the difficulty has followed value, 
not value following difficulty.

> the local fee market will develop, fees will raise and complement mined
> coins, thus bringing more miners back to the game (together with expected
> higher exchange rate).

Depends on the hashrate drop, and tolerance for higher fees, both of which are 
largely unknown at this time. At least having code prepared for the negative 
scenarios in case of an emergency seems reasonable, even if we don't end up 
needing to deploy it.

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm

[Pavel Janík via bitcoin-dev]

> the network. This would result in a significantly longer block interval, 
> which 
> also means a higher per-block transaction volume, which could cause the block 
> size limit to legitimately be hit much sooner than expected.

If this happens at all (the exchange rate of the coin can accomodate such 
expectation), the local fee market will develop, fees will raise and complement 
mined coins, thus bringing more miners back to the game (together with expected 
higher exchange rate).
--  
Pavel Janík




___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Guarantees Strong, not Eventual, Consistency.

[Natanael via bitcoin-dev]

To say that Bitcoin is strongly consistent is to say that the memory pool
and the last X blocks aren't part of Bitcoin. If you want to avoid making
that claim, you can at best argue that Bitcoin has both a strongly
consistent component AND an eventually consistent component.

The entire point of the definition of eventually consistency is that your
computer system is running continously and DO NOT have a final state, and
therefore you must be able to describe the behavior when your system either
may give responses to queries across time that are either perfectly
consistent *or not* perfectly consistent.

And Bitcoin by default *does not* ignore the contents of the last X blocks.
A Bitcoin node being queried about the current blockchain state WILL give
inconsistent answers when there's block rearrangements = no strong
consistency. Not to mention that your definition ignores the nonzero
probability of a block rearrangement extending beyond your constant omega.

Bitcoin provides a probabilistic, accumulative probability. Not a perfect
one.
Den 2 mar 2016 04:04 skrev "Emin Gün Sirer" <
bitcoin-dev@lists.linuxfoundation.org>:

>
> There seems to be a perception out there that Bitcoin is eventually
> consistent. I wrote this post to describe why this perception is completely
> false.
>
> Bitcoin Guarantees Strong, not Eventual, Consistency
>
> http://hackingdistributed.com/2016/03/01/bitcoin-guarantees-strong-not-eventual-consistency/
>
> I hope we can lay this bad meme to rest. Bitcoin provides a strong
> guarantee.
> - egs
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev