Topic: AMT users thread. - page 7. (Read 60015 times)

Fact is it is very possible this is what these miners are doing. AND might ultimately explain a few things. One AMT/Joshua Zipkin knows I have the know how to actually figure this out. So his efforts to silence me might be a way to stop this. Thankfully the idea is out there and i am not the only one with the ability to look at this hence why the raw image is out there. As I cannot manipulate timestamps due to the nature of linux security, he cannot claim it was altered. There are LOTS of moving parts and that would be easily exposed if he claimed I had. So in effect AMT may be hiding something under the hood.

This leads to an even MORE disturbing idea.....the WEBui IS accurate and JorgeStofoli's idea is correct. Some of that hashpower is going to f2pool or another pool. Which would be highly illegal and now puts Joshua Zipkin directly in the crosshairs of hacking and espionage as this sort of thing falls squarely under that. There is no disclaimer. AND the hardware coming from China...well considering the issues Cisco has had with counterfeit hardware in recent years, this could present some new areas for law enforcement to cover. This certainly is an avenue to look at. Thanks Jorgestofoli for the insight. I will start bruteforcing the image to get into the SDcard. I might be able to uncover the cgminer code. It may turn out there are alot of discards and hardware errors. But IF it turns out a portion of our mining power (which if the UI reports) is actually mining to another wallet/pool. Then this is the smoking gun we all need. And it means its even present in the new code as well.

IF AMT puts out new updates, I STRONGLY recommend you do not download it unless it has access to SSH so cgminer performance AND validate pool info. At this point they may be putting out tainted code. Be VERY careful until the community can validate any new code at this point. This should also go for other vendors like lktec and anyone who does not allow under the hood access to their hardware. It is AGAINST the open nature of bitcoin as it is.

I will power up the miner tonight and see if I can capture some net traffic off it to see where its going. It should be going to my chosen pool and nowhere else. Any other locations and then that should provide some insight into whats going on. IF it turns out traffic is being diverted from the miners, then we solved the mystery of the constant 1.27Ths.....it is hashing at that BUT with a portion of it going to Joshua Zipkin's wallets....which would be theft plain and simple. I will make a video as I sniff the traffic. Least that way the community can see it. And this will be the same untouched image. Others with the same performance issues not using this image can duplicate my results if there are any results to duplicate.

Ja. that is why Opeium and I were baffled about the weird connections popping up when looking at the network realtime graphs. It was Opie that finally recognized one of the addresses as a ntp time server.

Weird thing is it didn't show up on the rt graphs on my s1's. then again I recall Bitmain was having troubles with ntp back then and may have disabled the function. When I recently updated the s1 software it now showed traffic when ntp was on..

Smething that traffic may have been is communications to ntp.org time servers. When I got my first Ant s3's I saw a LOT of weird ip addresses being talked to - including one owned by Bitmain.

 Turns out they were time servers being polled every 5 min.
I disabled using a time server in the Ant configs and traffic stopped.

ja, it is. And is why we need to be able have full root access to these miners. If they are hard coded to ping an address it would be in the configs for the CPU used. In the Canadian case it was only kept in temp storage as the cable ISP's routers took care of re-injecting when needed.

I see.  So the risk is real, it seems.

As I wrote before, in another thread some clients of Chinese manufacturer "lketc" complained about lack of ssh access, and someone claimed that the manufacturer was stealing hashpower.  IIRC, they even detected encrypted internet traffic between the mining rig and the manufacturer.  But I did not see any followup on those claims.

That is the intended overall effect, OK; but I was asking about a technical implementation detail, to see whether a manufacturer can steal hashpower from a pool member.

AFAIK, the mining software periodically gathers a batch of unprocessed transactions into a candidate block, that includes a coinbase transaction directing the eventual reward to the pool's input address.  Then the mining software sets one or more machines to work on that candidate block.  The work consists in making a series of attempts. In each attempt, the nonce field in the block header is replaced by a different value, and the SHA-squared hash of the header is recomputed.  If the hash value is below the network difficulty threshold, the attempt was successful and the block is broadcast to the bitcoin network, which credits the reward to the pool.  Otherwise, if the hash is below the pool's difficulty threshold, the block and the hash value are sent to the pool, as proof of effort.  Otherwise the attempt has no effect.  Correct so far?

Now consider whether this attack by malicious mining software could be viable: in one attempt out of every six (or in one candidate block out of every six) the software replaces the coinbase output address by the thief's address.  As before, if an  attempt yields a hash below the network threshold, the block is broadcast to the bitcoin network.  Otherwise, if the hash is below the pool's threshold and the coinbase address is pointing at the pool, then block+hash are sent to the pool as proof of effort.  Otherwise, the attempt has no effect.

If this attack could be set up, then the data seen by the pool would be consistent with the miner having only 5/6 of the hash power that he really has.  Of every 6 successfully mined blocks, 5 would be credited to the pool, and 1 to the thief; but the pool will not notice the latter.  If the miner is monitoring his performance exclusively through the pool's site, he will not notice the stolen blocks either -- only a loss of 1/6 of the hashpower.

Does this make sense?

To remind y'all:

http://i.imgur.com/Hi5bZN2.jpg

The way it works is the miner is a worker in the pool handling some of the processing duty to mine a block in the pool. The pool in effect would be like a giant worker directly pointed at the bitcoin network decrypting blocks. Each worker within that pool is identified and gets a share of the solved block. I think that is more or less the simplest explanation I can come up with.

Thanks!

I do not know how mining pools work.  Do you send each mined block to the pool, and they broadcast it? Or do you broadcast it yourself, and the block just directs the reward to the pool's address?  (I presume the latter, to avoid unnecessary delay, correct?) 

No they are not. I checked for that in the firmware. The configs are easy to see without an SSH connection. I just need ssh so I can see what cgminer actually reports. But right now I can mount the sdcard in a linux machine and see the configs. Maybe someone will turn something else up. But as far as I can tell it just performs at less than it's reported speed.

I actually contacted ckolivas for some advice. I am going to enable debug mode in cgminer so that it logs performance stats as it mines. I will do this on the miner I have configured with my pools. This is an alternate way of getting results. 

That matches other reports in this thread.

The less damning explanation is that they doctored the software to show 15-20% more than reality.

A more worrisome possibility is that they are somehow using 15-20% of the machine's capacity to mine for their own profit.  Is that technically possible?  Can the miner access the internet on its own?

Hi everyone.
Sorry I've been a little quiet lately. Had some family over for an extended stay which in turn put me way behind with work, and after nearly a year of this bullshit I had to take a break and step back, get some work done and watch from the sidelines.

Note to Josh. Just because we are not posting does not mean everyone is not watching or participating.

After AMT posted that they planned to issue refunds to every one, whether they received their machine's or not I finally unpacked the one machine I received. The packaging was in reasonably good shape and no sharp rusty metal so that was a good thing. The 1st thing I did was pull the sd card and make an image. ( haven't had the time or lynex skills to investigate into it or to try to ssh or putty into the pi yet.) If anyone is interested I could figure a way to get it online and make it available.

Hooked the miner up to my laptop and turned it on and holy hell that thing is loud. ( I have to do what fuzzy did and get those fans away from the boards and heat sinks and make a shroud to duct the flow into the boards. The current design is quit similar to the way they made WWII air raid sirens.) anyway with a couple of adjustments to my network settings I was into the miner console, reset the network settings to be compatible with my LAN and fed in my pool info. Shut the thing down, plugged it into the network, fired it up and I was off to the races making a whopping .015 btc per day.

I in no way want to count myself as one of the lucky ones but this 1 machine has been running smoothly but INCREDIBLY LOUD. The console claims an average hash rate of 1.24T but the pool stats show 1.04T over a 12 hour average. A difference of about 16%. I am curious for those of you who have ant's or other miners how those percentages stack up on there local vs. pool stats? I know some loss is expected but is a 16% or more loss common among comparable machines from other producers?

My Story to come for anyone who is interested. (It may take a while as it is a long one.)

That seems consistent with my experience. The 1.2 thing is a VERY rare spike though. That is not nominal. 1.2 is supposed to be the advertised actual functioning rate. I could understand drops TO 1Ths an up to 1.3. But it functions at 800-1000Ghs on average. That would be considered nominal. SO again AMT and Joshua Zipkin has lied and deceived. We did not even get the promised hashrate. AND this CANNOT be disputed as it is VERY clear from a technical standpoint. It is a repeatable event. Not to mention the in ability to SSH in to see whats REALLY going on under the hood which in iteself is suspicious considering Josh aka AMT_Miners keeps giving out bad logins, which in time will be possible by bruteforcing the key. I have not bothered with that yet.

Has anyone been able to SSH into the original interface? Because the new firmware likely will have scrubbed any trace of their mining and such.

I have the feeling that after me cleaning it up, changing the fans *and getting a PSU from AMT*, channeling airflow, my miner is one of the best of these running out there...

Consistently reports 1 to 1.02ths on the EMC pool with 900ghs or so for dips and the occasional 1.21ths as a not very often spike.

Oh, and the 1 working card from the original design testbed is still running a rock-solid 178ghs. A long way from the 250-something ghs it should be but solid. The 2 other functional ones shipped with it died within days.

https://filetea.me/t1s0ZlLi5lzSJ25xqn3CglKSQ

If it still does not work I will need to check some network settings. I recently changed my network around.

http://www.mediafire.com/download/doc827z8m7zqwo0/AMT_image_original.img.gz.bz2 this will work better.

Im interested but that magnet torrent sucks lol

To specs at 1.2THs? No. Fans are deafeningly loud 85Db roughly OSHA standards mean its going deaf time. The proof is in the hardware we got. The interface shows a constant 1.27Ths but the various pools report the real hashrate we get mrpark is reporting the same as I and I believe others who have their working to be hashing at well under 1.2Ths. Most 800-900Ghs with the occasional 1Ths spike. Thats a full 200-400Ghs drop in performance. As AMT is not giving out the SSH password (evidently giving the wrong ones out as none have worked that they posted) I get the impression that they don't seem to want us to take a look under the hood to see what cgminer really is reporting. And since the source is not released, another legal violation of the GPL, well again, damning against AMT. Nothing I am saying here is "slanderous" it is their own actions I am pointing out.

I already posted up an image for analysis to make sure the webui is not set to falsely report the UI. This is the ORIGINAL unmodified image that shipped with the miners prior to the AMT update. It also has their user name (kusmet is the user a bulgarian word for luck as confirmed by Bulgarian members of BCT) on f2pool and the logs show how long the machine was up for mining, at least mine. a full 2 weeks of mining at least, with the image having been created in MARCH!!! So even as early as march this machine was built. Just saying the proof is damning there.

If any linux gurus want to take a look and verify my findings that would be good. It would eliminate any bias.

magnet/?xt=urn:btih:B5ITPMAP52QMQBLWS4FSYKUWHA5XGPV3&dn=AMT_image_original.img.gz.bz2&tr=udp%3a%2f%2fopen.demonii.com%3a1337%2fannounce&tr=udp%3a%2f%2ftracker.publicbt.com%3a80%2fannounce&tr=udp%3a%2f%2ftracker.openbittorrent.com%3a80%2fannounce&tr=udp%3a%2f%2ftracker.istole.it%3a80%2fannounce&tr=udp%3a%2f%2ftracker.token.ro%3a80%2fannounce&tr=udp%3a%2f%2fcoppersurfer.tk%3a6969%2fannounce&tr=udp%3a%2f%2fpow7.com%3a80%2fannounce

Download qbtorrent and then copy and paste this link into the file > add link to torrent option. Then you will be able to download it.

This is a raw image dump of the SDcard. If you are on windows use windiskimage32 to write it to a new SDcard. For linux users dd will work just fine. It is compressed from 7.4Gb to 219.3Mb. Easier to download