> On 9 Mar 2016, at 20:21, Bob McElrath wrote:
>
> Dave Hudson [d...@hashingit.com] wrote:
>> A damping-based design would seem like the obvious choice (I can think of a
>> few variations on a theme here, but most are found in the realms of control
>> theory somewhere). The problem, though, is
On 3/9/2016 3:18 PM, Henning Kopp via bitcoin-dev wrote:
> Hi,
>
> > However, I think it could actually increase
> > confidence in the system if the community is able to demonstrate a good
> > process for making such decisions, and show that we can separate the
> > meaningful underlying principles,
On 3/9/2016 1:30 PM, Dave Hudson via bitcoin-dev wrote:
> The hash rate has jumped up by almost 70% in the last 6 to 7 months and that
> implies some pretty serious investments by miners who are quite aware of the
> halving.
There are a few ways in which that information would be irrelevant:
[1.]
Dave Hudson [d...@hashingit.com] wrote:
> A damping-based design would seem like the obvious choice (I can think of a
> few variations on a theme here, but most are found in the realms of control
> theory somewhere). The problem, though, is working working out a timeframe
> over which to run the d
Hi,
> However, I think it could actually increase
> confidence in the system if the community is able to demonstrate a good
> process for making such decisions, and show that we can separate the
> meaningful underlying principles, such as the coin limit and overall
> inflation rate, from what is m
A damping-based design would seem like the obvious choice (I can think of a few
variations on a theme here, but most are found in the realms of control theory
somewhere). The problem, though, is working working out a timeframe over which
to run the derivative calculations.
The problem is the m
My recent conversations with miners revealed:
* Many have made "extra-large" hardware investments recently.
* Some wonder if we have just reached (or are quickly reaching) a
plateau of hardware-efficiency. This would mean that
hardware-investments might not be made in the critical period
immediat
Dave Hudson via bitcoin-dev [bitcoin-dev@lists.linuxfoundation.org] wrote:
> 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 i
An alternative soft fork would be to require that miners pay some of the
coinbase to a CLTV locked output (that is otherwise unlocked). This allows
the release of the funds to be delayed.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
Since the root cause of what you are trying to address is the reward
having, I'd suggest considering an adjustment to the having schedule.
Instead of their being a large supply shock every four years, perhaps the
reward could drop every 52,500 blocks (yearly), or even at each difficulty
adjustment,
On 03/02/2016 03:02 PM, Peter Todd wrote:
> 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 ar
It makes sense to me that there might be objective conditions under which
we would want to use a number smaller than 2016. A good example would be a
mean time between blocks of more than 20 minutes over the last 144 blocks
(one - two days). If such an occurrence ever happened, and the software
t
On Thu, March 3, 2016 10:02 am, Peter Todd via bitcoin-dev wrote:
> 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
On 3/2/2016 12:53 PM, Gregory Maxwell via bitcoin-dev 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
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 fut
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 exp
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 i
in-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
mailto:bitco
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 ho
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 f
It is **essential** that emergency code be prepared. This code must be
able to lower the difficulty by a large factor.
---
This halving-difficulty-drop problem can, with some bad luck, get quite
disastrous, very quickly.
( I did a micro-study of this problem here, for those who are unaware:
http
On Wed, Mar 2, 2016 at 5:14 PM, David A. Harding via bitcoin-dev
wrote:
> 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 si
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 fo
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 a
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 f
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 m
On Wednesday, March 02, 2016 2:56:14 PM Luke Dashjr via bitcoin-dev wrote:
> 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.
Lapse of thinking/clarity here. This probably isn't a practica
> 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
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.
>
> I
> 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
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
31 matches
Mail list logo
