Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Does anyone know if there is a way to force the client miner to only use nodes listed in protoshares.conf?
Does USE_UPNP=- do that?
The idea being that, in the interim, use only peers known to be on the correct chain.
not yet it seems. this run was longer than before so we are on the right track. the issue is rouge peers, if you run it while connecting to functional clients that are on the right fork it seems to work.ok, it's been more than thirty minutes since arubi tried what i asked him to do, since then it has been more than twenty minutes without it crashing. I'll wait an additional 30 minutes for a response from hm again, but i am sure this temporary fix has resolved the issue of crashing. however, i need bytemaster to also confirm this, then we can implement the patch quickly.
good job! (+ 1BTC bounty?)
As many of you know Keyhotee will have a wallet interface. I would like a developer to build the initial version of this interface with the following requirements:
1) Interfaces to bitcoind (or any compatible alt-coin)
2) Uses public/private keys from Keyhotee Profile Hierarchical wallets (I have already implemented the key generation)
3) Displays a list of all transactions & Balance
4) Allows the creation of new transactions for sending coins to a Keyhotee ID
I estimate that it would take me about 2 weeks full time dedicated to the effort to create the basic interface.
The winner of this bounty also gets credit of $5000 toward their Keyhotee ID.
unable to connect....
why?
help me ~~~~~
You could read the past couple of posts.... and know exactly why.
************** ATTENTION *******************perhaps you should address those of us who are still having problems with your supplied miner before jumping into a new fork, seems rather discriminatory that others are mining just fine, but the rest of us with issues are just left out to dry. win64 users have been mentioning the 0x0000 problem and the msvcp issue all to no avail.
We are preparing a hard fork that would allow the difficulty to increase by 32x every 4032 blocks. This is the fork that will be honored by Invictus Innovations as the foundation of future block chains.
We will post new Windows and Mac binaries within the next several hours, hopefully before the next difficulty adjustment.
Those in my pool will automatically be updated to join the new fork.
I believe that there is enough hash power and market forces to support such a fork.
If there are any solid objections, speak now.
I'm happy to report that it works like a charm.
I've updated the source code.
Feel free to test it for yourself.
It correctly finds nonce collisions and follows all the predictions made in my earlier post.
I've conclusively demonstrated that memory requirements can be scaled arbitrarily while retaining an equivalent memory-to-computation ratio. Latency has been made a non-issue due to immediate return on collision detection and external thread termination.
Here's a snippet of what the output looks like using CHAIN_LENGTH = 4:
Step 31 of 128...
HITS: 743672
MISS: 1353480
TOTAL: 1966081
PCT: 35
Step 32 of 128...
HITS: 760208
MISS: 1336944
TOTAL: 2031617
PCT: 36
RAINBOW HIT
SEEK HASH: 423473256423089
ORIG NONCE: 28524699
RAIN NONCE: 5439512 + 1
0: 203104387400228
1: 423473256423089
2: 1041792957055939
3: 780112116212973
4: 629783454762940
5: 675829228796259
6: 738539531672861
7: 577969205224283
NAILED IT! Nonce: 28524696 + 3
0: 959239184726270
1: 186912846539772
2: 633556876464486
3: 423473256423089
4: 553069074389047
5: 746169572180730
6: 539623141106693
7: 588368479534609
Checking Work:
Nonce A: 5439513
Nonce B: 28524699
Hash A: 423473256423089
Hash B: 423473256423089
And the view from the outside: http://i.imgur.com/rMUKK5t.png
530 connections
Paying out 300 PTS / hour right now.
