BCH eDAA, I would like you to meet: 10MBT  (10 Min Block Time)

This is a reply to a post on reddit here:

https://www.reddit.com/r/btc/comments/i2yjii/joint_statement_on_aserti32d_algorithm/

I am not sure what to call this, it definitely wont fit as a modified DAA, so I am going with the 10MBT 😊

It was suggested to offer a solution instead of complaining (about Amaury – acting like a dictator and forcing new code that will increase the confirmation times in opposition to majority of BCH dev team).  I support Amaury based upon the great things that he did in the past, but I will not support him fighting like a dictator and pushing controversial changes.

This DAA, or keeping a consistent 10 min block time, is not what makes BCH great, but having 10 second blocks and 3 hour blocks are hurting BCH.

Please understand, I do not believe my idea will get implemented, probably not even tested.  I do not believe there is anyway that I will benefit.  There is no angle here I am working to gain any fiat or crypto.  – this is not why I am writing this.  I am writing this to help open some minds to some other possibilities.  What I propose is not that 2 + 2 = 4 is wrong, just that there are other methods we can use to calculate 2+2 =4  (abacus, count with fingers, calculator, etc, etc.)

Background:

With Multiple coins using the double SHA256 hashing algorithm (including BTC-core or BTc) and the emergency DAA (eDAA) BCH implemented, there are games afoot.  With the eDAA, the difficulty target adjusts more often than every 2016 blocks.  What is happening, miners with significant hashpower will mine BCH at a significant profit over BTc and once the eDAA adjusts so it is more profitable to mine BTc the hashpower leaves BCH.  Once the eDAA lowers the difficulty again, the hashpower moves back to BCH.  This happens over and over to maximize miner profitability.

The issue is, BCH block time (or confirmation time) is not even close to being consistent 10 minute, this produces block times from seconds to hours.  (Ironic that as I am writing this, we are on block 646782, currently at 152 minutes.)  These hour long block times create problems for people moving coins onto and off of exchanges (during the very very long, hour long blocks).  No one complains about the very fast block times, but these short block times hurt a constant coin issuance rate.  (Armaury is pushing a DAA upgrade to increase the overall blocktimes to correct for historical drift, this will not fix the large variance if there are 300% swings in hashrate.)

Goals:

Before we get into the discussion of a proposed solution, I want to define the goals that this solution (or any other new DAA) should have.

·        10 min block times  (as close 10 minutes as realistic possible)

·        Keep double SHA256 POW  (no silly POS stuff)

·        Reduce Re-Org Risk?

·        Reduce Orphan Rate?

·        Eliminate 51% attack?

Correct?  These are our goals, correct?  Maybe a little broader goals than what you expected when you started reading this.  I don’t think having an urgent fix to correct the historical drift is any benefit, rather it will just make the current situation worse.  If future block time average is 10 minutes or slightly over, we are correcting the drift.  The more future blocks that are at 10 minutes, the historical average will approach 10 minutes.

To consider the idea described below, we will need to keep our minds open, remove any narrative biases, and be willing to remove/replace code that came from the original bitcoin.

Using DAA to adjust difficulty to create 10 minute blocktimes

When bitcoin was originally created, it was designed for only one bitcoin, not competing chains using the same double sha256.  The concept was, everyone/anyone that wanted to mine Bitcoin, would mine and they would mine as close to 24/7/365.  So, as Bitcoin gradually gained hashrate, the difficulty would adjust to keep blocktime at 10 min.  I really doubt that Satoshi envisioned the competing chains of today.  If so, the DAA might have been something else.- MAYBE

There is the planting of the seed.  Maybe the DAA or eDAA or any version of it may not be the best solution for our current situation.

Digging Deeper into the current problem with DAA or any version of it

Using DAA to control block times is SIMILAR to controlling water level in the following scenario:

Imagine you have a cylindrical tank of water. The tank is 12 inches in diameter and 200 feet tall. At the top of the tank there are Twenty different 6 inch pipes that can all add water to the tank.  All those input pipes are controlled by 20 unknown people that can add as much water or as little they want, whenever they want. We can not see the water going in the tank, we only know the tank level.  At the bottom of the tank, there is one 12 inch valve that WE can open or close to control the level in the tank.

Imagine that WE are assigned to keep the level of water in the tank to 10 feet. Imagine that the only way to know the current level of the tank is that the current level must be passed thru 3 people before you know the tank level. Imagine that these 3 people can pass only one note every 10 min. ( 1 to 2, then 2 to 3, then 3 to you) When we get the level of the tank, the information is now 30 minutes old, and now we can make one change to the valve and we have to wait at least 10 minutes before we know how the level changed.

Now imagine you get paid a 100 Trillion dollars if you can keep the tank level between 3 and 20 feet. Now imagine that the 20 unknown people that control the water going in can win the 100 Trillion dollars if they can make you fail.

The input water from the 20 different pipes is the hashrate.

The 12 inch outlet valve to control the level is the DAA.

The 10 foot level in that tank is our 10 minute block time.

This example may seem a little exaggerated, but the reality of the current eDAA is much more difficult than the water level example.  (hour long blocks vs 10 min delays in the feedback of the tank level).

I do not believe "constant hashrate" is a safe, or realistic assumption to base any DAA today.  Take whatever version of the DAA you want, you will loose, loose bad trying to keep the water level between 3 to 20 feet.

Imagine if a coins success depended upon how closely they came to achieving the targeted confirmation times?

What I am proposing is a tank that is only 15 feet tall, regardless how much water is put into the tank, the water level will never go over 15 feet (excluding the global flood).  But in the solution below, there is no chance for a global flood.

Solution:

Eliminate the DAA and replace with a new system,

To state it simply:  In the new system the miner with the highest difficulty solution at 10 min will win the block reward. 

Everything else is just details to make that happen.

The new system will:

Keep block times constant at 10 minutes (or relatively constant) – Regardless of hashrate.

            Continue to use double sha256 POW

            Eliminate crazy swings in blocktimes

            Eliminate orphans

            Eliminate ReOrgs

            Eliminate 51% attacks

Details of the Solution:

Some of the main terms of the new system.  An initial objection may be that this requires a central time authority.  We sort of have one now, right?  Who is the authority that determines that 2016 blocks was more or less than 2 weeks?  Sorry to throw this in here, I did not want to start another debate, just consider that.  We can circle back here if you want.    The answer is, NO, this does not require a central time authority, we will use a consensus based time authority.

Block Age in Seconds:  This is how long ago the work started on the current block.  We would use the same method to agree on Block Age as used to agree on the first transaction in Avalanche.  As soon as your node gets notified of a new block, you reset the block age timer to zero.  After a specified time (say 60 seconds?) you start asking/transmitting your block age and come to a consensus of the current block age time.  (New Block Age would start = 0 seconds when the Block Overtime is exhausted)  This does not have to be accurate to ms, but probably +/- a second or two.  More technical people would know what the is a realistic limit to set here.

Best Diff:  This is the current Best Diff that has been submitted to the network. When mining starts we will start storing our local Best Diff solution.  Obviously, we would not want all nodes  to be transmitting every Best Diff within the first few minutes as there would be intense traffic of Best Diff.  So, at some time Block Age, (for discussion, lets say 5 min or 300 seconds)  Prior to 300 sec, we will just store and replace our Best Diff until 5 min.  After this time we will store the network Best Diff and use that as our goal to beat while mining.  At 10 minutes, the block will be complete and awarded to the highest Best Diff (intrinsic definition).  What if scenarios below.

Block End Time:  This is what we can adjust to get the average to 10 minutes.  For example we say winner is always chosen at exactly 600 seconds, but based upon data from past 2016 blocks, the average is 615 seconds, then we can adjust this Block End Time to 585 get the average to 600.

Block Overtime:  What happens when Best Diff at 600 seconds, then another Best Diff comes in at 602 seconds.  How does this get settled, the 602 sec Best Diff is higher than the 600 Best Diff.  To eliminate these orphan situations, we will use this “Block Overtime”  lets say it is set to 10 seconds.  So Best Diff is chosen at 600 sec Block Age, and another higher Best Diff comes in at 610, then the award will go to the Best Diff that came in at 610 only if there is no higher diff submitted before 620.  This will not go on forever as a higher difficulty will be required.  (almost bet 500 BCH that it would never go beyond 1 hour, probably never past 20 minutes)  What if we have the first Best Diff at 600 and a 2nd higher Best Diff at 611.  We can again use the Avalanche method to determine if the 611 Best Diff is actually at 610 or 611.  If consensus is 611, then the block award goes to 600, if consensus is 610, then block reward goes to 610 unless there is no higher Best Diff submitted at 620 or before. (Not sure if anyone is familiar with online car auctions.  Once there is a high bid, they give x seconds for someone else to bid and if there is no higher bid, the winner is the high bid.  If someone bids at x-1 seconds, the bidding time gets extended another x seconds.  And this continues until there are no higher bids.  Here is an example https://www.youtube.com/watch?v=Qz3ken1gR0Y )  

This new 10MBT allows miners to implement different strategies, but will not hurt users.   Do I keep my best diff secret and start mining next block based upon my best diff?  I see a Best Diff that should easily win, do I stop mining current block and start on next block based upon the high submitted diff? (because statistically I wont find higher diff in the amount of time left?) etc etc,  These are strategies that may benefit a miner, but do not hurt the users planning on 6 confirmations per hour.  This will eliminate orphans.  If you have a 611 Best Diff, consensus you are not an orphan.  This is actually a better orphan solution than any of the DAA out there in BTc BCH or BSV.

Objections/Questions/Arguments/Quibbles:

Questions:

Will we maintain hashrate?  Yes, we will maintain hashrate that is equal to the price and mining profitability as other double sha256 coins. 

How?  Imagine all the miners say, I am not playing that game and they stop mining BCH.  Well I dig out my TRS-80 and I am mining all the blocks on BCH.  I am making what, $11,250 every hour.  Probably would not stay like that for long right?  Based upon historical blocks Best Diff, you will be able to calculate difficulty target that will give you an “indication” of how much work is required to win a block.  This will be what is used to help miners choose when to and when not to mine.  No miner will know the winning diff until that block Best Diff is found.  Just like today, sort of.  This will eliminate the “selfish mining” that is laying havoc to our confirmation times.  I believe any version of a DAA will continue to see the same problems when the hashrate goes +/-200%.

Will there be a higher chance of Re-orgs, or will we need checkpoints?  I don’t honestly see how someone could reorg or the need for checkpoints anymore.  No more hash war.  If you want to mine something else, go ahead.  You want to attack us, go ahead.  Not sure I have thought this thru, but I do not think there is any chance of someone doing harm with 100,000x the hashrate. 

Will 51% attack be possible?   And do what, claim block rewards? I think someone would have to gain control of many nodes.  But then, nodes could be configured to only connect with trusted nodes so the Avalanche system does not get gammed.  I guess someone that hates BCH, could just mine all the coins and dump them on the exchanges.

Objections:

What will keep a miner from saying Block Age is 600 seconds, when its not?  Or saying Block Age is 400 seconds when it is really 200.  Or doing anything against the rules?  Same thing that keeps them from doing that now: consensus.  They can do whatever they want now, but everyone plays within the framework of the rules.  I have not seen anyone set their block reward to 1,000,000.  Why not?  They could do it if they wanted.

This is changing bitcoin and we are not keeping true to the whitepaper.  First, I do not believe Satoshi planned for our situation.  He clearly believed a minority chain would/should die.   Second, how many changes have we made that were not in the whitepaper.  Last, if we keep the same hash algorithm, same limited supply, keep the same functions to lock/chain the blocks together, we use the same address/keys/transaction methods and we maintain 10 minute block times, this pretty much is bitcoin.  We must use the DAA! – well our confirmation/block time consistency looks like a joke, lets fix it.

Arguments: 

This is not proven or tested.  Well lets do it.  We do not have time to make a change this upgrade.  We could add the ASERT DAA (or nothing) and then replace the DAA with 10MBT next upgrade in May 2021.  I always say, anything is easy if you are not doing the work, I am not doing the coding work.  But this is not that complicated.  (not like trying to explain the difference between addresses and private keys or trying to explain the exact problem that asics are trying to solve to win the block reward)  Someone with Chris Pacia expertise with Avalanche implementing a version of this, I think would be rather straightforward.

Quibbles:

You are removing the decentralized clock bla bla bla.  That is a myth.  Our goal is decentralized p2p electronic cash, not decentralized clock bs.  BTW, our decentralized eDAA clock is all FUBAR anyhow

            The only way this will work is with DAA.  DAA or die

            Block times do not = Water level

            Valves are not difficulty adjustments

            No it won’t work

            Not right

            You are wrong

            You are lying

            You are just anti-bch

            Troll Troll Troll

            Your momma

            I know you are!  What am I?

Was any of the quibble section funny?