 Show Posts
|
|
Pages: [1]
|
https://realityripple.com/crypto_icons.htmlFeel free to use or modify them to your own needs. Remember that fonts are important and not universal. Don't worry about ownership, I'm a public-domain type of guy. ZCash is probably easiest to represent with ⓩ, ⓩ. If anyone wants me to CSS-ize a cryptocurrency, lemme know and I'll see what I can conjure up.
|
|
|
|
]I already did. They're in the final quote under the names il * G and m's ECpub respectively.
Can you print them in hex? The negative makes things slightly harder to check things. The X component of m's Pub is correct and iL * G is also correct. Yeah, so I have no idea what the standard is for converting negatives to hex is here. but it's whatever -7bd3305d363c26f82c1e41c667e4b3561c06c60a2104d2b548e6dd059056aa51 would be represented as, in any case.Ah, yes, it was my decompression of Y. I had my suspicions. You helped me narrow it down quite a bit, actually. Thank you for your assistance. |
|
|
|
Before you do the adding, can you print out what you get for Point::mul($il, $secp256k1_G) and Make sure that those are what you expect them to be. The only thing that can be wrong here is that either you are adding the wrong things or Point::add is broken. I already did. They're in the final quote under the names il * G and m's ECpub respectively. Also, Point::add and Point::mul are used in my recoverPubKey function for verifying signed messages, which I'm already sure works correctly for multiple coin types. However, I can't completely rule out the possibility of an issue, which is why I'd like verification on the numbers and the results, as you say. |
|
|
|
I'm working on a Public-key-only BIP32 script to track purchases on my website rather than having users sign messages to verify themselves as the purchaser, and I spent yesterday getting the code together for it. The primary extended public key (m) code is now fully functional, but deriving children is running into issues. I've been testing with TestVector 02 (xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8id oc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB), and have successfully generated this data with the key: Version: 488b21e
Depth: 00000000
Parent Fingerprint: 00000000
Child Index: 00000000
Chain Code: 60499f801b896d83179a4374aeb7822aaeaceaa0db1f85ee3e904c4defbd9689
Key: 03cbcaa9c98c877a26977d00825c956a238e8dddfbd322cce4f74b0b5bd6ace4a7
Key Hash: bd16bee53961a47d6ad888e29545434a89bdfe95
Key Str: 1JEoxevbLLG8cVqeoGKQiAwoWbNYSUyYjg
When I begin derivation of m/0, however, I get this far and then things end up wrong: Version: 488b21e
Depth: 00000001
Parent Fingerprint: bd16bee5
Child Index: 00000000
Chain Code: f0909affaa7ee7abe5dd4e100598d4dc53cd709d5a5c2cac40e7412f232f7c9c
####OH NOES BELOW####
Key: 02d83bc1ba1544900181dc0a68f70c7f35de329935252d6a8a69609f18613e57e2
Key Hash: 05bde101bb72a69c8cfe19e0700f66542b706d49
Key Str: 1XMqymHzMur3pkEXr29pr8ghZbJkNWPw4
Of course, m/0 should be 19EuDJdgfRkwCmRzbzVBHZWQG9QNWhftbZ, not 1XMqymHzMur3pkEXr29pr8ghZbJkNWPw4. In comparing with https://en.bitcoin.it/wiki/BIP_0032_TestVectors, I can verify that the Chain Code matches, so up to the SHA512 hash must be working correctly, however, the X/Y coordinates are completely wrong, resulting in the wrong key. The actual values for the left-side-of-I and the X/Y coordinates I'm ending up with are: iL: 60e3739cc2c3950b7c4d7f32cc503e13b996d0f7a45623d0a914e1efa7f811e0
X: d83bc1ba1544900181dc0a68f70c7f35de329935252d6a8a69609f18613e57e2
Y: 24f0d3bc9e646d0951df799e7e0691ac6a8ab228a62e2e76ff93c57886b4abfc
Since the chances of my iL being wrong are virtually impossible because the Chain Code is right, my best guess is my point math must be off. The code I'm using is: $k = Point::add(Point::mul($il, $secp256k1_G), $this->ECpub); where $il is a big-integer version of iL above, $secp256k1_G is the G Point, and $this->ECpub is the parent key's Point (decompression of Key's Bytes of course). Here's the function in its entirety: public function derive_child($i)
{
if (USE_EXT == 'GMP')
{
$secp256k1 = new CurveFp('0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F', '0', '7');
$secp256k1_G = new Point($secp256k1,
'0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798',
'0x483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8',
'0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141');
}
else
{
$secp256k1 = new CurveFp('115792089237316195423570985008687907853269984665640564039457584007908834671663', '0', '7');
$secp256k1_G = new Point($secp256k1,
'55066263022277343669578718895168534326250603453777594175500187360389116729240',
'32670510020758816978083085130507043184471273380659243275938904335757337482424',
'115792089237316195423570985008687907852837564279074904382605163141518161494337');
}
$data = self::pubKeyEnc($this->ECpub) . pack('N', $i);
$hash = hash_hmac('sha512', $data, $this->chain_code, true);
$il = BigInt::bin2big(substr($hash, 0, 32));
$ir = substr($hash, 32, 32);
$k = Point::add(Point::mul($il, $secp256k1_G), $this->ECpub);
$ret = new BIP32(null, $coin);
$ret->coin = $this->coin;
$ret->chain_code = $ir;
$ret->ECpub = $k;
$ret->child_index = $i;
$ret->parent_fingerprint = substr($this->ECpubKeyHash, 0, 4);
$ret->version = $this->version;
$ret->depth = $this->depth + 1;
$pubBinStr = self::pubKeyEnc($ret->ECpub);
$ret->ECpubKeyHash = self::encKeyHash($pubBinStr);
return $ret;
}
Points, CurveFPs, and all that good elliptical shit are handled via a stripped down version of Matyas Danter's phpecc, so I'm pretty sure the actual mathematics I'm calling are good there, but the outcome for $k is always ending up as d83bc1ba1544900181dc0a68f70c7f35de329935252d6a8a69609f18613e57e2 rather than fc9e5af0ac8d9b3cecfe2a888e2117ba3d089d8585886c9c826b6b22a98d12ea, and I can't figure out for the life of me why. For reference, the point I'm getting when multiplying iL and g is x=b661389998a7d5f191064dd13de77d6ecdc180660cd035c39e4242e4b2421b04, y=e4b7d21882264392ba68ab5a91fa6a7eb7794273e6887cbbcc367f0fc1a711be. I have no idea if this is correct or not, but I know that once I add the parent's public curve, it ends up being completely wrong. So, please, if anyone could have a working implementation spit out the points for iL * g, the parent key, and k, I'd like to know where I'm going wrong.My own results, in decimal, are as follows: m's ECpub: 92177583198369651078012650237376329809196622616143640907636115035502672667815, -56007618903221299795442838537477169399092506140195394231153621809959624157777
il * G: 82492713246181758252564353521594198071070516838199040858840666892200560433924, 103452112517317065707525904845368455724160088879315742877692289659877619863998
k: 97805156324642238343967192827814613794937570537923054831382185035481516759010, 16708767198174203366132415676330364127973636681074638317164427780658514144252 The negative y on the parent's ECpub sorta makes me anxious, but the key output is right for "m", so it must be correct, yes? |
|
|
|
|
Removed the old Pool.Gold and replaced it with the new one.
Adding daily changes (reflecting price shifts) to let you know how much you made (or potentially lost depending on price shifts) since midnight. Uses Pacific at the moment, but working on auto-adjustment depending on last login IP (IP won't be stored, just used to determine time zone, which will be stored).
|
|
|
|
|
Adding support for the new Pool.Gold system as it's being developed.
|
|
|
|
Not sure this project will be helpful to anyone, but I've created a little webpage for keeping track of multiple pools simultaneously with minimal data. Basically just an activity indicator, speed, and earnings in a quick list; something that can be checked quickly on a phone or whatever without having to wait around or load lots of pages and lots of data you don't need. I've added the pools I use and a couple other pools here and there, and the system seems to be functional enough to be put out there, so I thought this would be the place to say something about it. I call it MinerState. Please note that this project was conceived and written yesterday. It's still in extremely early stages, but if you want to try it out, you can find it at https://realityripple.com/Tools/MinerState/. At present, it supports ViaBTC, 2Miners, NanoPool, ethermine, Pool.Gold, BTGpool.pro and NiceHash. I'd love to add support for other pools, so long as they have some kind of API (preferably JSON, of course). Right now, since there doesn't seem much point in any real security for a read-only system, all you need to register is a Username. No password, no E-Mail, no private info of any sort. The stored Username's even hashed, because why the hell not, right? Accounts that haven't been checked in 60 days will be removed from the system automatically. If you decide to try it out, after you create your account, you'll be prompted to add your Pool data through a fairly simple interface. Some helpful information about what is requested will also be displayed. I'm assuming most the people on this site won't need any help. All that's usually required is the Wallet Address for your pool account. Some of the Mixed Currencies pools may require you to choose a coin type as well. ViaBTC needs an API Key, which is unfortunate, but easier than adding different wallets and coin types to include all the pool data. Once you add your info, it may take up to two minutes for the cron job on my server to grab your statistics, so please be patient there. I was thinking of loading the info through the page, but that could cause errors or slow-downs with the page load, so I figured "keep it asynchronous". There's also a currency option which currently lets you display your earnings in either USD or BTC. If anyone wants me to add support for other currencies, I should be able to include them pretty easily. Of course, I'm using CryptoCompare for all that, with exchange rates updated twice an hour. At present, the system updates every two minutes, more or less, but I will be altering that to prioritize accounts that have been viewed recently, and scaling depending on the number of users I end up with. The total speed on each pool can be found by moving the mouse over the little activity icon. At present, I do not display individual worker information, completed payouts, or notifications, and the page doesn't do any AJAX-style updating. I may eventually add live updating, but the other stuff is sort of beside the point for this project. However, if anyone has any particularly good suggestions that are also fairly minimal, I'd love to hear them. Oh, and if anyone's curious, the icon is supposed to be a canary in a cage. |
|
|
|
|
Running into some zombification as of last night. Tweaking frequencies and the voltage dial to see what's up, but for now it seems happier at 150 MHz than 175. Also, it apparently doesn't like a voltage much higher than what it was set to originally, but I did get it to 200 MHz for a brief period. I think it also might no longer like the USB 3 extension cable I'd been using, but for that, I need to do some difficulty adjustment tests, since I'm not sure if it stopped mining or timed out finding shares in that instance.
Still, I'm impressed with the device's ability to recover. It's nice working with something that's volatile-memory-only again.
|
|
|
|
I want to get ten but im trying to understand the baseline can you guestimate the hash power against stock would you say they are 70% 80% 50% efficient ? considering not only clock speed but hw error %?
The only rejected hashes I get are due to ping response because of my internet connection; no hardware errors in the last three days here. No idea on higher-voltage, higher-frequency settings, but between 100-200 MHz, I'd say they're at least 90% against stock. Running ten of them, you should be able to get up over 200 GH/s without altering voltage on any of them, long as you cool 'em down a bit. The one little 80mm fan in my photos above is enough to keep the one I got at literal room temperature, cool enough to touch. Absolutely no idea what happens closer to their limits, though. |
|
|
|
Ok, just so i understand i believe these seconds have HW errors at stock speeds (pot at 2 oclock and 100mhz) but work with no errors at overclocked speeds like 200 to 250?
The speed isn't the issue, it's the voltage. It just requires a little extra oomph to function as expected, but increasing the voltage does not inherently increase the speed on these little guys. |
|
|
|
Received my order yesterday, fiddled with it all evening and ran it all night through a USB 3 power-compatible extension cord. Performs wonderfully at stock 100MHz, around the expected 10+ GH/s. Made about a thousand "cashatoshi" running it overnight. Today, I started messing around even more, pushed the frequency up and added a fan through my case.  Just used a drive tray from the front with a spare fan lead and an old 80mm, testing the temp with an ir temp monitor, can't believe how quickly it cools... Went from around to 180° F when running at 140MHz+ to just over 100° at 175MHz. Happy there 'cause I'm getting a decent 20 GH/s from it. The case even closes nicely, as you can see.   It's very entertaining to mess around with, and I haven't even touched the voltage regulator. Gotta say, being on solar without a grid connection, this low-wattage toy is fantastic. It does stop responding now and then if you push it too hard, but it seems to be fairly resilient, especially for second-tier stock. Very happy with my purchase; all the best regards to your friend. |
|
|
|
|
