<unnamed>

Public Key

npub1re22dhneg8azw7z3979njqn2sp4gxzp4703g62tsrvmsvnj76heqj679nu

Profile Code

nprofile1qqspu49xmeu5r7380pgjlzeeqf4gq65rpq6l8c5d99cpkdcxfe0dtuspz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dspsz7mu

Publishing to

relay.damus.io

nos.lol

Last Notes

2023-06-07 19:49:33 CEST

- reply

📅 Original date posted:2016-03-09
📝 Original message:> On 9 Mar 2016, at 20:21, Bob McElrath <bob_bitcoin at mcelrath.org> wrote:
>
> Dave Hudson [dave at 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 derivative calculations.
>
> From a measurement theory perspective this is straightforward. Each block is a
> measurement, and error propagation can be performed to derive an error on the
> derivatives.
Sure, but I think there are 2 problems:
1) My guess is that errors over anything but a long period are probably too large to be very useful.
2) We don't have a strong notion of time that is part of the consensus. Sure, blocks have timestamps but they're very loosely controlled (can't be more than 2 hours ahead of what any validating node thinks the time might be). Difficulty can't be calculated based on anything that's not part of the consensus data.
> The statistical theory of Bitcoin's block timing is known as a Poisson Point
> Process: https://en.wikipedia.org/wiki/Poisson_point_process or temporal point
> process. If you google those plus "estimation" you'll find a metric shit-ton of
> literature on how to handle this.
Strictly it's a non-homogeneous Poisson Process, but I'm pretty familiar with the concept (Google threw one of my own blog posts back at me: http://hashingit.com/analysis/27-hash-rate-headaches, but I actually prefer this one: http://hashingit.com/analysis/30-finding-2016-blocks because most people seem to find it easier to visualize).
>> The problem is the measurement of the hashrate, which is pretty inaccurate at
>> best because even 2016 events isn't really enough (with a completely constant
>> hash rate running indefinitely we'd see difficulty swings of up to +/- 5% even
>> with the current algorithm). In order to meaningfully react to a major loss
>> of hashing we'd still need to be considering a window of probably 2 weeks.
>
> You don't want to assume it's constant in order to get a better measurement.
> The assumption is clearly false. But, errors can be calculated, and retargeting
> can take errors into account, because no matter what we'll always be dealing
> with a finite sample.
Agreed, it's a thought experiment I ran in May 2014 (http://hashingit.com/analysis/28-reach-for-the-ear-defenders). I found that many people's intuition is that there would be little or no difficulty changes in such a scenario, but the intuition isn't reliable. Given a static hash rate the NHPP behaviour introduces a surprisingly large amount of noise (often much larger than any signal over a period of even weeks). Any measurements in the order of even a few days has so much noise that it's practically unusable. I just realized that unlike some of my other sims this one didn't make it to github; I'll fix that later this week.
Cheers,
Dave

2023-06-07 19:49:33 CEST

- reply

📅 Original date posted:2016-03-09
📝 Original message: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 measurement of the hashrate, which is pretty inaccurate at best because even 2016 events isn't really enough (with a completely constant hash rate running indefinitely we'd see difficulty swings of up to +/- 5% even with the current algorithm). In order to meaningfully react to a major loss of hashing we'd still need to be considering a window of probably 2 weeks.
My other concern is that if we allow quick retargets to lower difficulties then that seems likely to expose the chain to being gamed. I'd need to think about this some more, but a few scenarios I was thinking about earlier this week appeared to risk making some types of selfish mining strategies quite a lot more profitable.
With all this said though I'll be very surprised if there's a huge drop in the hash rate come July. 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. My guess is that quite a lot of the baseline 30% has also been replaced in the same cycle. These same miners were mining with a coin price around $250 last year so in terms of profitability I'm pretty sure that one around $400 won't be a huge concern.
I'm sure that there will be some very public "I'm done with mining" announcements from a few smaller miners come July, but I suspect the bulk of the network will have a relatively small blip and continue on its way.
Cheers,
Dave
> On 8 Mar 2016, at 22:05, Bob McElrath <bob_bitcoin at mcelrath.org> wrote:
>
> Dave Hudson via bitcoin-dev [bitcoin-dev at 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 is
>> likely to be problematic.
>
> I have no comment on whether this will be *needed* but there's a simple
> algorithm that I haven't seen any coin adopt, that I think needs to be: the
> critically damped harmonic oscillator:
>
> http://mathworld.wolfram.com/CriticallyDampedSimpleHarmonicMotion.html
>
> In dynamical systems one does a derivative expansion. Here we want to find the
> first and second derivatives (in time) of the hashrate. These can be determined
> by a method of finite differences, or fancier algorithms which use a quadratic
> or quartic polynomial approximation. Two derivatives are generally all that is
> needed, and the resulting dynamical system is a damped harmonic oscillator.
>
> A damped harmonic oscillator is basically how your car's shock absorbers work.
> The relevant differential equation has two parameters: the oscillation frequency
> and damping factor. The maximum oscillation frequency is the block rate. Any
> oscillation faster than the block rate cannot be measured by block times. The
> damping rate is an exponential decay and for critical damping is twice the
> oscillation frequency.
>
> So, this is a zero parameter, optimal damping solution for a varying hashrate.
> This is inherently a numeric approximation solution to a differential equation,
> so questions of approximations for the hashrate enter, but that's all. Weak
> block proposals will be able to get better approximations to the hashrate.
>
> If solving this problem is deemed desirable, I can put some time into this, or
> direct others as to how to go about it.
>
> --
> Cheers, Bob McElrath
>
> "For every complex problem, there is a solution that is simple, neat, and wrong."
> -- H. L. Mencken
>

2023-06-07 19:49:32 CEST

- reply

📅 Original date posted:2016-03-02
📝 Original message: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 <bitcoin-dev at lists.linuxfoundation.org> 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 19:33:36 CEST

- reply

📅 Original date posted:2015-08-07
📝 Original message:> On 7 Aug 2015, at 16:17, Ryan Butler via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> A raspberry pie 2 node on reasonable Internet connection with a reasonable hard drive can run a node with 8 or 20mb blocks easily.
>
I'm curious as I've not seen any data on this subject. How fast can a RP2 do the necessary cryptographic calculations to validate blocks of various sizes?
While everyone tends to talk in terms of 10 minutes per block that is, of course, only a typical time and doesn't account for situations in which 2 or more blocks are found in quick succession (which, of course, happens on a daily basis). At what point does, say, an RP2 node fail to be able to validate a second or third block because it's still not finished processing the first?
If someone were to be playing games with the system and mining transactions without first broadcasting them to the network then how long would that take? This would in essence define the ability to DoS lower-performance nodes (ignoring all of the other usual considerations such as bandwidth, etc).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150807/80bcb76d/attachment-0001.html>

2023-06-07 17:44:08 CEST

- reply

📅 Original date posted:2015-07-30
📝 Original message:> On 30 Jul 2015, at 06:14, Tom Harding via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Another empirical fact also needs explaining. Why have average fees *as
> measured in BTC* risen during the times of highest public interest in
> bitcoin? This happened without block size pressure, and it is not an
> exchange rate effect -- these are raw BTC fees:
>
> https://blockchain.info/charts/transaction-fees?timespan=all&daysAverageString=7 <https://blockchain.info/charts/transaction-fees?timespan=all&daysAverageString=7>
I've not published any new figures for about 8 months (will try to do that this weekend), but the thing that that chart doesn't show is what's actually happening to fees per transaction. Here's a chart that does: http://hashingit.com/analysis/35-the-future-of-bitcoin-transaction-fees <http://hashingit.com/analysis/35-the-future-of-bitcoin-transaction-fees>
The data is also taken from blockchain.info so it's apples-for-apples. It shows that far from a fees going up they spent 3 years dropping. I just ran a new chart and the decline in fees continued until about 8 weeks when the "stress tests" first occurred. Even so, they're still below the level from the end of 2013. By comparison the total transaction volume is up about 2.4x to 2.5x (don't have the exact number).
> ... more evidence that conclusively refutes the conjecture that a
> production quota is necessary for a "functioning fee market." A
> production quota merely pushes up fees. We have a functioning market,
> and so far, it shows that wider bitcoin usage is even more effective
> than a quota at pushing up fees.
I think it's equally easy to argue (from the same data) that wider adoption has actually caused wallet users to become much more effective at fee selection. Miners (as expected, assuming that they hadn't formed a cartel) have continued to accept whatever fees are available, no matter how small. Only where there has been an element of scarcity have we actually seen miners do anything but take whatever is offered.
Clearly history is not an accurate indicator of what might happen in the future, but it seems difficult to argue that there has been any sort of fee market emerge to date (other than as a result of scarcity during the stress tests).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150730/aaba0a9a/attachment-0001.html>