Topic: 8th Alt coin thread. Or what to do now that asics are all over the place. - page 33. (Read 81547 times)

Two things I found from the interwebz:

- Why are cryptos falling? Some speculate that Christine Lagarde's call for central banks to issue their own digital currencies. The Managing Director of the International Monetary Fund is an influential politician. If government-issued cryptos are in play, they compete with the decentralized ones.

- Others point to the upcoming hard fork in Bitcoin Cash. Coinbase, one of the world's largest crypto-exchanges, decided to shut down trading in BCH ahead of the fork.

Since Binance already said they will support both chains, it sounds like a no-brainer. One should load up on BCH now before the fork. Now ofc, if the split doesn't go through, BCH could just resume trading... at a much lower level. Hmmm.

How likely is it that the fork will go through and there is enough hash on both sides?

I don't understand the exact reason for the drop either.

Its definately not people selling BTC to get BCH so they can get the forked coins.

It "could" be Craig Wright saying he is Satoshi and how he plans to sell large quantites of BTC to fund the hash rentals to mine BCH SV instead of ABC or BTC. However is he really "Satoshi"? Hence the reason why this reason for the drop is farfetched.

That doesn't make sense - it would tend to drop BCH and aid other coins.

Fork is coming soon

bch fork fight probably
https://mobile.twitter.com/ProfFaustus/status/1062751765601361923

Bitcoin was holding steady for like the past 3 months, for the most part going between $6000-$6500 for most of that time so this new down trend all across the board is a bit concerning.

Does anybody know what is driving down most of the market today by ~15%? I have been looking for news but have not yet found anything. One would think coindesk would have something but ...

Its not quite that simple when you understand how an FPGA works on the inside and is programmed; and most importantly how its internal configuration is made as to time each portion of its config to be in line and ready for each others sections to have done their work.

Prime example:  look how long it took to get an xevan bitstream to come to pass;  if you do the legwork and research that algo and its POW scheme;  you can make some relatively minor edits to the algo to completely disrupt the timings and require better or more hardware.

With FPGA's being so complex (many aspects to getting them to do things properly),  there is a lot people don't quite understand about them and how they can be effective or easily made obsolete...




If a hardware hashing device was based around a 10Mhz oven controlled crystal oscillator;  and the algorithm has a time factor built in that can be related/based on this;  it could easily become a standard for limiting hashing speeds;    and could easily be re-verified as to be a valid result by the network using that time-base schism.   It is of-course more involved than just a simple single function;  but if worked properly;  the time function can be integrated at steps throughout the process of calculating.

Example:  Calculate for a result;  and during each mathematical operation;  do a math operation on the intermediate value/variable with the timer's current value as a salt;  do the next step;  salt, etc.   All salt is based on the timer.

This way;  you are forced to conform to the 10Mhz oscillator's salt, and it will disrupt your ability to hash faster as your result won't match someone else that is running the correct timebase, when you are accelerated and hashing faster.

Before everyone gets too excited about the Digibyte idea, look at the followup tweet:

The idea is an algorithm that recreates itself every 10 days. FGPA's will be the ideal hardware to mine with. Every 10 days miners will get to "reprogram" and rediscover the most efficient settings to mine the #DigiByte #blockchain with.

Zcash next Major "Blossom" release will be active around October 28th, 2019: https://forum.zcashcommunity.com/t/announcing-zcash-blossom-and-proposed-feature-goals/31891

Guess timing will be close to Ethereum changing to POS.

it would be a little longer but pretty fast.

I think 10 days is too fast but 30 days works.

I know writing an algo is time consuming.

but pre write 24 of them.

It will hurt asics big time.

and hurt fpga's some what.  figure  3 days to week. before bitstream is modded.  and most likely it will be private not a public bitstream.

I wonder if you did this with a major coin what would happen but  for me I just mine BCI and don't worry about anything else. I am close to 2000 coins.

What? It takes me a few minutes with AwesomeMiner and even less now that Linux is supported.. deploying a new miner would take as little as 60 seconds for 100 rigs.

Exactly my point - having to deploy a new version of the mining software every 10 day basis would be a NIGHTMARE.



To the other comment about pre-defining the algorithms - do that, and an ASIC can be designed to do the same thing.

Which would ALSO kill the advantages of GPUs to a major degree and modern multi-core CPUs to a noticeable degree.

not the first time ive said this;

If you integrate time into at least 3-4 segments throughout the hash protocol/algo;  you can instantly void any asic's ability to calculate faster.  It would be forced to conform to a static time variable.


Let that sink in.

I agree. The PoW has to evolve so that it is ASIC resistant. If it is fixed, no matter how many, ASIC can be built for it.

Don't think it would make the coin completely ASIC resistant. Remember dark-coin with its X11 algo? In 2014 everybody assumed that an ASIC could never be designed for X11 because it has 11 different algo combined into one.

If they wrote 24 different algos and changed them every 10 days, then they would just design a similiar ASIC which can switch algos when the switch happens. Most likely they won't do it due to the small miner reward but if it was a coin like ETH or BCH that switched to this algo then you would see there would be ASICs being designed for this.

the best way to overwhelm an asic is timing;   if you can design the algo to necessitate a linear flow of programming of the FPGA;  it's advantages will pretty much be negated....

but changing algo once a month;  could be a good one;  but again;  it could bite them due to people not updating wallets/daemons; etc...  and releasing the algo change schedule initially will most certainly make people work towards one algo or another; etc.

its kind of a catch 22 as to what would be the best course of action.    4 months seems like a good point to do algo tweaks on the regular.   I tend to notice overall network diff increases at that point with monero by now;  and the next 3 months data will probably back that up when its to that point.

I hear what you are saying, but what is the difference between that and updating to a new version?

It would be slower for farms to update which would give the little guy a little bit of extra profit every 10 days.

I see your point though, it could turn into a nightmare very quickly.


I think that it changes automatically every 10 days, so there is never a need to code a algo.

I do agree every 10 days is a bit quick, but how long does it take for a fpga programmer to up date their bitstreams??

every 10 days is faster then needed.

1 time a month should work.

prewrite 24 algos

release the new software on the last day of the month

start the new algo on the first of the month.

a gpu could  do the switch easy

but it would delay a fpga  for a bit of time  before it can switch

an asic would be trashed.


I think 1 time a month would hurt fpgas enough that they may not bother with the coin.