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

[Scott Roberts]

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
>