[Bitcoin-ml] Time to get agreement on new DAA for Bitcoin Cash

Scott Roberts wordsgalore at gmail.com
Tue Oct 31 03:57:31 UTC 2017


If you remove the long tail, you'll need to raise difficulty for the
"short tail" in order to keep the correct avg solvetime.

But the math that attempts to measure the hashrate during the long
tail makes the overall difficulty lower.

I would "fix" the short tail, bringing it also closer to target time
T. The need for symmetry is cropping up again.

I would make the long and short tail difficulty adjustments
symmetrically continuous based on the probability of solve times.

I tried the following on the non-weighted average and it seems to work.

effective_D = D * 0.5 / (1-e^(-t/T)) for t < 0.693 T
and
effective_D = D * e^(-t/T) / 0.5  for t > 0.693 T

t=0.33 * T => eff_D = 1.78*wt_D

t=2 * T => eff_D = 0.24*wt_D



On Mon, Oct 30, 2017 at 8:56 PM, G. Andrew Stone
<g.andrew.stone at gmail.com> wrote:
> My proposal doesn't require a central time server.  It degrades gracefully
> if times are off by a bit because nodes can delay acceptance of a block.  It
> requires the same decentralized time as bitcoin today only with more
> accuracy.  This accuracy is not an issue given computers with enough power
> to process bitcoin.
>
> On Oct 30, 2017 6:20 PM, "Scott Roberts" <wordsgalore at gmail.com> wrote:
>>
>> It's surprising to see some people do not realize how bad the EDA is
>> and are proposing similar ideas.  There are a lot of alt clones that
>> have "big brothers" with the same codebase and POW. Their hashrate
>> compared to their big broth is often 100x times bigger than the
>> difference between BCH and BTC. They're doing fine because they use a
>> rolling average with an N < 100.
>>
>> Bitcoin cash will not suffer 10x changes in hash rate once it gets a
>> good algorithm.  Alts switching from a bad algo to a good one show the
>> hash attacks reduce in size from 20x to 3x simply due to having a
>> difficulty that responds.
>>
>> Any good simple difficulty algorithm with N from 15 to 50 will have
>> about 5% to 10% of its blocks "stolen" by hash attacks that will occur
>> 2 to 5 times a day. There is no fix. I have a script to identify when
>> miners are attacking. They do not have long delay problems after the
>> attacks.  There are a million ways for devs to mess it up with "fixes"
>> and cause a coin to lose 20% to 30% of their coins and suffer long
>> delays. All coins should be using Degnr8's with N=15 to 50.  My Zawy
>> v6 responds pretty much the same and you can see sumocoin and
>> karbowanek using the simple equation with N=30 and N=17. You can look
>> at Zcash and HUSH to know what an N=63 looks like (they use Digishield
>> v3 "tempering" N=17 slows it down to act exactly like N=63). Bitcoin
>> Gold will use it and I have an open issue with them trying to get them
>> to change it to N=40 and remove the "tempering".
>>
>> You should expect SQRT(N) variation for every N you observe. This is
>> not an oscillation caused by the algo. It's the Poisson. There is
>> nothing that can or should be fixed. Smoothing it out in any way will
>> slow down the response to attacks coming on and off.
>>
>> You should not employ filters, aka limits, aka tempering, aka
>> buffering to "fix" the above. There is no noise to be filtered.  The
>> Poisson randomness is not a white noise from a power source. It's
>> real, valid data that needs to be included.
>>
>> tw-144 is a PI controller with an advanced integration by using the
>> weights. The "integral" part is advanced by being weighted. That
>> enables tw-144 to estimate hashrate as of the previous block whereas
>> my Zawy v6 estimates it at N/2 blocks in the past, just like bitcoin,
>> except mine adjusts every block, like most alts.   I agree no "D" of a
>> PID controller can be used because that can cause real oscillations.
>> PID controllers are tuned for a given fixed system. Profit-seeking
>> miners are part of the "system" being controlled by difficulty. As
>> active intelligent profit-seeking agents, they will immediately cause
>> it be out of tune, causing oscillations, mining when it is low, and
>> leaving constant miners with it high.
>>
>> If you show me the psuedo code in my terminology  (D, T, ST) for piec,
>> I can compare it to TW.
>>
>> In your article and on the github, I can't make any sense of the
>> charts.  The hashrate should be plotted with the difficulty as I do in
>> this post:
>>
>> https://github.com/kyuupichan/difficulty/issues/11#issuecomment-340259718
>>
>> Concerning long tail: there is no way for all the nodes to determine
>> "current time". It is estimated by node peers. Peers can be planted.
>> If we didn't need mining to act as a timestamp server and had a real
>> clock for all the nodes, the nodes could be run as a syncronous
>> network that does not have a Byzantine problem. We would not need
>> mining. Central timestamp servers exist. We could use one to timestamp
>> a tx when sending it to the receiver and it would be recored on node
>> blockchains. Any tx with the same coin stamped after that would be a
>> double spend the nodes could detect without mining and receivers would
>> know the money was already spent. We don't do it because we can't
>> trust a central timestamp server.
>>
>> On Mon, Oct 30, 2017 at 12:50 PM, G. Andrew Stone via bitcoin-ml
>> <bitcoin-ml at lists.linuxfoundation.org> wrote:
>> > This is my work-in-progress analysis, posted early because of the sudden
>> > ABC
>> > decision:
>> >
>> >
>> > https://medium.com/@g.andrew.stone/tail-removal-block-validation-ae26fb436524
>> >
>> > In the first part I analyze the proposed algorithms.  In the second I
>> > propose that since all the algorithms can be exploited to some degree we
>> > need to take a different approach.
>> >
>> > One thing that I don't consider though is how much better the proposed
>> > DAAs
>> > are verses the EDA.  So I have no opinion on whether we should switch to
>> > a
>> > better DAA as a temporary measure.  However, I think that my analysis
>> > shows
>> > that miners who move between blockchains can extract at least 5%
>> > additional
>> > revenue at the expense of the "benevolent" miners who do not (within
>> > Neil
>> > Booth's simulation anyway), and it took me just a couple of hours and
>> > very
>> > simple algorithms to achieve that.  As I mentioned in my prior article,
>> > draining value from benevolent miners is dangerous since benevolent
>> > mining
>> > is required to generate at least a few blocks to trigger the DAA's to
>> > decrease difficulty and the benevolent miners create the median block
>> > confirmation time that is important for users.
>> >
>> >
>> >
>> > On Mon, Oct 30, 2017 at 4:44 AM, Erik Beijnoff via bitcoin-ml
>> > <bitcoin-ml at lists.linuxfoundation.org> wrote:
>> >>
>> >>
>> >> > On 30 Oct 2017, at 05:48, Jason Cox <jasonbradleycox at gmail.com>
>> >> > wrote:
>> >> >
>> >> > To add another question: From what I understand, the ABC Team is
>> >> > driving
>> >> > the DAA changes. Are the other teams (BU, XT, Classic) prepared to
>> >> > make the
>> >> > same changes? I'm assuming the patches are mostly compatible between
>> >> > these
>> >> > forks?
>> >> >
>> >>
>> >> In the case of Bitcoin Segwit I think it’s safe to assume that
>> >> traditionally changes have been pushed through in full by one single
>> >> party
>> >> controlling the agenda, namely Core. This is not the case with Bitcoin
>> >> Cash.
>> >>
>> >> My take on it is that in Bitcoin Cash there are three steps to
>> >> implementation in the network. 1). Developers propose changes,
>> >> single-handedly or in coalitions. 2) Influential miners choose to adopt
>> >> the
>> >> proposed changes (or not). 3) The economic majority accepts or rejects
>> >> the
>> >> changes. If there is major disagreement somewhere in these three steps,
>> >> you
>> >> risk a split, dividing the conflicting interests which from that point
>> >> will
>> >> be diverging in different directions.
>> >>
>> >> This is pretty much the ideal governance form of Bitcoin if you ask me.
>> >>
>> >> It's also the reason that I’ve continued to nag about this specific
>> >> issue
>> >> for about a month or more; I’m trying to facilitate the process
>> >> described
>> >> above, or at least keep it moving.
>> >>
>> >> When it comes to your specific question - a pull request has been
>> >> merged(?) into ABC that forces a decision at the 13th of November (for
>> >> ABC
>> >> users). Amaury Séchet of ABC has proposed a change to the DAA
>> >> algorithm. I
>> >> am not aware of wether this proposal or some other will be merged by
>> >> ABC.
>> >>
>> >> It is my belief that in the case of the DAA, developer alignment to the
>> >> proposal that is deemed to hold the most merit is the best way to move
>> >> forward. I’m pretty sure that if one proposal is generally accepted,
>> >> all
>> >> teams would be happy to adopt it. If not, I think it will be difficult
>> >> to
>> >> get them to implement.
>> >>
>> >> /Erik
>> >>
>> >> _______________________________________________
>> >> bitcoin-ml mailing list
>> >> bitcoin-ml at lists.linuxfoundation.org
>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml
>> >
>> >
>> >
>> > _______________________________________________
>> > bitcoin-ml mailing list
>> > bitcoin-ml at lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml
>> >


More information about the bitcoin-ml mailing list