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
> 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 facto
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
> 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
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
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 th
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
19 matches
Mail list logo
