 Show Posts
|
|
Pages: [1] 2 3 4 5 6 7 »
|
If anyone is interested, I finally found access to a 5080 and 5090 for speed testing. Looks like the 5080 is about 3,850 Mk/s and the 5090 is about 6,650 Mk/s Comparing to a 4090 at about 4,500 Mk/s its about a 47% increase in KeyHunt. I haven't tried other grid sizes, but both are only using about 50% of the VRAM with the auto grid. Start Time : Tue Feb 18 03:28:22 2025
Global range : 000000000000000000000000000000000000000000000000000000B1D37A781F (40 bit)
GPU : GPU #0 NVIDIA GeForce RTX 5090 (170x0 cores) Grid(1360x128)
[00:00:04] [GPU: 6683.80 Mk/s] [C: 3.50 %] [T: 26,738,688,000 (35 bit)] [Puzzle: 67] [Shares: 1365.47 ] [EST Payment: 0.007000 BTC] [Searched: 0.015941 %]
[00:00:06] [GPU: 6654.08 Mk/s] [C: 5.23 %] [T: 39,929,774,080 (36 bit)] [Puzzle: 67] [Shares: 1365.47 ] [EST Payment: 0.007000 BTC] [Searched: 0.015941 %]
Start Time : Tue Feb 18 03:53:11 2025
Global range : 000000000000000000000000000000000000000000000000000000631E19728C (39 bit)
GPU : GPU #0 NVIDIA GeForce RTX 5080 (84x0 cores) Grid(672x128)
[00:00:04] [GPU: 3875.17 Mk/s] [C: 3.64 %] [T: 15,502,147,584 (34 bit)] [Puzzle: 67] [Shares: 1303.03 ] [EST Payment: 0.006672 BTC] [Searched: 0.015960 %]
[00:00:06] [GPU: 3816.42 Mk/s] [C: 5.38 %] [T: 22,900,899,840 (35 bit)] [Puzzle: 67] [Shares: 1303.03 ] [EST Payment: 0.006672 BTC] [Searched: 0.015960 %]
|
|
|
|
is there no save feature for Keyhunt cuda? i've been searching for a couple of days now and unfortunately have found no save feature
No, this is pretty much the reason I decided to make a pool so that I could be sure that I wasn't wasting search power on the same keys over and over. |
|
|
|
I've been working on updating the website whenever I get a chance, and I'm excited to announce a new update to the client code! The client is now built to support CCAP version 10.0, which I anticipate will be fully compatible with the upcoming RTX 50 series upon release. Website: https://www.challengepool.net/ Join the discussion on Discord: https://discord.gg/ryD8tChjt7 |
|
|
|
KeyHunt can get about 4,500 Mk/s on a 4090 while checking for a match to 1 RIPEMD-160 hash value. GPU : GPU #4 NVIDIA GeForce RTX 4090 (128x0 cores) Grid(1024x128)
GPU : GPU #5 NVIDIA GeForce RTX 4090 (128x0 cores) Grid(1024x128)
GPU : GPU #1 NVIDIA GeForce RTX 4090 (128x0 cores) Grid(1024x128)
GPU : GPU #0 NVIDIA GeForce RTX 4090 (128x0 cores) Grid(1024x128)
GPU : GPU #2 NVIDIA GeForce RTX 4090 (128x0 cores) Grid(1024x128)
GPU : GPU #6 NVIDIA GeForce RTX 4090 (128x0 cores) Grid(1024x128)
GPU : GPU #7 NVIDIA GeForce RTX 4090 (128x0 cores) Grid(1024x128)
GPU : GPU #3 NVIDIA GeForce RTX 4090 (128x0 cores) Grid(1024x128)
[00:00:56] [GPU: 36298.09 Mk/s] [C: 103.91 %] [T: 2,047,088,787,456 (41 bit)] [Puzzle: 67] [Shares: 2443.00 ] [EST Payment: 0.096345 BTC] [Searched: 0.002267 %]
Start Time : Thu Jan 2 22:41:33 2025
Global range : 000000000000000000000000000000000000000000000000000001CAAD2673FF (41 bit)
|
|
|
|
I have put together a basic webpage to view the current pool stats as well as lookup your workers via the bitcoin address https://www.challengepool.net/ |
|
|
|
I am quite happy to share portions of the server code for external validation / improvements. The problems of the clients (all clients must be considered to be untrusted) I don't really have a bullet proof solution to the problems and am happy to explore options that other people might think of to make it less practical for a client to skim the private key from the pool. I am happy to add notifications to the workers if a solution is submitted, this is not a difficult thing to adjust in the programs. The pool checks the balance of the target puzzle address every couple of minutes to confirm that the prize is still in the account. It has not been implemented yet that if the balance goes to 0 that we shift to the next puzzle. We would do that if a valid solution was submitted to the pool. I have considered a number of different options of masking / encryption of the search block, however in the end the clients must run the address check with the actual private key hex or they will never return any correct solutions. In order for that to happen they need to be sent the information that is required to decrypt / unmask the value and are left with the raw hex anyway. If anyone has any techniques that they think would be assistance to this problem it would be worth exploring. There are a number of things that I would be more then happy to adjust / improve if there is sufficient interest in pursuing the pool. The share system right now is setup as a proportional share system, each client that completes 1 work increment (WORK_INCREMENT = 10,000,000,000 private keys) gets 1 share. The current calculation allocates shares to each puzzle independently so if puzzle 67 is solved, shares are logged for 67 and a new count starts for 68. I do see the merit in carrying over shares if the solution is found by a different party as it would still reward any workers for past work and only reset if the pool finds a solution. The logic for the 60 second work increment is so that it is easer to track progress / update searched ranges / return non responsive work back to the pool. The work is being distributed in a weighted random selection search method. The basis is that it will try and break up larger unsearched areas into smaller and smaller ranges. Once the ranges get to be smaller then the requested search size the pool will start returning the smaller ranges to close gaps between completed work. This process seemed to work well in testing with the easier puzzles. This is the function that does the work assignments, yes I am just using SQLite for the time being as I am the only client, this will be migrated to a different database if/when the need arise. def assign_random_range(puzzle_id, client_increment):
"""
Assigns a random range to the client, ensuring uniformly random selection
across the puzzle space for all "big-enough" ranges.
Steps:
1. Fetch all available ranges from the database.
2. Classify ranges into "big-enough" and "smaller."
3. If "big-enough" ranges exist:
- Perform weighted random selection based on range size.
- Assign a subrange of length `client_increment` and update the database.
4. Otherwise, assign the largest "smaller" range.
5. Return `None` if no suitable ranges are available.
Args:
puzzle_id (int): The ID of the puzzle to fetch ranges for.
client_increment (int): The size of the range to assign.
Returns:
tuple or None: Assigned range as (start, end) or None if no range is available.
"""
conn = None
def fetch_ranges(cursor, puzzle_id):
"""Retrieve and convert all available ranges for the given puzzle ID."""
cursor.execute('''
SELECT start_range, end_range
FROM available_work_ranges
WHERE puzzle_id = ?
''', (puzzle_id,))
return [
(int(start_hex, 16), int(end_hex, 16))
for (start_hex, end_hex) in cursor.fetchall()
]
def update_database(cursor, puzzle_id, chosen_start, chosen_end, assigned_start, assigned_end):
"""Remove the chosen range and reinsert remaining parts into the database."""
# Remove the old range
cursor.execute('''
DELETE FROM available_work_ranges
WHERE puzzle_id = ? AND start_range = ? AND end_range = ?
''', (puzzle_id, hex(chosen_start)[2:], hex(chosen_end)[2:]))
# Reinsert leftover front
if assigned_start > chosen_start:
cursor.execute('''
INSERT INTO available_work_ranges (puzzle_id, start_range, end_range)
VALUES (?, ?, ?)
''', (puzzle_id, hex(chosen_start)[2:], hex(assigned_start - 1)[2:]))
# Reinsert leftover back
if assigned_end < chosen_end:
cursor.execute('''
INSERT INTO available_work_ranges (puzzle_id, start_range, end_range)
VALUES (?, ?, ?)
''', (puzzle_id, hex(assigned_end + 1)[2:], hex(chosen_end)[2:]))
def weighted_random_pick(big_enough, client_increment):
"""Select a range weighted by size and assign a subrange."""
total_space = sum(rsize for (_, _, rsize) in big_enough)
pivot = random.randint(0, total_space - 1)
cumulative = 0
for (rstart, rend, rsize) in big_enough:
if pivot < cumulative + rsize:
max_start = rend - client_increment + 1
assigned_start = random.randint(rstart, max_start)
assigned_end = assigned_start + client_increment - 1
return rstart, rend, assigned_start, assigned_end
cumulative += rsize
try:
conn = get_db_connection()
cursor = conn.cursor()
# Step 1: Fetch all ranges
all_ranges = fetch_ranges(cursor, puzzle_id)
if not all_ranges:
logging.error(f"No available ranges for puzzle_id {puzzle_id}.")
return None
# Step 2: Classify ranges
big_enough, smaller = [], []
for rstart, rend in all_ranges:
size = rend - rstart + 1
(big_enough if size >= client_increment else smaller).append((rstart, rend, size))
# Step 3: Handle "big-enough" ranges
if big_enough:
chosen_start, chosen_end, assigned_start, assigned_end = weighted_random_pick(big_enough, client_increment)
update_database(cursor, puzzle_id, chosen_start, chosen_end, assigned_start, assigned_end)
conn.commit()
return assigned_start, assigned_end
# Step 4: Handle "smaller" ranges
if smaller:
smaller.sort(key=lambda x: x[1] - x[0], reverse=True)
sstart, send = smaller[0][:2]
cursor.execute('''
DELETE FROM available_work_ranges
WHERE puzzle_id = ? AND start_range = ? AND end_range = ?
''', (puzzle_id, hex(sstart)[2:], hex(send)[2:]))
conn.commit()
return sstart, send
# Step 5: No suitable ranges
logging.debug(f"No suitable range found for puzzle_id {puzzle_id}.")
return None
except Exception as e:
logging.error(f"Error assigning random range for puzzle_id {puzzle_id}: {e}")
if conn:
conn.rollback()
return None
finally:
if conn:
conn.close()
In regards to the solo vs pool, I cannot understand the logic of a solo pool that uses work from other workers? Its like saying I want to use the pool work but I get the full reward if I am the lucky one to find the key. A larger reward for the lucky person would make more sense if that was what people are looking for. |
|
|
|
If you are unaware of the Bitcoin Challenge Puzzles, there is a lot of information about it in this thread. https://bitcointalk.org/index.php?topic=1306983.0and some basic details here https://privatekeys.pw/puzzles/bitcoin-puzzle-txWhy are you calling it a "mining" pool? It is a pool but there is no mining, it is just solving a "puzzle" which is not "the Bitcoin Challenge" as you put it. This is just a puzzle or rather a brute forcing game.  I changed the name so it is more appropriate to the task Yes it is just the brute forcing game, and if we all sit and individually brute force the full range in the next 6,000 or so years one of us might get lucky and find it alone. |
|
|
|
Hello Everyone, I’ve been working on a public mining pool designed to help a community collaborate on solving some of the Bitcoin challenge puzzles. The goal is to make the pool as transparent as possible while taking steps to secure the private key from misuse if a miner finds the solution. Please keep in mind that due to this the client and server software will have to remain closed source as there is no way to get around the clients having to work with the physical private key hex values. I’ve built a working client/server package that distributes work to clients in a randomized manner from the current puzzle range. The server dynamically adjusts the assigned work so that each client completes its range in approximately 60 seconds, sends back the result, and receives its next random block of work. This ensures consistent and efficient participation across the pool. While the system is functional, I’d love to hear the community’s thoughts and suggestions on improving the security and functionality of the pool. This includes ways to enhance transparency, protect the private key, and build trust in the process. At the moment, I have not put together a web interface as I have been focusing on the core client and server software. However, the client software provides updates on the miner's stats, the estimated BTC payout if the solution were found now, and the total search range that the pool has completed. The client is a modified version of the KeyHunt software, as it was in a format that allowed for relatively easy modification to include the pool functions. The server code is written in Python, with persistent storage for the work ranges that have been completed, as well as client work and related data. If the pool does find the solution, the transaction will be generated to distribute the funds among the miners based on their share percentage and submitted via slipstream.mara.com. This is designed to reduce the risk of the transaction being broadcast to the full Bitcoin network mempool, as this could potentially result in the transaction being hijacked. I am looking for anyone who would be interested in providing feedback or willing to point any GPUs at the server to help continue working through bugs. Looking forward to your feedback! Client Output: GPU : GPU #0 NVIDIA GeForce RTX 3080 (68x128 cores) Grid(544x128)
[00:00:58] [GPU: 2101.64 Mk/s] [C: 102.44 %] [T: 122,926,661,632 (37 bit)] [Puzzle: 67] [Shares: 465.00 ] [EST Payment: 0.053736 BTC] [Searched: 0.000713 %]
Start Time : Thu Dec 26 10:53:31 2024
Global range : 0000000000000000000000000000000000000000000000000000001BF08EAFFF (37 bit)
GPU : GPU #0 NVIDIA GeForce RTX 3080 (68x128 cores) Grid(544x128)
[00:00:58] [GPU: 2113.36 Mk/s] [C: 102.68 %] [T: 123,211,874,304 (37 bit)] [Puzzle: 67] [Shares: 477.00 ] [EST Payment: 0.055123 BTC] [Searched: 0.000713 %]
Start Time : Thu Dec 26 10:54:31 2024
Global range : 0000000000000000000000000000000000000000000000000000001BF08EAFFF (37 bit)
Server Output: 2024-12-26 11:21:44,470 - INFO - Client 37CDsFQ4wN5xjAnuSe5CxvPbk7H2vhH2kv:3080-2 completed work range 791b4951faef50cb3-791b4953b9f83bcb2 in 60.97 seconds - 1968.08 Mk/s
2024-12-26 11:21:44,535 - INFO - Client 37CDsFQ4wN5xjAnuSe5CxvPbk7H2vhH2kv:3080-2 assigned work range 5f2f790baa55217bf-5f2f790d695e0c7be
2024-12-26 11:21:50,378 - INFO - Puzzle ID 67: 0.00071820 % of the range has been searched.
2024-12-26 11:22:18,809 - INFO - Updated balance for puzzle_id 67: 6.70010696 BTC
2024-12-26 11:22:45,455 - INFO - Client 37CDsFQ4wN5xjAnuSe5CxvPbk7H2vhH2kv:3080-2 completed work range 5f2f790baa55217bf-5f2f790d695e0c7be in 60.91 seconds - 1970.09 Mk/s
2024-12-26 11:22:45,529 - INFO - Client 37CDsFQ4wN5xjAnuSe5CxvPbk7H2vhH2kv:3080-2 assigned work range 578f6ad3304fbeab4-578f6ad4ef58a9ab3
2024-12-26 11:22:50,403 - INFO - Puzzle ID 67: 0.00071837 % of the range has been searched.
2024-12-26 11:23:19,363 - INFO - Updated balance for puzzle_id 67: 6.70010696 BTC
2024-12-26 11:23:46,582 - INFO - Client 37CDsFQ4wN5xjAnuSe5CxvPbk7H2vhH2kv:3080-2 completed work range 578f6ad3304fbeab4-578f6ad4ef58a9ab3 in 61.05 seconds - 1965.74 Mk/s
2024-12-26 11:23:46,660 - INFO - Client 37CDsFQ4wN5xjAnuSe5CxvPbk7H2vhH2kv:3080-2 assigned work range 4563b3389517d413c-4563b33a5420bf13b
2024-12-26 11:23:50,429 - INFO - Puzzle ID 67: 0.00071853 % of the range has been searched.
|
|
|
|
|
mod please delete this thread, I have moved it to a different section
|
|
|
|
I have only tested it with the CPU version as I do not have a GPU, but contributions are welcome.
Just some feedback, I have built and run the software with cuda 86. It does seem to run with the gpu but it does not find the match on the smaller challenges (50, 55, 60) the CPU seems to come back with the match reliably. 50 - SolveKeyCPU Thread 14: 1024 kangaroos
- Done: Total time 01s
55 - SolveKeyCPU Thread 13: 1024 kangaroos
- [65.43 MK/s][GPU 0.00 MK/s][Count 2^28.96][Dead 2][08s (Avg 06s)][282.3/321.7MB]
- Done: Total time 08s
60 - SolveKeyCPU Thread 09: 1024 kangaroos
- [61.55 MK/s][GPU 0.00 MK/s][Count 2^30.94][Dead 1][34s (Avg 25s)][1.1/1.2GB] MB]
- Done: Total time 36s
I will have a bit of a look around when I get some more time. |
|
|
|
|
The modern wallet currently supports the following coins;
SnowGem
BitcoinZ
Zcash
ZeroClassic
Zero
BZEdge
BitZec
Commercium
|
|
|
|
Hello Everyone, We have some great and exciting things to tell you about what is going on with SnowGem. As usual the developers have been working hard to make this project better everyday. To make your investment safer and more secure. Now your investment is protected by Thor's Hammer.  Thor´s Hammer 51% Attack Solution official Documentationhttps://snowgem.org/files/snowgem-thors-hammer.pdf Thor's Hammer is a first in the crypto world and it is to prevent the SnowGem network from a 51% attack using a masternode Proof-ofWork (mPoW) solution. Txid made a nice video showing a potential attack on a network and how Thor's Hammer can stop the attacker. https://www.youtube.com/watch?v=sdqw2rv8pzEAt this time the core team along with SnowGem pools and exchanges have all upgraded successfully to this new code. The upgrade is very fast and only takes a few minutes to do. This is a mandatory upgrade on all masternodes in the SnowGem network. For more information please read our full blog about the release. https://snowgem.org/blog/mpow-51-attack-solution |
|
|
|
There have been a number of recent 51% double spend attacks in the crypto space during the past months. That is why the SnowGem team proudly announces that we have just successfully finished testing of our revolutionary network protection solution aka Thor´s Hammer — masternode Proof of Work ( mPoW). In the coming days the security update will be released along with information about how we will be protecting the SnowGem blockchain.  This is also last mandatory update which will be done manually, because our Asgard system is now fully tested and will be released in the begining of February. All masternodes owners will be able to migrate to this platform. |
|
|
|
You can rent a VPS for $5 per month and host multiple Masternodes on it (only if they are from different coins in most cases). There are various services in the $8-10 range that will manage your Masternode for you too, although I'm not sure which ones support SnowGem specifically.
In my opinion, investing into Masternode is very risky, mainly because real ROI will be much different than estimated ROI at the time investors decide to invest into their interest masternode coins. I don't see how you can say that its very risky to invest into a Masternode. You can remove your funds at any time, there is no locked in contract or agreement and you always maintain control of your own collateral coins. You start receive payments within hours of setting up your Masternode. If you plan to hold coins for any period of time waiting for growth then Masternodes are just interest on your holdings. |
|
|
|
I have a question about the distribution of rewards for the block.
Reward 20 coins, miners 10, masternodes 9, development fund 1.
But I look there are payments for example: 9.6 +1 + 0.4 +9.
Or 9.84 +1 + 9 + 0.16.
But in some blocks this is not.
To whom is 0.4 or 0.16 for example?
To use this block for example;
https://insight.snowgem.org/block/0000021e06573313bf77d6d7292546d443e535abc448c5c0558e9958fb14ab2b9.84043089 XSG was paid to the pool to distribute to miners. 1 XSG was paid to the development fund. 9 XSG was paid to a masternode. 0.16 XSG was paid to the pool as the pool fee. Total is 20.00043089 XSG for the block. The 0.00043089 XSG are from the tx fees that people pay to send transactions to the network. Hope that answers your question. |
|
|
|
# server supports extranonce
# server set difficulty to: 0001fffe0000000000000000...
protocol version 040c0000 not supported
What's this error mean? I've tried zm versions 0.5.7, 0.5.8, and 0.6.1 - same error. Don't recall getting this before, but its been a few weeks since I've done any equihash mining.
Is DSTM broken?
me too, i just up^date to 6.1 but not helping, don't know what error it just close strange it works on gtx1060 but not on 1080 & ti edit; actually it was working with invalid job id on 1060 Are you mining the original Equihash coins (200,9) zcash, zen ect or the recently forked Equihash coins (144,5) snowgem, bitcoin gold etc? DTSM does not have a miner for the forked coins. You will have to look back to EWBF for that. |
|
|
|
Hi guys!
help please.
There is always Rejected share.
Pool does not see the rig.
Rig on other miners is working fine, there is no overclock.
You cannot mine zcash with this miner, it will only work with coins that have forked to 192,7, 144,5 and 96,5. If you want to mine zcash you will need to use the original miner as it still uses 200,9. |
|
|
|
|
