This right here is pure gold.... but would drop the level of trust onto a singular entity (person holding the real private keys for said auth device).... so at some degree;  the creator of the coin/algo would need to have a hardware device created, as to serve as this token validator/creator/holder.

How do you control the amount of devices at play and assure they are properly distributed in such a manner?   This part is kinda tough to tackle.

Maybe if that hardware device was a trio of servers that reach a consensus and communicate with the "man in the middle" app or hardware device to implement a time value and tokens for proper results... but if this is the case... imagine the traffic you would have to manage to those servers...

To limit things further;  internet IP could play a BIG role in the submittal of hashes as well.   Only allow so many hashes to be obtained from a singular internet IP...   so proxy services, VPN services, large pools, etc... would all not be a usable endpoint to hide your true location and more-so "who you really are".    This could help filter things down to a manageable and realistic decentralization of mining on the network as well.


Good idea though, Ill try to add it to my concept idea.   Its still bubbles on a piece of paper... and very rudimentary... but it is in process.... and once I get it outlined, then its time to work on the actual details of each part of the algo/coin that works in this manner.

you sent to 0xff539..............

Seems that when I try to view the info about this token address, its invalid via:

https://etherscan.io/token/0x0affa06e7fbe5bc9a764c979aa66e8256a631f02?a=0xbe8a9b8dcc1fca21e9aa98526d151b0d706abf291591d81d93571e9060980ab2

check yourself: https://etherscan.io/token/Polybius?a=0xff539ad5f01a8111c3a1f75cd9387839b584d27e

Looking up: 0xff539ad5f01a8111c3a1f75cd9387839b584d27e alone shows it has not been touched since transfer.


Verify the address you sent to was correct, and not missing one or two digits.





you contradict yourself.

First you sent it to them.

Then you sent it from their address to them again?   Please clarify......

yet they want to do the merit system to prevent.... spam.


spam not ok here...
scam ok here?

for "asic" resistance,

I have been toying with the idea of being able to use some of the undocumented registers in the processors that date back to the early 90's, and were present in everything from intel to cyrix processors...

Some of them have finally had documentation in past years revealed, to which they were encryption functions (AES?) built-into the die.   My guess would most likely be government in origin.   I would not be surprised that if one of them is for decoding GPS encryption (military accuracy).  You can load the memory with your data, call the register, then read out the change and use for your algo.

Now;  the downside is they were created, so they were documented somewhere... which gives an insiders edge.


But requiring the mining device to basically have a complex PC built in (remember, x86, not ARM, etc)... it would kill the product cost of an ASIC to be able to hash more advanced functions like this.

Using the timer and clock of the x86 CPU, as a part of the algo running outside the x86 CPU   (see where this is going?)  You can now add a fixed time clock based on overall ticks or based on increments of ticks and memory values, etc. to the algo.    

Ive been trying to find a reasonable way to lock time to the mining algo in a way that you can't simply implement a fixed or known time variable.   It would need to have something to do with the network, such as how many TX in mempool, size of mempool, time since last block(s), last valid high (but not 100%) value share to the network, a consensus reply from the network, etc etc etc.   You could build in better block controls that will take out the randomness of nethash spikes, nethash decreases, etc.  Built in countermeasures that aren't related on the speed of a calculation are key to leveling the playing field.

Make it reward effort, not greed.

Yeah, Marvell2's pool is pretty solid so far;   But if you are mining to a wallet that does not play well with micro tx (Like I am), i'd not use them till the payout amount gets increased soon (I get dinged 2 rvn per micro tX)...
I think he was under the assumption is was configured higher then .001RVN payout every 2 hours       I've already PM'd and i'm sure it wont be this way for long..... a .001 tx of RVN is not much BTC value at all.


When I get time tonight, Ill probably try testing this coin to see whats possible...

 but im trying to stay away from "mine and hold" scenarios with anything but BTC....   all the RVN I have stacked up is literally just sitting on the exchange on a sell order waiting for a pump.

I want to lock this thread.


But I can't. 


I'm surprised this obvious scam activity hasn't been cut off by the mods.......   


I know they want to be sure before banning people, etc... but.... this one is pretty blatant guys.....

Yep, ill keep you guys posted.

Turns out the binary was only partially built;   if it ever tried to do anything with cuda/openCL, it would crash due to not being fully built.   My mistake..... but it did mine just fine on my lenovo laptop with integrated graphics.


So, for now, ill only have the 2.4.2 release available.  Gotta get the libraries working again.

its such a crapshoot though;  if block times roll by quickly;  sometimes some machines get more of a chance to get a submission in over others....

Ping time, and latency... oah latency can be a thorn.  Working from cellular connections:  I feel the pain.  Lots of long term tests for finding appropriate difficulties to run when I get high packet loss regularly is a tough thing to swallow.

Some algos act funny such as when mining xevan, I was able to set one rig at half the difficulty and still get the same server side hashrate of a rig twice as powerful.. seemingly about half of the time.   now, they were weak rigs compared to the "industry", but they taught me that luck is an ever changing and un-predictable factor....  scaling up, just exacerbates the readings during the short-term blocks.   Coins with long term blocks/hashes are a different story.


And, good job on the pool Marvell2.  I myself have yet to get a yiimp code properly configured to interface with a coin daemon....  hats off

Glad the no-ip DNS name helps;  its been a life saver for me, and has helped me recover a laptop in the past as well.   I suggest it to everyone here wanting a nice free customize-able DNS name for their dynamic IP device(s).... all you need from there is to open up some external ports on your router for <insert activity here>.  Sorry for skewing the topic further on the tangent.

Back on topic:

Eff Bitmain 

all you have to do is:

re-encode your application/miner to give zero output.  only return flags with program closure is an optimal config.  Be sure to build a single binary.  Incorporate all libraries.

Have it bitstream logs with your mining data to a FTP text file for monitoring if that's your thing.

obfuscate the miner app heavily. 
and most importantly:  Add the salt.    [you know what im talking about.... things like pages 13-69 of encyclopedia written in code form, encase the program in this nested code, but allow them to interact with junk variables.  simple intergers, add or subtract.... KISS]

have all data traffic from the machine salted with more traffic to a proxy that you control via a SSL tunnel;  do NOT let them decipher your data in any way..  Have that traffic be ~30x the normal traffic as mining would be.

Have the balls to generate an rsa key >8000 for this communication.... but 4096 personally generated keys can suffice if you up the salt.   Even the government would be scratching their heads trying to decipher your data in any reasonable amount of time.   The altered datastream to the proxy could be infinitely clever.

Unless "utilizing what you pay for" is violation of terms... they have ZERO to hold against you.....


And the steps are all pretty much trivial if you know what you are doing.




I remember when people were doing the free amazon AWS 'free' trial bots that would replicate infinitely......

do what I do for those dynamic IP situations;  use a no-ip.com free redirect and their client/daemon.    I use them for my VPN's DNS tag....  and the daemon will automatically report any changes in ip to no-ip... just bind the custom (free) dns name to cloudflare =)

All of my raspberry pi's are literally "plug in anywhere" on the internet and I can access them easily.  The only downside to the free dns names are they need manual log-in to no-ip.com once a month to renew them for another 30 days.  You can have up to 3 free.


Just a thought.


But when im less stressed with work, Ill point what I have to your pool;  see how it fairs for the little guys and ill give you my payout address for using in your statistics if needed.

No, msvc redis is a whole slurry of system dll files that don't belong in the program folder.....

This is why it's a system package from Microsoft....

When I finally make it home I'll try on 3 more machines to see if it's a singular fault, or if it's a universal fault to people without some msvc version installed.

*edit*
So it turns out I built as a debug release and it didn't build in the MSVC140 libraries into the executable like it did for earlier releases.

I am booting up the laptop with the compiler and attempting a final release recompile.

Stay tuned.

*edit again*

Gotta completely flush out all toolkits and compilers from my laptop, and try over again.

Very strange things are happening now.   Im going to pull the release.

It worked fine on CPU only apparently.  Something is miffed with the cuda and openCL integrations to the compiler for some reason.   The released binary was only partially built;  even though I can compile the solution for the binary by itself and get zero errors.


Hopefully Ill have more for you guys soon... but I need to get at a high speed internet link to do the reinstalls (again), and I have been working 10+ hour days at my day job... so Ill try to get on it shortly.

The most accurate approximation of a real sales pitch....  I am awaiting being proven wrong

It's definitely a msvc lib install needed


The redistributable should be included with the 2.4.2 release.  If not, reply here and I'll upload it to mega for you guys to download...

Screenshots or detailed list of the problem may help me resolve your issue.

It ran perfectly fine on my Lenovo laptop...

also, zpool has a x16r port.

there are plenty of statistics on the site to compare how they are doing profitability-wise.

ill PM later.  now that my compiler seems to be working, im going to dig up the x16r source I downloaded to compile originally... I think it was an x16r.   Ill keep you in the loop as I figure out more.

im still out and about dealing with some things tonight.  Hopefully I can devote an hour or two.

also many "mass" supporters are mostly low post users;  many were < 5 post users.

If it is indeed a real product, I will eat crow.  no worries there.   I am only offering sound logical advice to all users of this board.

yep, looks like electronium is supported.  give it a try.

Ive only tested with CN7 myself, but this should be exactly the same as the github precompile, aside from the zero devfee change and dev pool address change to localhost (127.0.0.1).   If theres an error in electronium;  it must exist in the main precompile found on github as well.

I just use the xmr-stak version I have compiled: https://bitcointalk.org/index.php?topic=3264773.msg34028507#msg34028507

but im using it on 1070 and earlier cards.... I mean, all the way down to the 400 series;  since power is included with my space rental....

It may not make sense dollar per dollar as it is valued right now;

but....

it will make sense as time goes on as I see a true long term value storage in XMR compared to its earlier days.    They have proven they are trying to fight asics/fpga's, and that adds a huge tick to long term value in my eyes.

BTC is different of course for obvious reasons, but that's a whole different topic.


I see wavering profitability from the algos I have held true to over the last two years.

new ones seem to bite me in the butt profitability wise (had I not switched my gear to check profitability), and the previously reliable algos are seeming like there are some sort of unknown hardware bloating hashrate.


So, Ill still stick with my XMR plan;  I think it will be worth more as time goes on.   ~300 seems a touch low for its utility and difference from BTC.    I can see it used for personal micro transactions over some of the other coins out there.




Now;  I have personally never mined zec past a 2 hour test when zec was ~2 months old.    It never fit the bill for me;  I made 4x on skien for example.  It's not a blockchain I am willing to maintain.  My bandwidth at home is rather limited (cellular), and I don't want to deal with the exchange process personally.   I dont see enough people using zec for person-to-person transactions.  they are usually via a 3rd (usually internet) party.


Can someone point me towards a good equihash windows binary/source that is zero devfee and somewhat efficient? (bleeding edge not necessary, but I dont want antiquated)    If it needs to be recompiled with no devfee;  I may be able to handle that like I did with XMR-stak.

I don't want to switch to using SMOS....  A:  not gonna pay the fee for the OS for one machine;  and second, I am trying to keep inside windows so I can incorporate equihash into my mminer batch.    Sometime in the future Ill be giving SMOS a whirl; but that's when im done playing with these antiquated cards, fully comprehend all the nuances of ATI cards (getting there... made much progress), and i am buying a lot of GPU's to put into boards/rigs I have ready and waiting to be populated.


Sorry for the novel;  I finally had more than a few words to say

sadly, for the sixth or seventh consecutive time, it will go on deaf ears.