Show Posts
|
Pages: [1]
|
It already is a standard API - that I wrote. All the large vendors use the equivalent of my API code (or my actual API code) in their miners. The differences are Bitmain who broke compatibility by changing the field names and scale for hash rates and changing the data format for LST but the interface is my code even in the Bitmain miners.
It's a great API! And now there's an HTTP REST wrapper for it.
|
|
|
I have written a RESTful API wrapper for cgminer in Rust: https://github.com/brndnmtthws/cgminer-restPlease check it out and provide any feedback you might have on GitHub. My goal (someday) is to get ASIC/miner vendors to standardize around an API to make it easier to build high quality tooling for managing miners. Cheers!
|
|
|
I didn't get a reply to my question earlier, so I posted an issue here: https://github.com/braiins/braiins-os/issues/6If anyone else wants to see high quality free and open source management tooling for braiins, please jump on board
|
|
|
You can always grab the source off GitHub if you're worried about it. And strictly speaking, this problem exists with all software distribution, not just npm or pypi packages Unless you audit the source code and compile it yourself, there's no way to be 100% certain the code isn't compromised in some way, even if the binaries/packages themselves are signed. You can compile Linux from scratch if you want, but it takes a while: http://www.linuxfromscratch.org/ (oh and some hardware these days requires binary firmware blobs without any source code, such as wireless drivers)
|
|
|
You can take it one step further and convert both one-time pad and the resulting ciphertext into the same mnemonic format as the original seed. This will allow users to enjoy the benefits of mnemonic format - ability to memorize it, being easy to write down on paper and easy to transfer from paper back to computer.
That's a cool idea, I hadn't thought of that. It's definitely possible! The only downside I can think of is that if you forget which is the key and which is the seed it might take a few attempts to figure it out. I suppose that's a reasonable trade off since you normally wouldn't have to restore from a backup very frequently. It actually wouldn't make any difference, since decryption is just addition modulo 2048 and both parts are of the same length, so ciphertext + key and key + ciphertext both yield the plaintext. Also, the cool side effect is that you can use both the key and the ciphertext as some sort of decoy wallets. Providing you have copies and backups, you can give them up to physical attackers to lose only a fraction of your coins. That's true, but it also depends on how you encode the values. I'm not sure it would work as decoy keys, because there is actually a checksum built into the BIP39. When you run the keys through the OTP it breaks the checksum. Unless you have a wallet that ignores the checksum, the words wouldn't work as a proper key (or at least, it's extremely unlikely they would work).
|
|
|
You can take it one step further and convert both one-time pad and the resulting ciphertext into the same mnemonic format as the original seed. This will allow users to enjoy the benefits of mnemonic format - ability to memorize it, being easy to write down on paper and easy to transfer from paper back to computer.
That's a cool idea, I hadn't thought of that. It's definitely possible! The only downside I can think of is that if you forget which is the key and which is the seed it might take a few attempts to figure it out. I suppose that's a reasonable trade off since you normally wouldn't have to restore from a backup very frequently.
|
|
|
Interesting idea, even though BIP39 already have optional encryption. But IMO this only change the problem since you need to keep your OTP secure. If i were to use your software, i'd encrypt the OTP with my own passphrase that i could remember and store it together with encrypted words. Your readme.md is very neat BTW I posted this in an old thread, but the post got deleted. I guess the mods didn't appreciate me digging up on old thread . It's against forum rules, unless there's good reason to do it. I don't think any of the wallet vendors implement the encryption part, AFAIK. But yes, you would have to store the key somewhere. You could actually write it down on paper as well, but that defeats the purpose. The point is to store the key and the seed differently, making it rather difficult to get both (or infer any information about the other).
|
|
|
I posted this in an old thread, but the post got deleted. I guess the mods didn't appreciate me digging up on old thread . Anyway, I created a Python tool for using a one-time pad for seed phrase storage: https://github.com/brndnmtthws/seed-otpThere's a fairly detailed discussion of the pros/cons of using this on the github readme. I hope someone finds it useful!
|
|
|
So, what free open source monitoring software can be used with this version?
None AFAIK, but I'd be happy to add support to my project if they're willing to work with me
|
|
|
It would be sweet if you also added a decent REST API. I'd like to add support to my management tool: https://github.com/brndnmtthws/mother-of-dragonsI can't find any documentation about your API, so from what I can tell the only thing available is what cgminer ships with. One thing that's great about the T1 (and Innosilicon miners) is that it has a reasonable REST API.
|
|
|
Yes I am in the US. Is this a known issue that you've seen before? Also, I wasn't clear in my last post but this is happening on every T1 that i've tried from my order, which is 4 so far. I have 6 others that I haven't unboxed yet.
I've found the update process to be quite unreliable as well when using the Web UI, but I have had good success with the Python tool I wrote: http://github.com/brndnmtthws/mother-of-dragonsYou can also use the REST API directly if you prefer, it works well as long as you use the file upload method (as opposed to the confusingly named 'download' method): https://github.com/brndnmtthws/dragon-rest
|
|
|
|