I was about to say;  2.5.2 is the last version I have released;  so what are you using right now if not 2.5.2? lol

Looks definitely worth doing.

It will be compiled with cuda 10; and the recommended blockchain SDK version from fireice-uk's github instructions.

It could be tomorrow, it could be in a few days.   I have been in and out of it for a bit;  but ill try and get it done.

Block find rewards are held back for x amount of found blocks by that user.     Last x blocks never get funded to you and end up burnt;  unless in the future you start back up again.  This should [at first thought] all but obliterate the abuse of generating a new address for the purpose of mining; because too fast;  no pay;  not enough blocks per address?  no pay.... something along those lines anyways.   I am just trying to keep it simple until the nuances start to take hold and things get serious...   but the endgame is everyone has an equal chance.  You could calc a result with a slower device;  because it's salt can do wonders for odds.

MAybe build in a POS-type mechanism:  If you keep those fresh earned coins in your same account for longer;  the reward goes up a touch after 'y' blocks... also helps keep the people in check trying to mine too much too fast.



This is a small thought that may help with it.  So far; there's no logical way to approach a "limited devices per user" thing;  we will always have one or another person(s) with more hardware and more funding.


Maybe we should get a thread together separate than this;  But in my eyes;  fighting the selfish nature of "underground mining hardware/software", I think falls very in line with how things have been going through the year and its why I have been discussing it here.

It's a tough cookie to wrap your head around penalizing for calculating speed.  This is why I think it should be based of a standard but very precise timebase.  Things like microcontrollers and whatnot's internal clocks;  often suffer from voltage drift and a slew of other things.   I can't stress the emphasis of a good clock.



I do agree that times have definitely been slow in the altcoin world;  mainly because of the overall market being where it has been, and the countless amounts of altcoins that keep getting introduced; as well as the fact that asics/FPGA's have always shown that they basically end up taking over the greater share of earnings and making the gpu's less profitable.....  but to everyone;  remember;  didn't this happen before?   How did we recuperate then?  How do you think it will play out this time?    I smell a similar ride.   The idea is to keep in touch with what actually becomes something;  and what is just there to try and pyramid yourself over someone else and sell off.

Legitimately in my honest opinion;  95% of altcoins, are worthless and only carry a value because people still buy them.    Most of those;  started as a copy-and-paste pipe-dream with no actual ever widespread use of them but to simply use on an exchange to trade for another.   Most I see that have some type of advertised use, or whatever else;  legitimately [in my eyes] are farts in the wind, only they are less useful than a fart in the wind.

Sorry for the rambling =P

https://imgur.com/a/aq9gUe7

Im just gonna put it out there;  that even the things you think couldn't be effed;  truly are.


Look at the BTC total on the far left, then look at BTC in the center column on left;  the middle column; and the far right center column.

I only have one amount of BTC in my account;  and its close to 1mbtc... so i would believe the .8mbtc number from what I recall when I placed it into a purchase order.


Now;  This is my second gripe.

I did a withdraw;  pulled out exactly .04 (via their withdraw calculator on the w/d page).   Tx input to my wallet was .03999999...  so theres another gripe.

Also the Tx to me; had a fee substantially less than the withdraw fee.  I get it;  it's a fee.  But;  Everyone can see;  there's enough moving through the hot wallets that it adds up to a substantial sum.


It seems their fee habits keep changing.   I wish they were transparent with all of them and listed them somewhere as to be blatantly clear.   I've already called them out once on charging 1mbtc extra specifically for network tx speed, and they legit did not pay a tx even close to what my withdraw tx cost;  let along the ~50 other outputs to different people in the same tx.   Literally that massive tx, has a total "speed up fee" that was a fraction of my charged tx fees (when it was .0025 minimum tx fee from them).    They changed the fee the day after I sent a screenshot of their twitter post.

Anyways;  just another gripe;  to add to everyone else's.

Luckily;  I still have yet to not be paid;  if it does happen erratically (last time between payments was definitely over 8 months).

As of and up to today, All of my BTC/ETC/LTC withdraws have been relatively painless, as well as two other altcoins with online and block-height checked wallets.  Hopefully the future continues on the same.

If someone from yobit is watching here;  Consider integrating XMR.   Add another healthy staple to the ocean of trash.

There is a chance it could just be coincidence.

if you increase its normalization factor up to some arbitrary number (this will also influence your miner to swap to that algo, which helps us test quickly) lets say 0.28;  see if it indeed carries over to the difficulty setting.

If this is the case;  I would think someone screwed up a variable in the yiimp code by mistake....   seems like an easy enough variable to use by accident.

Yeah;  in order to limit hashing speeds;  the oscillator that the time function is based off of, would need to be very precise for repeat-ability;   but the time function wouldn't be for something as simple as a nonce;  it would be dispersed throughout the entire set of hashing functions.

The reason for the time based nonce is basically just to be another security protection against withholding blocks from the network.


you could;  but;  imagine the impact of my idea on a pool.......  Suddenly;  the large amount of hash is a bad thing... forcing decentralization... to a point.

I see how you could theoretically do the same functions on different addresses at the same time;  but their results will always be different each round; and would need to be calculated individually;  not linear-ally "through the same hardware pipe" so to speak; needing individual hardware for each.

this goes right in line with making the number of individual "devices" the core reason you would have more of a chance of getting a winning result....  making all devices relatively equal by limitations of time.

POS requires a coin value to be staked on the network (locked in).  I speak of POW.

This is about strictly adding a timebase standard that can be used to effectively nullify things that will calculate above a certain speed.   IT would make all devices effectively equal at a point; and would boil down to quantity of devices from that point on....   Equal opportunity in a manner of speaking.

of course things like;  adding simple functions that salt the time function's process on the next round; they come from the previous round's block's values;  and could be beneficial as well.

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.

login to yobit.

start a support ticket alerting them of the changes and necessity of updating the wallet.

Odds are they will read it and close the ticket letting you know they received it.


This is your best way of contacting them.


I personally have no way to contact them in regards to my sig campaign payments that are never are available;  so.... Its my best suggestion to you.

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.

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 was able to get pretty quiet results with S7's running full-bore...

make sure they are in their own space (I had mine basically in a tote surrounded by eggfoam) with ducting connected and sealed to the outlet and inlet.   With about 2 meters+ of ducting on either end(non insulated mind you),  it was no worse than a pc running.

but if these are coming off their shelf from their active use;  they aren't impacting the overall algo sum net hashrates as if they are a new product.  You probably aren't considering this.

I've been watching the steady price increase on XMR;  looks like the "powerdraw" and less asic insta-dumping is starting to take effect.

Ok,

  Another small utility I whipped up the other day.     I was having stability issues with xmr-stak; as well as wanting to have a clean auto-reboot mechanism in my miners.   Nowadays I tend to use teamviewer to track all of my devices and have easy access, but it tends to have strange crashes and not respond every now and then.   So;  two birds with one stone.     I don't use windows task scheduler.... it is... unreliable at best.

This simple batch file can be used to reset your process periodically, and set a system reboot timer as well.

Feel free to hack and splice this any way you wish;  Just remember;  if you incorporate it;  just give credit where credit is due as everyone should.

I do not ask for donations for my work.   But if you feel so inclined, there's a tiny donation address that can be found via the batch link in my signature.

rebooter.bat

My buddy is looking for someone that's selling a GTX 1080 Hybrid.  Prefer EVGA.   He is looking to by around a $300 price range.  So if you have are looking to sell for around that price, shoot him an email, vattaso@gmail.com


Thanks guys.
He asked me to pass on the word to anyone I know, so, here it is.

ill probably end up picking up one or two via private-party in-person sales locally... something like craigslist.

This is smelling exactly like when the S3 was selling for ~$40.....   I made a killing profit wise (again, power is not a factor for me in most respects) and sold them for the same or more later.

Even if they are bricks after;  I feel they could shadow the trend I saw with the S3.

Ok, so I finally got off my ass and went in and optimized my cards for what I could.

Made my previously ~890H/sec machine into a 1296H/sec machine.... no overclocks or any special configs;  Just modifying the threads, etc.  (poolside i'm seeing 1200-1600h/sec, which is the amount I had on cn7;  Which makes me wonder what it would have been on cn7 if i had done this earlier)


http://www.xmrstak.com   has countless user-submitted configs to give you an idea of what you need to do.  Just compare others' settings to see.      It seems that if I attempt a bios mod on the Rx560 I have, I could go up 30% in hashrate;  but I am not the type of user who does this;  even though I know how to accomplish it and have done it to cards before....   Since my business model isn't based around pinching every penny, or the absolute most efficient;  and the fact that this RX card is not my own as it was graciously lent to me by a fellow board member;  I doubt Ill be doing the bios mod....

But I highly suggest letting the autoconfigs happen, note the hashrates per card, then disable all but one and start trimming the values individually and doing tests;  it's worth the 10-30 min spent.   You can get quite a bump like I did from my 1070; went from ~420H/sec to ~588H/sec with very little effort.  I don't think ill tune it to get the highest possible, this was good enough for me.

I noticed another wallet hitting the network with a substantial deposit.

This is good.    We need more of this.  Shows increasing support of the project for sure.

I want to see yoBit's wallet shrink more and more guys =)

I know that the memory size was not the focus of the CNv8 changes...  Its all about creating functions that will overwhelm FPGA timing and circuit design... for starts....  Its a complex animal to get into.

But my main purpose for releasing/compiling and pushing xmr-stak specifically:  
1) Ive been trying to keep a no devfee miner app available specifically for monero.
2) I understand the code;  the cpp files and their uses.  I have edited them enough now over enough releases;  I get it.  Finally.
3) The source is 100% open and free.
4) less "fluff" associated with having many algos and functions that 99% of people wont use.  Most people who mine CN coins, only mine CN coins.... and would prefer a more optimized app for all of the the others individually.

I can see what angle you are coming from;  but I think you are missing the fact that you can use a cuda 8.0 library when compiling (or replacing my cuda 10 .dll from a separate compilation as I have mentioned in previous posts) and then you would not have to worry about the limits associated with cuda 10.  In response to your other post in another thread (i research shills in this thread before deleting, and you cut it under the wire :  The drivers are cuda backwards compatible (for game compatibility sake in the future for starts) and updating the driver;  is a good thing.  I have yet to have any issues with my 1070 or 1080.  
Only with one game, and one driver version did I have to rollback;  but that was only temporary until the game fixed its bug.

I do 100% understand the power limit you want to set for yourself;  but many people don't set mining limits just based on individual coin power draws;  if they aren't mining to sell immediately.

The official release from githib has: xmrstak_cuda_backend.dll    Just rename it to xmrstak_cuda_backend_9_2.dll and plop it into the folder with my release next to, or in place of my DLL.  See what it does.   Also;  you can just try replacing the file altogether: xmrstak_cuda_backend.dll and it shouldn't have cuda10 libs at the point.     I believe it chooses the cuda DLL based on what driver you have installed;  so if it still tries to load under cuda10 even though you added the cuda8/9 dll's, just replace the file instead of adding along side and it will force it.    I have it added alongside in my personal rigs so that my older generation cards can work alongside my current gen cards in the same machines.