Topic: Algorithmically placed FPGA miner: 255MH/s/chip, supports all known boards - page 12. (Read 119444 times)

Well, probably not anymore after this incident... This is a breach of trust/confidence/reliability which especially the large scale miners will take very seriously. On my side you've killed about 7 gigahashes, I'd assume the total from the people running my TML port for x6500/MMQ alone will be in the 50-100GH/s range.

IMO it would have been mandantory for you to publish the information that the bitstreams have a time bomb when you released TML. Your customers have a right to know that they will have to regularly update their systems, and if you had released that information you would surely have been reminded in time that the deadline is approaching.

Has there been a downtime of the signcryption services? Or do you block IPs that repeatedly try to connect with an old gateware version? After I rebased to 1.12 yesterday I wasn't able to contact any signcryption server anymore, they just refused the connection (and I saw that it tried several different IPs).

By the way, something occurred today: can variable difficulty be used to combat withholding attacks?  The higher the share difficulty, the higher the cost of the withholding attack -- the "found a block" shares represent a larger fraction of the submitted shares.  Could even be automated: if the pool sees a suspiciously low fraction of block-found shares from a miner, jack up their difficulty.

I know, I know.

So many features, so little time.

Well, the reasons are standardized as part of BIP 22.
Obviously it's not necessarily a rule for the now-obsolete getwork protocol, but there's no reason not to use the same strings either.

But more importantly: if your miner had supported the target - which has been standard since getwork was created - you wouldn't have these rejects at all.

Yeah, because I had a similar unexpected-downtime experience with EclipseMC -- they recently started rejecting two-low-difficulty shares.

Unfortunately since the X-Reject-Reason headers aren't standardized the safest thing to do is assume that when a share is rejected that work ought to be thrown out.  This wrecks the hashrate.

Below is an excerpt from an email I sent to TheSeven which does a good job of explaining the situation.

All of the anger is completely justified.  This was a screwup on my part.  The only consolation I offer is that this wasn't the result of me doing something, it was the result of me failing to do something.

The leibniz bitstream doesn't expire for another 40 days.  Long before then I will make sure this doesn't happen again, most likely by removing the ntime check.

FWIW, I had no idea so many people were using the TML.  I suppose that means that when I turn on the commissions I will get a nontrivial income from this, in which case I will have a strong motivation to take uptime very seriously.



Blue portions were edited relative to the email I sent him (due to wider audience).  Bold added for those who are skimming.

So ... someone was hashing with his bitstream for free ... instead of ?

Sounds like a good reason to kill off everyone (without notification) mining using his bitstream until they work out what is happening ... NOT!

I suspect he accidentally released enough information for a clever hacker to bypass the signcryption. Been resisting the temptation to try.

I still don't get why he didn't opt to open source his bitstream. Donations worth hundred of BTC instead of zero revenue from forced donations.
Yes, his next project will yield "much more than those few BTC" but what does this project has to do with that? FPGA mining will be dead in a few months.

In my opinion this already *was* irrational...

Indeed, besides pushing a new bitstream he also implemented difficulty >1 support, wow!
But why on earth does this warrant a breaking protocol change AT ALL? (Not to even mention that there was no prior notice.)
Well, maybe the old bitstream contained some critical flaw in the signcryption code that was fixed in the new one? I can't think of a different (rational) explanation. But OTOH it wouldn't be the first time for ET to act in a completely irrational way.

Wow - if that above is true - damn stay away from this
Proprietary FTL ...

Looks if code changed to avoid send of shares below difficulty.  May be because of load on TML servers.  It would be excuse for not allowing connections from older client.

Bitstreams significantly differ, but could be result of compilation of minor change.  Appears some midstate java code calls simplified.  Could be reason for larger bitstream, to move into fpga.  Midstate changes relate to signcryption and could be server affecting as well.

I am guessing based on simple analysis of available source code and eyeball + tools of bitstreams.

Elden blocked a huge group of miners from using his system because he claims we need a "TML Update"

His mining software says that you need to upgrade to the latest version of TML and it effectively knocked everyone's rigs offline (overnight for most of us I might ad) without any prior notice either on the forum or on his tricone-miners subscription news letter.

So since a lot of people have lost some significant mining time due to this complete act of irresponsibility

my team has done a full analysis of this update and here are their findings:

No Bugfixes found / changes appear to be insignificant

Actual Changes from TML 1.11 to 1.12:
* a bit of whitespace here and there
* changed the default bitstream name from kreisel to leibniz
* fixed a misspelled parameter name in the usage info screen
* changed a couple of copyright headers
* bumped the version number to 1.12

Current Known TML Bugs:
* MakeFile Bug -- still unfixed
* Clocking Bug -- still unfixed
* Bitstream Upload Bug -- still unfixed


I am sorry elden but if you want people to feel secure using a centralized proprietary system like this you really need to do things in a way to increase our confidence and surprising us in the middle of the night by inexplicably taking down our mining rigs for no apparent reason is not a good way to do that.




Hello,

  I'm running 2 mod miners and mine died about the same time.
I don't have remote access to them yet and I'm not in front of them so I have know Idea what the error is yet.
Just weird that mine died at roughly the same time as yours.


 

Hello,

I've been happily running on my x6500 until 10 min or so ago.

Now I'm getting:

[x6500:AH01ABH9:0.0]   new cipher state = 0x4a1ab2152fd629d276cd6299
             restarting blocked threads for com.triconemining.signcryption.SCClient$Connection@20d9896e
               finished restarting blocked threads for com.triconemining.signcryption.SCClient$Connection@20d9896e
             opening signcryption connection to limp.tricone-mining.com/23.23.249.133:7778
listener thread for limp.tricone-mining.com/184.82.49.28:7778 exiting due to java.io.IOException: please update your TML to the latest version.

I'm running tml.1.11 from the website and do not see a newer version... anyone else having this problem?

FYI I will have limited/unreliable internet and email access until Tuesday 02-Oct.

Elden,


Please review this at your earliest convenience.

https://bitcointalksearch.org/topic/500-btc-bounty-for-opensource-bitstream-that-is-faster-than-tml-still-open-112303

Thank you for all you do

Tom
BTCFPGA.com

Today i have time to test again.

You have to change the Device Identifier Code.
Cause My Spartan 6 have: Device IDCODE= 0x4401d093. That is the latest Revision that Xilinx delivers.

http://www.xilinx.com/support/documentation/user_guides/ug380.pdf page 80, the First 4 Bits Are Revision Codes.

My complete Commandline is:
java -Dbitstream=leibniz -Dclock_pin=csg484.W11 -Dclock_pin_freq=6.666 -jar tml.jar urjtag:flyswatter http://HelloWorld:[email protected]:8332

And this is the complete output:

_________________________________________________________________________
Tricone Mining Logic, host software v1.11

   IF YOU EXPERIENCE HIGH ERROR RATES: try running just one ring at a
   time (e.g. use 'ztex:0:0.0' on command line instead of 'ztex:0'). 
   If each ring works error free on its own, but you get errors when 
   running all three, it means your power supply is sagging.         

             adding work source gigaforge.com
             starting long poll thread
[flyswatter     ] found new board urjtag:flyswatter
[urjtag:flyswatter:0] found new chip
[urjtag:flyswatter:0] programming FPGA with bitstream leibniz
             USERCODE before bitstream upload: 0xcafebabe
             USERCODE after bitstream upload: 0xcafebabe
[urjtag:flyswatter:0]   done programming FPGA
[urjtag:flyswatter:0] magic number check ok 
[urjtag:flyswatter:0] chip is running bitstream version 0x50547e78, built 8d8h54m32s ago
[urjtag:flyswatter:0] chip has 3 rings       
[urjtag:flyswatter:0] assuming input clock frequency of 6 Mhz
[urjtag:flyswatter:0] asserting global reset
[urjtag:flyswatter:0.0] disabling DCM bypass mux
[urjtag:flyswatter:0.0] opening signcryption channel
[urjtag:flyswatter:0.0] setting clock to 149 Mhz, mult=45 div=2
H:0 X:0 E:0 T:10s   |  H:0 E:0 A:0 R:0 T:10s java.io.IOException: DCM did not report ready for programming
   at com.triconemining.miner.DCM.setClockFrequency(DCM.java:151)
   at com.triconemining.miner.DCM.setClockFrequency(DCM.java:62)
   at com.triconemining.miner.RingWrapper.setClockFrequency(RingWrapper.java:393)
   at com.triconemining.miner.ChipWrapper.enableRing(ChipWrapper.java:268)
   at com.triconemining.miner.ChipWrapper.enableRing(ChipWrapper.java:184)
   at com.triconemining.miner.BoardWrapper.run_(BoardWrapper.java:101)
   at com.triconemining.miner.BoardWrapper.run(BoardWrapper.java:73)
   at java.lang.Thread.run(Thread.java:722)


My Clock is generated from a Frequency Generator. I also tried with 5, 10 and 20 Mhz. always the same result.

Could you please post the complete command line you're using, with all arguments, and the complete log that's printed out?  It's hard to tell what's going on just from this one lone line.  However, I will tell you that this is the error message you get if the clock input to the chip isn't running, so you might want to double check that.

Cablepair is Tom, he's with Modminer.