 Show Posts
|
|
Pages: [1] 2 »
|
Love it... Definitely a great set of new features in this wallet... it will take a while to find them all. There's bound to be some great articles on SilkCoin to follow. @Wulfcastle - Sent you a PM on MySilkcoin.comThis download is full of crap. silk-coin-qt109.zip takes you to some lousy Media Fire based download manager, which chrome objects to and if you ignore that proceeds to install a bunch of bloatware on your browser, and when all is said and done there's still no Silk coin wallet. Have you guys lost your minds? How about an FTP site instead, then we can skip all the browser tricks? Sincerely. |
|
|
|
|
Any chance I can try it out on my Sony Vaio laptop? I used to click 60 MH/s mining BTC with it in the good old days,
I'd give the software a run for posterity and report the results here.
|
|
|
|
|
I have a Mexican Cinco (5) Peso coin from 1948, in good condition, could be polished up but It's been in a plastic folder when I bought it on the beach in mexico sometime in the 90's.
Anyone know what that might be worth?
Thanks in advance!
rassalas
|
|
|
|
I actually did it. What happened was that several hours after I had started the miner I found the 7-chain/h number reported by the last new-block message shown in the console to be 6.8, which was much higher that normal. Then I noticed that only 2 (two) 7-chains have been found. I expected much more. I pressed s and saw there have been 2 hours 43 minutes since the miner had been started. I looked at the block number in the last new-block message and found the block number was more than 100 behind the latest block found on ypool. That definitely proved that the miner had been stuck for a long time. And the 6.8 7c/h with 2 chains found means the miner found the last block at 60/6.8*2 =~ 20min . The log showed two 7 chains. The miner usually find about 40 6-chains and 4 7-chains when everything worked. hope this helps.
I am seeing something like this too, After long times connected, in my case ~ 4days 7hours, I see the last block reported being 361823 yet Ypool is reporting data from 362213. The CPU is humming along at 100% If I turn SPS messaging on I get a steadily declining values per hour the pps and SPS seem to fluctuate, the ACC also seem to fluctuate between 836 and 854, And NPS also appears random I don't get any new blocks reporting being found, no disconnection message. I've been watching it like 40 minutes now. I've tried one diagnostic test, I manually disconnected my wireless connection the miner doesn't seem to notice. I reconnect, the miner doesn't seem to notice that either. This isn't the first time I've seen this happen, more like the third time, I've been using JHprimeminer-T17 for a few weeks now. Thanks for any interest, or solutions. |
|
|
|
PS still, out of curiosity, 0.1 btc bounty to whomever can provably link this move to an identity of the mover.
I'll throw .1 BTC in to identity verification bounty too. |
|
|
|
|
Any more of these left? I need 8 to complete a 16 chip board.
Let me know.
|
|
|
|
This is the postmortems and obituary over namecoin. In fact it never really existed, but by block: 139872 it became clear. However, if you haven' t noticed yet read on... Namecoin has always been my favorite alt-coin - it had a clear purpose, different from Bitcoin, offering a nice way to keep a de-central registry of key-value pairs. About a month ago I had a closer look at namecoin, to integrate it into libcoin. Libcoin is a complete other story, it is a library supporting bitcoin as well as several of the alt coins, enabling easy construction of anything from light weight wallets to full server wallet solutions for exchanges and merchant sites. However, back to namecoin... I have integrated several alt coins, and I know the machinery pretty well by now. The engine of any bitcoin based crypto currency is the ConnectBlock / ConnectInputs methods in main.cpp. They keep the rules of when to accept a block and when to reject a block, and it is there you make patches to enable anything from alternative hashing algorithms (litecoin) to merged mining (namecoin and others) as well as add new features and rules. Namecoin keep a reasonable separation through the definitions of hooks, implementing the actual rules in a separate file, namecoin.cpp. So the real interesting stuff in namecoin is happening in namecoin.cpp in the ConnectInputs method. This one is called from ConnectInputs in main.cpp and hence have the ability to change and add rules. All namecoin rules are kept hidden from the bitcoin script rule engine through OP_DROP opcodes, i.e. some special opcodes and data is entered, followed by a matching chain of OP_DROP commands, so the normal script rule engine will simply ignore anything namecoin'ish. The special op codes of namecoin are: OP_NAME_NEW
OP_NAME_FIRSTUPDATE
OP_NAME_UPDATE The reason for the OP_NAME_NEW/OP_NAME_FIRSTUPDATE setup is to avoid domain opportunists listening for new domain reservations and issuing competing reservations to later sell the domain back. So first you issue a: OP_NAME_NEW << hash << OP_2DROP Where the hash is composed of a random number and the domain, hashed. You are not allowed to issue a first-update, finally registering the domain, before after 12 blocks, ensuring no block reorganizations can enable a domain opportunists to steal your domain. In the name_new/name_firstupdate RPC calls this rule is nicely enforced, however, when you look in the ConnectInputs method you find rules enforcing a fee, rules enforcing the 12 blocks, but NO RULES ENFORCING THE HASH! [namecoin.cpp line 1874-1907] ]. So any name_new can be used as input for ANY name. This means that the domain reservation is not enforced at all leaving namecoin completely open for domain opportunists. Clearly the patient is bleeding and in urgent need for help, but brace yourselves, this is not affecting already registered domains so it is fixable by a proper patch, and a recommendation to not reserve any new domains before the patch is in effect. Relieved that there was a cure I continued with the standard examination, to check if the rest was ok. The key lines in namecoin.cpp are probably 1930 to 1949, this is the very core of namecoin. This is the enforcing of a name_update - a name update is the script: OP_NAME_UPDATE << vchName << vchValue << OP_2DROP << OP_DROP So, take an already registered name and update that with a new value. Now you would expect some code enforcing that only an input of that name can be update to another value - but NO! Again there is no enforcing of the core ruleset. So you can in fact update the value of any name in namecoin by any other input name. And after that you own it, or well, as much as you can actually own a name who anyone can update. The final test was to try it out - (sorry) - I might had overlooked something, so, I changed the name_update algorithm to enable such takeovers, and did a: ./namecoind name_fakeupdate d/postmortem d/bitcoin "Namecoin died October the 15th 2013, coinslayer" Try name_history on d/bitcoin and see for yourselves - there is no enforced integrity of the key value pairs in namecoin. So namecoin looses its entire purpose. The problem is that there is no fix to this - it is similar to being able to randomly take ownership of other peoples money, all the value is gone. I tried, initially, a silent fix contacting namecoin developers and key users more than a month ago, but I never got any answers back. Perhaps, the best future for namecoin now is a rebirth with a new genesis, or just a cancel of all the name reservations starting from some future block ? I should also note that up until block 139872, no one have exploited the bugs. The libcoin code actually enforced the above rules, and I was able to download and verify the entire chain, now I have added a flag, ignore_rules, to get pass block 139872. CoinslayerSo while everyone is busy, selling all their namecoins on this rumour, has anyone bothered to fact check this? I would like to have independant verification that what he's writing is true. |
|
|
|
|
Where's my refund?
I was told it was queued. that was a few weeks ago.
I tried to register on the website, but it wouldn't accept my name.
If they're not going to refund me where are my chips?
|
|
|
|
|
What's new here? I made it into batch 6, Still hopeful...
|
|
|
|
Looks to have been fixed, just now.
Yay! |
|
|
|
Am hating to bring this up, but is seeming to be a problem again:
18474 2013-06-08 20:06:47 1:10:33 13092667 1625 0.00000000 240455 25.05091001
Agreed 18474 2013-06-08 20:06:47 1:10:33 13092667 578 0.00000000 240455 25.05091001 89 confirmations left |
|
|
|
I have a burning question, I've sifted through the Github docs, but am having a hard time figuring out what cad software was used to create the pcbdoc and the Schdoc files. I'm assuming the BOM files were also generated by the same Cad program. Anyone know? Rassalas Altium Designer. They do have a free viewer for Windows on their web site. No Linux sadly. I don't think Altium is what was used. We can't seem to load the SCHDOC nor the PCBDOC files with Altium designer. If I'm wrong, please do elaborate. Thank you I stand corrected. We got them loaded. looking nice. |
|
|
|
I have a burning question, I've sifted through the Github docs, but am having a hard time figuring out what cad software was used to create the pcbdoc and the Schdoc files. I'm assuming the BOM files were also generated by the same Cad program. Anyone know? Rassalas Altium Designer. They do have a free viewer for Windows on their web site. No Linux sadly. I don't think Altium is what was used. We can't seem to load the SCHDOC nor the PCBDOC files with Altium designer. If I'm wrong, please do elaborate. Thank you |
|
|
|
Out of curiosity - is your hashing speed around 3.5-3.6GH/s?
I'm only running about 2.7GH/s hardware can probably hit closer to 3GH/s but I have cooling issues that need to be resolved. maths not my strongsuit.... kudos nottm28 Entering new workers with same credentials at the alternate serve did the trick. I did have to experiment with syntax to get valid credential submission, my poor memory or confusion with other pool standards... not important once I sorted it out Stratum server is working fine. I do have one annoying factor, Stratum is 4 characters longer then api so now my old worker names are too long to display well in a cgminer terminal that is each pool takes two lines, for my current name.wrkr. I could rename but last time I did that I lost some shares. |
|
|
|
Same here, I've got one machine already mining but the other which was stopped (so my daughter can play the Sims) can't start mining now but works with other pools.
CGMiner can't find work, GUIMiner says no JSON object could be decoded yet the other machine which has been running all day continues to mine.
I'm having similar problems one machine, Laptop, which gets stopped and restarted often can't connect to slush today, but can other pools. Other two miners on different machines are humming along no problem. Even tried to create a new worker and it won't json authorize or somesuch language... I got my machine using GUIMiner to log in by changing the settings. Instead of using the preset url settings for Slush's Pool(which is http://api.bitcoin.cz:8332) I changed it 'other' and gave it the host name 'stratum.bitcoin.cz' and port 3333, then it found work and started as soon as I ran it. I used the alternate host and port on the new miner I created, that one can't log in.. maybe I should recheck my typing. |
|
|
|
Same here, I've got one machine already mining but the other which was stopped (so my daughter can play the Sims) can't start mining now but works with other pools.
CGMiner can't find work, GUIMiner says no JSON object could be decoded yet the other machine which has been running all day continues to mine.
I'm having similar problems one machine, Laptop, which gets stopped and restarted often can't connect to slush today, but can other pools. Other two miners on different machines are humming along no problem. Even tried to create a new worker and it won't json authorize or somesuch language... |
|
|
|
I have a burning question, I've sifted through the Github docs, but am having a hard time figuring out what cad software was used to create the pcbdoc and the Schdoc files. I'm assuming the BOM files were also generated by the same Cad program. Anyone know? Rassalas |
|
|
|
Hmm, more weirdness. Account page says 724 MH/s, constant shares going out (last update at 0) every time I look, yet instead of the normal 0.0017-0.002 that I get per block, it's 0.00000082. I'm sure it'll be taken care of, but it's weird that these problems have been cropping up over the recent past and not before
Agreed, 18084 2013-05-18 10:21:35 1:29:33 12254159 509 0.00000031 none 236736 25.29456603 83 confirmations left I have also noticed twice in last couple days, even though I'm using cgminer 3.1.0 sometimes a certain miner will get flagged as not Stratum. maybe there's two things fishy, maybe it's the same thing. Is Slush still mum on the strange rounds? |
|
|
|
It might work, I'd rather design my own, and make sure there's thermal contact to the back surface. for a first pass testing rig it could work. The problem in my view is the definitive data sheet for the die will likely not be finalized until someone gets a few chips fab'd and can test them on a bench. So having a few of these ready on hand could be useful. for quick breadboarding. |
|
|
|
+1 on the weirdness above, I'm below for that block
17925 2013-05-08 14:13:44 1:27:14 11634278 558 0.00000013 235160 25.21733124 91 left
Me three, 17926 also looks slightly fishy to me. 17926 2013-05-08 16:05:44 1:52:00 15071549 641 0.00043981 235165 25.59585000 89 confirmations left 17925 2013-05-08 14:13:44 1:27:14 11634278 488 0.00000013 235160 25.21733124 84 confirmations left |
|
|
|
|
