AMT users thread.

[clenell]

im curious... is there even 1 amt miner out in the world that is working?

[opieum2]

im curious... is there even 1 amt miner out in the world that is working?

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

[omgbossis21]

Im interested but that magnet torrent sucks lol

[opieum2]

Im interested but that magnet torrent sucks lol

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.

[NotFuzzyWarm]

im curious... is there even 1 amt miner out in the world that is working?

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.

[opieum2]

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.

[captin crunch]

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.)

[JorgeStolfi]

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%.

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?

[opieum2]

Please note that because of the extended time it took to get you the machine AND the loss you incurred financially in that time you still qualify for a refund. The MPP never forget is part of all this. At the very very least AMT and it's CEO Joshua Zipkin made a pledge in that MPP that guaranteed you to achieve ROI even at their expense. So paying you back the money you spent plus 1$ would legally meet that requirement. BY AMT's admission couple of pages back and Joshua Zipkin CEO who would have had to authorize such a statement, we are investors in AMT. He later of course claims that after shipping our hardware we are not.

I recommend since he has made such a claim (only 3-4 pages back even) you report him to the SEC. As this would constitute investment fraud. the FBI, SEC, FTC should all be aware of this. As there are a number of aspects to this situation that could involve each of them. On the consumer side, FTC, the investment issue SEC, and criminal actions like death threads should have the FBI. Considering the amounts taken from us federal law enforcement needs to be involved. But if NOONE speaks up for themselves it will never happen. Right now there are only a few people who have put in reports. And that is not enough it requires ALL of the customers whether they got hardware or not to report to each of these agencies. Complacency or expectation that someone else will do the work to get you your money back will not work!! And Joshua Zipkin is likley counting on that apathy. I urge you ALL to speak up for yourselves to each of these agencies. It requires reports in numbers. THIS is why BFL got nailed by the FTC because 300 reports were filed with them that got their attention I was one of those reports.

As was mentioned I sent each of you who are known customers with the information to contact the FBI. If you have not reported, then please do so, the longer you take to do so the more likely Joshua Zipkin will get away with YOUR money. There are limits to how long something like this can go on before they do nothing does matter.

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.)

[opieum2]

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%.

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?

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. 

[JorgeStolfi]

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?

No they are not. I checked for that in the firmware. The configs are easy to see without an SSH connection.

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?) 

[opieum2]

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?

No they are not. I checked for that in the firmware. The configs are easy to see without an SSH connection.

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?) 

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.

[AMT_minerLESS]

To remind y'all:

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

[JorgeStolfi]

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.

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?

[opieum2]

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.

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?

Gotcha. I would have to run some forensic tools to check. Not likely though. Josh is not very tech savvy, The people he outsourced or bought might be though. If so that would also indicate some serious issues. However you hypothesis would also explain why we don't have SSH access to the system. But the configs somewhere would indicate that he is indeed hashing against another pool with some of the hash power. As possible as it is, It does not appear so. But certainly worth more digging.

[NotFuzzyWarm]

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.

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?

Earlier this year a disgruntled IT worker at a cable company in Canada did something rather like that. The weak points was using Stratum (I don't) and his access to routers at the company.

Normal share divisions is timed by the pools servers. In round-robin they periodically poll the miners to see if data is needed or available from them. To some extent I assume the polling is adjusted to a miners performance but still is up to the pool servers to decide. Like any good single purpose tool the miner only does what is needed and only when asked.

Stratum makes the miner a bit more of an active party in that it does not wait. Only link I found on a quicky is https://en.bitcoin.it/wiki/Stratum When needed it pings the block server for actions. In the above case it also pointed out a flaw in Stratum - the ability to actually *run* other code. AFAIK that is fixed btw.

Point is, yes the perp injected code into miner data being moved: At the ISP's routers he targeted a couple pool servers for the re-directs and injection. Once the miner got the new code it from time to time changed the wallet addresses mined to...

[JorgeStolfi]

Once the miner got the new code it from time to time changed the wallet addresses mined to...

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.

[NotFuzzyWarm]

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.

[NotFuzzyWarm]

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.

[NotFuzzyWarm]

Well, bitmain is a very honest company and they give ssh access.

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..