Hi everybody,

is anyone aware of a KeyHunt-Cuda version that supports p2sh and bech32 addresses as well? Any hints appreciated.

Thanks.

[0.16381090]

Hello all. I am puzzled about the information showed on blockcypher.com and can not explain it at the moment. For example, it is about the following Bitcoin address 1BFhrfTTZP3Nw4BNy4eX4KFLsn9ZeijcMm

On the most diverse block explorers like mempool.space or blockchair.com or blockchain.com  I see following information for this address:

Total transactions: 173
Total received: 0.16381090 BTC
Total sent: 0.16381090 BTC

However block explorer blockcypher.com outputs for that address a fewer amount of total received/sent amount
https://live.blockcypher.com/btc/address/1BFhrfTTZP3Nw4BNy4eX4KFLsn9ZeijcMm

Total received: 0.1474109 BTC
Total sent: 0.1474109 BTC

Why? All explorers show the correct total transactions of 173 though. How can the mismatch be explained? So far, blockcypher seems not outputting correct information.

I must add that the API service of this page could be used for several Bitcoin tools available out there, and these tools might therefore output incorrect or incomplete information. One example is the python library pycoin.

[BIG THANKS to @mikeywith]

Hello all,

The following post grew out of a discussion of another post. There the user akaki had criticized that in solomining one cannot simply multiply the calculated probability of a block hit per block average time of 10min with any desired time frame that would result in the probability e.g. for 1h, or a day, or a year. The user mikeywith has thankfully countered with very informative posts and explained the opposite. Since I wanted to dedicate myself to this topic intensively and learn more, I made a learning project out of it and wrote a Python program in parallel, which I constantly extended. This way I could try out different approaches and implement my learning into a working program right away.

At this point again a BIG THANKS to @mikeywith, who has really animated me to do this and has helped with his valuable explanations on.

I had already recommended the moderators to move the corresponding posts #46 - #56 to a new thread here in the technical forum, since this has become off-topic after all, but the mods probably haven't seen or wanted to implement that yet. I think it is appropriate to move the discussion here on technica part of the forum so that it is clear to everyone what it was actually about and on this way more information and a good discussion could follow.

All this resulted in the following python tool which I have uploaded to my repository [1] and would like to share with interested parties. I would like to add that I'm a complete Python beginner and still taking the first steps, so bear with me and correct me if you find any gross errors. I am also open to recommendations or constructive advice and will try to implement them in my free time. The goal is to learn and continue to have fun.

The "Solomining Probability Calculator" is a tool designed to assist solo miners in understanding their chances of successfully mining a block on the Bitcoin network. The program takes the user's hash rate as input, supporting various formats for ease of use. It also retrieves the current Bitcoin network difficulty which is then used to calculate a range of important mining metrics. These include the ratio of all hashes over the valid hashes, the probability of each single hash attempt, expected time to mine a block and the probability of successfully mining a block for various time frames. Additionally, the program offers helpful analogy and phrases to provide a better human-understanding of the probabilities, making it easier for users to interpret the results. With this tool, solo miners can gain valuable insights into their mining operations and make more informed decisions. Overall, the solomining probability calculator is a valuable tool for any solo miner looking to increase their chances of success in the competitive world of cryptocurrency mining.

If you like it and are interested, I could imagine to move the function to a website. This is because I have found that the solochance.com website that I am familiar with does not include current Difficulty values, and thus the calculations are not accurate when I compare them to others and my own calculations. I may be wrong, but I suspect that the relevant values like "difficulty" or "nbits" are not kept up to date there or may be manually entered by the operator from time to time. That would explain the deviation. For this reason, I was thinking about using my existing Python program as a basic framework to create a website with that functionality and output. I think I would have to rewrite that in JavaScript, which would be again (almost) new territory for me but if there is great interest then I would tackle that. Just let me know.

Have fun and a nice weekend.
citb0in

[1] https://github.com/citb0in/solomining_probability_calc

[ecdsa_sign_recoverable]

Hello all. I am referring to secp256k1 library in Python where you can signrec a message.
Following example:

privkey = '0000000000000000000000000000000000000000000000000000000000000001'
message = 'Hello, world!'

after signing it will produce the signature

b85d62928d63583f52b14995c9444a92e1b7998a3fcfd0c134f327d61b162c6e7ea40adb783bd4c 00f9cfdb829c7e7d5b8d8e25a797d8548aec6f41df461fab9

I am digging into the code and like to understand what the process looks in detail. I am stuck on the last point and hopefully someone can shed some light onto...

The signrec command line argument calls the function ecdsa_sign_recoverable

Code:

[...]
    elif args.action == 'signrec':
        priv, sig = sign('ecdsa_sign_recoverable', args)
[...]

the message is hashed one time through sha256 and stored into the variable name msg32. The sha256 from the message shown is

315f5bdb76d078c43b8ac0064e4a0164612b1fce77c869345bfc94c75894edd3

Code:

[...]
    def ecdsa_sign_recoverable(self, msg, raw=False, digest=hashlib.sha256):
        if not HAS_RECOVERABLE:
            raise Exception("secp256k1_recovery not enabled")

        msg32 = _hash32(msg, raw, digest)
[...]

So far so good and understood. But on the next step the raw_sig variable is created by calling ffi.new('secp256k1_ecdsa_recoverable_signature *')

Code:

[...]
        raw_sig = ffi.new('secp256k1_ecdsa_recoverable_signature *')

        signed = lib.secp256k1_ecdsa_sign_recoverable(
            secp256k1_ctx, raw_sig, msg32, self.private_key,
            ffi.NULL, ffi.NULL)
        assert signed == 1

        return raw_sig
[...]

I am trying to understand what exactly is done in this step but I have no insight. I see that the called functions are derived from _libsecp256k1.

Code:

from ._libsecp256k1 import ffi, lib

I looked into the filesystem of that python module secp256k1, there is the file:

~/.local/lib/python3.10/site-packages/secp256k1/_libsecp256k1.cpython-310-x86_64-linux-gnu.so

but I have no clue what's inside. Can anyone explain to me, please?
What process in detail is done to get from the sha256 hash "315f5bdb76d078c43b8ac0064e4a0164612b1fce77c869345bfc94c75894edd3"
--> to the final signature ?

b85d62928d63583f52b14995c9444a92e1b7998a3fcfd0c134f327d61b162c6e7ea40adb783bd4c 00f9cfdb829c7e7d5b8d8e25a797d8548aec6f41df461fab9

My next question ... If I'm not mistaken the shown final signature in base64 representation is:

IEkjQHms3Yy0+B8INBVgKozpZc1rf3OHf7MCk2CnrGorYk2TEnwnNSHnLuK8tRkBIAIR1c9i8NCO19EebEHCMak=

How do you convert this base64 to get to the hex representation and vice-versa ?

Thanks to all.

Hello all,

Jean-Luc-Pond said that in his version of VanitySearch no RegExp is implemented and available. However, the original version VanityGen from sam7 contains a regex function. This is also mentioned in its readme.

Does anyone know if there is a modified VanitySearch version available that also allows PCRE/RegEx searches? If not, is there anyone among you with C++ skills who could re-implement the missing code from Sam7 in VanitySearch? Looking forward to your comments.

[EDIT:]

Hello everybody,

in the last days I am trying various approaches in Python to generate random private keys (hex) and the corresponding bitcoin address (optionally uncompressed, compressed, bech32 or mixed) as efficiently as possible and with good performance. There are several different approaches. I am actually very satisfied with the "bit" library from Ofek, because it is the fastest I experienced so far. However, if you also want to generate bech32 addresses, you have to do some manual extra work and the speed advantage of bit is then lost. So, as a very good and satisfying average I find the use of fastecdsa and iceland2k14/secp256k1 very fast.
EDIT:
Note1:
I didn't know that the Python library iceland2k14/secp256k1 was written natively in C++ and is just included in Python. Also, this library is closed-source, which means the source code is not known. So far, no security vulnerabilities have become known in this regard, but this point still deserves attention. There are some tools in the Bitcoin community that use this library for fast calculations.

Note2:
As I progressed, I found that the Python library fastecdsa is too oversized for generating random private keys and is not optimal in terms of performance. The secure Python library "secrets" on the other hand is fast when choosing randomness but also fast. It results in over +32 % better performance.

In several of my python programs I am testing, I have integrated a performance counter, which shows me the total number of addresses and the calculated rate (addresses/sec) while the program is running. However, I have taken this out in this examples to keep the code as simple and clear as possible. For relative ease of comparison, I do create 1 million randomly generated keys from which the Bech32 Bitcoin address (prefix 'bc1q' is then calculated. I write the output into a file, so I can check it afterwards to ensure everything went correct and the data is correct. I "time" the Python program to see how long it took to create the 1 million addresses. Let's get into it...

Here is an example which generated bech32 addresses:

Code:

#!/usr/bin/env python3
# 2022/Dec/26, citb0in
from fastecdsa import keys, curve
import secp256k1 as ice

# Set the number of addresses to generate
num_addresses = 1000000

# Open a file for writing
with open('addresses_1M.out', 'w') as f:
  # Generate and write each address to the file
  for i in range(num_addresses):
    prvkey_dec   = keys.gen_private_key(curve.P256)
    addr = ice.privatekey_to_address(2, True, prvkey_dec)
    f.write(f'{addr}\n')

It took 82 seconds to generate those 1 million addresses. This is a rate about 12,195 addresses/sec which is way too slow.

real   1m22,192s
user   1m21,461s
sys   0m0,640s

I often read about numpy and from what I could find on the internet about it, it sounded interesting. So I tried to rewrite the code to use numpy and compare the results.

Code:

#!/usr/bin/env python3
# 2022/Dec/26, citb0in
import numpy as np
import fastecdsa.keys as fkeys
import fastecdsa.curve as fcurve
import secp256k1 as ice

# how many addresses to generate
num_addresses = 1000000

# Generate a NumPy array of random private keys using fastecdsa
private_keys = np.array([fkeys.gen_private_key(fcurve.P256) for _ in range(num_addresses)])

# Use secp256k1 to convert the private keys to addresses
addresses = np.array([ice.privatekey_to_address(2, True, dec) for dec in private_keys])

# Write the addresses to a file
np.savetxt('addresses_numpy.out', addresses, fmt='%s')

real   1m19,636s
user   1m18,826s
sys   0m1,027s

As you can easily see, this did not bring any speed advantage, if you disregard the 1-2sec difference.

However, what caused significant speed boost was the attempt to distribute the program code into several threads and thus enable parallel processing. As I didn't see any disadvantage by using numpy I kept the numpy part in the code. Here is the extended python code:

Code:

#!/usr/bin/env python3
# 2022/Dec/26, citb0in
import threading
import numpy as np
import fastecdsa.keys as fkeys
import fastecdsa.curve as fcurve
import secp256k1 as ice

# Set the number of addresses to generate and the number of threads to use
num_addresses = 1000000
num_threads = 16

# Divide the addresses evenly among the threads
addresses_per_thread = num_addresses // num_threads

# Create a list to store the generated addresses
addresses = []

# Define a worker function that generates a batch of addresses and stores them in the shared list
def worker(start, end):
  # Generate a NumPy array of random private keys using fastecdsa
  private_keys = np.array([fkeys.gen_private_key(fcurve.P256) for _ in range(start, end)])

  # Use secp256k1 to convert the private keys to addresses
  thread_addresses = np.array([ice.privatekey_to_address(2, True, dec) for dec in private_keys])

  # Add the addresses to the shared list
  addresses.extend(thread_addresses)

# Create a list of threads
threads = []

# Create and start the threads
for i in range(num_threads):
  start = i * addresses_per_thread
  end = (i+1) * addresses_per_thread
  t = threading.Thread(target=worker, args=(start, end))
  threads.append(t)
  t.start()

# Wait for the threads to finish
for t in threads:
  t.join()

# Write the addresses to a file
np.savetxt('addresses_1M_multithreaded.txt', addresses, fmt='%s')

My system has a total of 16 threads available, so I distributed the load across all threads for that test. Now look at this:

Code:

$ time python3 create_1M_addresses_using_fastecdsa_and_ice_numpy_multithreaded.py

real   0m19,764s
user   0m38,147s
sys   0m6,367s

It took only 20 seconds to generate 1 million addresses. That is equal to the rate of 50.000 addresses/sec. Much better but I think it's still too slow.

I did realize through Linux tool "htop" that the 16 available threads on my machine were not utilized all and not fully with 100%. So the multithreading part seemed to work ok, but not as I expected. So I looked for more ways to properly distribute the load and found what I was looking for:

Code:

#!/usr/bin/env python3
# 2022/Dec/26, citb0in
import concurrent.futures
import os
import numpy as np
import fastecdsa.keys as fkeys
import fastecdsa.curve as fcurve
import secp256k1 as ice

# Set the number of addresses to generate
num_addresses = 1000000

# Define a worker function that generates a batch of addresses and returns them
def worker(start, end):
  # Generate a NumPy array of random private keys using fastecdsa
  private_keys = np.array([fkeys.gen_private_key(fcurve.P256) for _ in range(start, end)])

  # Use secp256k1 to convert the private keys to addresses
  thread_addresses = np.array([ice.privatekey_to_address(2, True, dec) for dec in private_keys])

  return thread_addresses

# Use a ProcessPoolExecutor to generate the addresses in parallel
with concurrent.futures.ProcessPoolExecutor() as executor:
  # Divide the addresses evenly among the available CPU cores
  addresses_per_core = num_addresses // os.cpu_count()

  # Submit a task for each batch of addresses to the executor
  tasks = []
  for i in range(os.cpu_count()):
    start = i * addresses_per_core
    end = (i+1) * addresses_per_core
    tasks.append(executor.submit(worker, start, end))

  # Wait for the tasks to complete and retrieve the results
  addresses = []
  for task in concurrent.futures.as_completed(tasks):
    addresses.extend(task.result())

# Write the addresses to a file
np.savetxt('addresses_1M_with_ProcessPool.txt', addresses, fmt='%s')

real   0m4,768s
user   0m54,444s
sys   0m1,894s

Perfect! Now I'm under 5 seconds for 1 million addresses. That's a rate of roughly 208,000 addresses/sec
How can we further improve the performance without using GPU? Is there anything else you can suggest, that will speed up the process?
Let's make a contest-like game. Create a simple code like this and try to beat the high score of currently 4.7 seconds for 1million bech32 addresses without using GPU.

The next step would be ==> how can we shuffle this code to the GPU for ultra-fast performance ?

Hi, I would like to understand how exactly VanitySearch works.

Can you actually search for a specific suffix with tools like VanitySearch or does it only work for prefixes? What is the reason that only in the prefix can be searched successfully and efficiently, but not in the middle or at the end of a bitcoin address? Are there tools available out there similar to VanitySearch that can search for certain suffixes or patterns ?

And how does VanitySearch calculate the "probability" until a hit occurs? The program seems to know a range and can therefore estimate how long it could take until a hit would be achieved. I conclude from this that VanitySearch does not simply create random addresses and then compares them according to the desired search pattern, but VanitySearch must rather search a certain range. Or? How exactly does this work, who can explain it to me in easy to understand words please?

Thank you very much.

[Question 1)]

Hello everybody,

stumbled over a few weird addresses and looking for an explanation. As you see in the block explorer, the addresses had incoming transactions and UTXOs because the coins were never spent.

bc1sw50qgdz25j
bc1zqyqs3juw9m
bc1zw508d6qejxtdg4y5r3zarvaryvaxxpcs

Question 1)
how does it come such short and valid bech32 addresses exist ?


until now I thought that all bech32 addresses always start with the prefix 'bc1q'. The mentioned examples above don't fit into this scheme as we see. On many info pages 'bc1' is mentioned as prefix. Out of curiosity, I looked at all the funded addresses on the blockchain to see what exist. There are thousands of addresses with prefix 'bc1p' and I immediately recognize that they have more characters than the usual ones with bc1q.

Here some examples:

Code:

bc1p000374fnuxfvhps6dvtut65g8kq7flhyy9zpltz6v07m8auxw8xsxmxr4q
bc1p000cavtlnpt9796j5rqzuc97mvr0z7dv7n63mvvxl9eeyqp6unrsjr8278
[...]
bc1pyu76wn0njsllkz39y2tkq4328k438rgzjvft2c26ucnq2gqle45qp2v8dy
bc1pzsh8nhmushx3gxyvgq2xwue8tqsdznhgtz2amtyr35anxhsrf97qay78he
bc1pzzzzmqpddscxwteulsaqha5t0sddvsuldcgzh096kg2gtfanxyds4gh798
bc1q00000002ltfnxz6lt9g655akfz0lm6k9wva2rm
bc1q0000005259fzmctd5xp7afs07dec5kxmp3fwgw
bc1q000000k2k2g4quxj7j3ddcz6kq69xa0xw8p2xx
bc1q00006zht44ezvmwjdymj9fnvcm0fmlwhdup55q
bc1q00007snl2y8ad3etca6mwzl86jvmk7av6u0772
bc1q0000et27ajp0vtyx5cqem3ngsjd447adp4wcu2
bc1q0000kvvqam2as2c3g26n7g3an596vuqnke64ew
bc1q0000qnrfhr5lf5a6v4042cwmdlkec9cpp7fr4m
bc1q0000sje0xgys2trk9972tudl4l220tyqttcr72
bc1q0000syek2pcnm5mupfg8uvew2lchgqyjswcyvf8d8exre3kw4assak2zgl
bc1q0000vcc9ypqa2ddlhj9vvz9rs5zpfzpr5ws4zn4uzkk28xezxh5qr55xjs
bc1q0000xx2wqshearravpm53nyy66e5fgu8erjxl3
bc1q0002chp04efzmcj7lv0tmem33v7ag3pv6rjv5z
bc1q0002gkkxx5mscfwtr0mthqnxyuwy0kgelgezpk
bc1q0002lrgfa8tkcz3ezspg2de4ss52n0sv72uxc0
bc1q0002q8zqngk6vv7pf594n4yrts8cgj7gw0w90n
[...]

Question 2)
I guess the longer addresses are P2WSH and the short ones are P2WPKH ?


Question 3)
how can it be that so many 'bc1p' addresses exist but this prefix is not mentioned at all in any known blockchain info site?


what's also interesting to see is the fact that there are many bc1p0 and bc1p2 and bc1p3 ...etc. addresses but no bc1p1 prefixed addresses.

Question 4)
Why? Although the chart '1' is allowed in the base58 charset. What cirumstance led to this fact that no such bc1p1 prefixed addresses were generated and seen out there ?

[solo mining]

Hello mining friends

I would like to tell you about my experiences, adventures and impressions I have made in the last weeks/months regarding solo mining. This should serve as a guide but also as a review for like-minded people who are facing similar problems and are looking for answers or want to share their own experiences.  It is not meant to be a manual, as it would go beyond the scope, although I will elaborate on some points I consider worth mentioning. If you want to learn more about the technologies presented here, you are of course free to do your own research and, if you have any questions feel free to create new posts of your own about them. For the following thread I would like to emphasize that all impressions I describe in the course are purely subjective, they show my personal opinion and this does not imply that it has to correspond to the fact or other views. I also refer exclusively and without exception always to Bitcoin, as I do not care about alt-/shitcoins and thus do not support them.

1) Requirements --> hash power for SHA-256 .

An indispensable condition for solo mining is -who would have thought it- hash power! Either you own your own hardware like ASIC miners (e.g. Bitmain Antminer, MicroBT Whatsminer, Canaan Avalonminer, etc.) or USB miners specially developed for the SHA256 algorithm (e.g. Gekkoscience Compac F, NewPac, etc.) or you rent the required hash power from one of the two well-known providers/marketplaces: MiningRigRentals.com or www.NiceHash.com. The principle behind these hashpower marketplaces is simple: ASIC miner owners can choose to use their hashpower themselves for mining or instead offer all or part of their device's hashpower for rent from MRR or NH. Understandably, the rental prices on the marketplaces are slightly higher than the rewards the ASIC miner owner would receive if they were to mine with PPLNS/PPS themselves. Therefore, many ASIC miner owners offer their hashpower for rent. Customers, on the other hand, are happy to accept the extra charge because they can scale very precisely when and how much hashpower they need. In addition, everything is included in the agreed rental price, the renter does not pay for electricity and does not have to deal with the loud noises that such an ASIC miner generates during operation.

Since I don't own any mining hardware at this point, I have to rent the hash power I want. I couldn't decide at first, but after reading a lot of forum posts here, or on Reddit and other sources, I initially chose NiceHash, simply because there was more reading material and experience reports. It gave me the impression that NiceHash was bigger/well known.

2) NiceHash.com (abbreviated as NH in the following)
So first I created an account with NH and tried to get an overview. First I "funded" my account with a not insignificant BTC amount by transferring from my private wallet to the NH wallet of my account. Nowhere in the deposit process does NH mention that 2FA is mandatory for a later withdrawal, but more on that later. Then I wanted to rent Hashpower from NH. Unfortunately, this turned out to be anything but easy, as I find the system rather confusing and not intuitively self-explanatory. The list presented under "Hashpower Marketplace" is difficult to interpret for a newcomer at first glance. There are roughly structured two markets displayed called "USA - WEST" and "EU WEST". For each of these 5 columns are shown: <Order ID>, <Price in BTH/PH/DAY>, <Limit in PH/s>, <Miners> and <Speed>, see the following screenshot.



For a newbie not everything is understandable and certainly not intuitive, because you can't click or even select anything at first glance. If you look at this line, for example ...



Then you understand that the ORDER ID is an 8-digit hex value that is supposed to hide the origin of the provider(s) for anonymity reasons. The column "PRICE per BTC/PH/DAY" is also understandable, it simply means that per Petahash 0.0044 BTC will be charged for the rental period of 24h. What the column "LIMIT" and "MINERS" should express, however, was mysterious to me at first. Afterwards I could find an explanation in the NH help pages. There it is explained that with NH you do not explicitly rent a single ASIC miner from a single person X, but that it is hashpower put together from several providers and machines. With Limit, it sort of sets the upper limit of hashpower in PH/s that one can choose when booking. And Miners shows how many individual mining machines this offer consists of.

After a bit of trial-and-error, I found that if you hover over the "Price BTC/PH/Day" column, a green checkmark with an arrow appears, and if you touch it with your mouse pointer, the text "Outbid order" appears. And here comes a crucial information to keep in mind when using NH:.

In the NH marketplace, everything is based on the system of bid and ask, i.e. the highest bidder gets the hash power. So you have to place your bid to rent the hashpower of a rig. So if one has placed an order and received hashpower and it has been sent to the desired pool, then everything is going so far for now. However, if you are suddenly outbidby someone else on the NH marketplace, then you have no hashpower anymore and are left standing because the highest bidder has "snatched" this hash power away. He simply bid more for it, so he got the hashing power. Of course, this is then no longer charged for and you also only pay for the service you receive, at least that's how fair it is. As soon as the other higher bidder is done or is no longer willing to pay as much and quits and you are therefore at the top of the NH queue, it continues again and you receive hash power again. Then the billing also continues accordingly. Despite everything, this condition should always be taken into account for one's own planning.

My overall impression and conclusion about Nicehash:

for several reasons for me an absolute no-no:

   - in order to be able to rent hashpower from NH, the customer is forced to go through KYC and drop his pants. Since I do not support this in principle and am strictly against it, it was already the KO criterion to continue to operate on this platform. I must honestly confess that I should have informed myself more thoroughly on their help pages beforehand. But I didn't even begin to expect that "renting hashpower" would require KYC for such insignificant simple actions. I was obviously mistaken.

   - i wanted to withdraw the high BTC amount back from NH by transferring it back to my private wallet. However, that was not possible and caused further trouble. NH forces one to set up two-factor authentication (2FA) to transfer amounts out of NH anywhere Bottomless cheek! Funnily enough, I was not forced[/i] to 2FA when I made the deposit, they accepted that without a hitch. But when paying out, they deliberately make it difficult. In short: To deposit funds into the NH platform they like to see, to release amounts that leave the NH platform again --> they obviously don't like to see that and make it more difficult for the customer intentionally by such hurdles. I don't like such "policies", that is for me no-go!.

   - I have followed dozens of solo mining parties that were carried out using hashpower on Nicehash. In doing so, I myself was able to follow the progress of hash power, shares, best share, etc... in detail, even though you don't have to have participated yourself. More about this later, in the section Kano-Pool. A run of about one day shows dozens of dropouts, interruptions and partial standstill for several hours. The reason for this was already mentioned above -> NH works on a bidding system and if someone overbids then the hash power is "snatched" away from you and you are left with 0 hashes/second. This is unreliable for the following reasons:

• (a) Let's assume a big difficulty increase of the bitcoin network is coming up in the next 25h, which everyone can see and estimate. But I still want to try my luck in the current difficulty class and mine for 24h with a huge hashing power. I rent this with NH and off I go. After about 6h I get outbid and so I don't hash at all. The one who outbid me is done after 17h and I slip back to the highest bidder and get my booked computing capacity again. This would theoretically run for me for another 18h (6h I have already used) but at this point after 1h the difficulty has been increased and I have no more interest in mining due to the blatant difficulty increase. I stand there stupidly, bag to, thing run. Finally, it means for me as a renter, I can not set a guaranteed rental period and thus can not reliably plan and calculate in the long term.
• (b) I can't do proper costing and long-term planning because the potential rental of hashpower has no 'fixed' costs can be allocated. I don't mean the general and usual market rice fluctuations but simply the fact that I don't have stable values for calculating rig/hashpower rent due to this supply/demand system. This is the logical conclusion from point a) because both price and time are assigned as a function.
  
• (c) There is no evidence or criteria in NH that meaningfully represents the state of a rig (or rig aggregation that is behind the anonymized "Order ID") to enable an assessment of reliability. Due to the lack of a rating system, it is not possible for the customer to roughly estimate whether the rigs will actually work reliably for the rented period without considerable hashrate fluctuations or even failures when they go offline (for whatever reason). In my opinion there is only one small approach to counteract this -> The value of the column "Miners" from the offer list should be as high as possible when selecting an Order ID. This way it does not matter much if e.g. 2 out of 139 miners would fail.
  

3) MiningRigRentals (hereafter abbreviated to MRR)

Since it was crystal clear to me that I would never use Nicehash for the first time, that left only MRR, easy choice So, registered there and looked around what MRR has to offer. Right away I got along much better here, everything worked intuitively and it was very clear to my sensation. Click on [Marketplace] and then click in the search box and start typing, when you get to SHA2.... all three available algorithms are displayed as hits:



Relevant to Bitcoin, the two hits colored in red are "Sha256" and "SHA256 Asicboost", with the latter offering better rents and usually being cheaper.
Here is a sample overview for the SHA256-ASIC rigs (as of 10/15/2022 / around 7:30pm):



When you select a rig, you get quite a bit of information displayed about it and can get an idea of whether it is a reliable rig and will keep the offered hash rates over the long term. For example the following rig (freely chosen by me, is now not necessarily a favorite of mine, so just random selection for demonstration purposes):



We see the location (US-EAST) for this rig. This is not irrelevant, as some pool operators allow you to choose certain pool servers located in other regions / countries / continents. The goal should be to have the shortest possible latency between the rig and the pool, as this can be the deciding factor for (failure) success. If I rent a rig in Russia and send the hashpower to a pool on the US west coast, it could be that the connection is much worse than choosing a pool server in the EU. In the worst case it can be that you have found a block, but until it is fed into the network and propagated it took too long, someone else was faster and you stand there stupidly without reward (orphan block). I just want to point out that it can be helpful to know the server location of the rig so that you can later adapt it to the server locations of the mining pool you are using, if the pool you are using offers this possibility at all. In the screenshot we also see the operator of this rig, I find this very helpful, why? I maintain an excel list for all my rentals I have done so far. I can make notes on them and very quickly and accurately filter out the good rigs from the bad. If I see certain "owners" with whom I have had bad experiences in the past because they responded late or even unfriendly to my inquiry about a problem, then I set internally "red flag" on these owners or also specifically on the Rig ID. I then avoid renting the same owner or rig again in the future. In the field "Suggested Diff" the rig owner can enter a Difficulty, which should be used as a guideline. So the person who wants to rent the rig knows if it is a lowDiff or HighDiff. In some pools you can also set the Diff, so you can select the right adjustment in advance so that everything goes smoothly in highspeed. The value under "Optimal Difficulty" is automatically calculated by MRR for the respective rig in such a way that 2-3 shares per minute are processed. This ensures the best possible throughput and a solid average performance. If the difficulty would be tuned higher, less shares per minute would come through and this would cause a rather fidgety course of the plot in the long run (also in the charts). The charts are an important basis to show reliability. In the above posted screenshot you can see in the upper chart window the live hashrate for the short-term time range.The blue area shows the 5min average and thus the largest swings. The black line the 30min average and the green line the 60min average. For the long-term view and thus the reliability one looks at the lower chart. The blue filled area shows the short term 5m average at the time shown, the black line the 30m average with a more smoothed line. Also, the red dashed line in both chart areas marks the hashrate advertised by this rig (500 TH/s in the example). So you look at the bottom chart, the black line should be at least above or around the red dashed line. This gives you great reliability that the advertised hashrate will be consistently achieved and delivered over the long term.

The upper chart shows the live hashrate, it serves as a quick assessment of whether everything is running ok or there could be any problems. In principle, it behaves like this: it may be that the rig briefly delivers less than the 500 TH/s advertised here, but it delivers a higher hashrate sometime later. Here again a screenshot I made a little later from the same rig. There you can see that the live hashrate was once briefly below the red-dashed one, but then shot up again and delivered 634 TH/s. The averages are relevant.



In the example, you have to rent for at least 24h and can rent for a maximum of 72h. The lowest possible rental period for MRR in general is 3h and on top there is no fixed limit as far as I know, or the rig operator can set it very high. Through the Quick Calculator you can see immediately how much BTC it would cost if you would rent xx hours and yy minutes. What is also possible: you can extend during the rental period if you want to. That however to a small extra charge, which is accounted for in the form of a fee. However, this is displayed transparently when you want to book the "extension".

The tabs [Workers] and [Rental History] are also very useful. In "Workers" you can see directly which difficulty the respective worker is currently using and how the individual hash rates of the particular workers look like. This can be very useful if you use a pool that allows customDiff. You can see to what extent the rig and the pool have synchronized and work well or less well together. You can also see exactly which miner software/firmware and which ASIC miner is being used and also the location of each worker. In the [Rental History] tab you can get a good picture of how reliable the rental operations have been in the past. Green color means that the advertised hashrate was largely achieved (plus minus about 5% is within the tolerance range, I think). These values also form the RPI (Rig Performance Index), a benchmark whether the rig is reliable and delivers the advertised hashrate in the long run or not. You can also see how long the rigs have been rented in the past and also by which renter (unless the user has turned off this feature under their personal settings, so that anonymous is then displayed there).



Now let's move on to the pools and how to choose one ...

4) Which solo mining pool to choose?

I had initially looked at <https://btc.com/stats/pool?pool_mode=all> to get an overview of all available pools. However, it lists all possible pools that have already mined blocks. You can't see if the listed pool also offers solomining. Nevertheless, the information on this page is interesting, more on this later.



The pool that found the most blocks is "Unknown". Unknown because it contains all those mined blocks whose coinbase transacation content could not be matched to any known pool string. For example: If user "lucky_miner" is mining privately on his own full-node and finds a block, then he can write free text into the coinbase transaction, which then appears publicly in the coinbase transaction of that mined block. However, the major known mining pools (F2Pool, Antpool, Slushpool, Binance, ViaBTC, SoloCK...) use specific text patterns for the coinbase transaction and therefore unique identification is possible. In short, all blocks mined that cannot be uniquely identified and assigned to a pool appear as "Unknown". The top of this pool list is "F2Pool" as can be seen. After that comes "AntPool", "BTC.com", "Braiins Pool" (formerly Slushpool), "BTCguild", "ViaBTC", "Poolin", etc. The actual total hash rate of the pools cannot be taken from this page, but is completely irrelevant for solo mining.

Originally I thought that the column "Empty Blocks Count" or expressed in percentage "Percentage of Empty Blocks", shows the number of blocks that the pool lost and therefore did not pay out. But empty blocks are just blocks without any transaction except their own coinbase transaction. So it is still a mystery to me why this "empty blocks" column matters and is displayed on this page at all. Another important thing are the "stale shares". These are shares that the worker returned to the pool too late. An "orphan block" instead is a completed and actually valid block whose calculated hash value was below the difficulty target and thus would be valid, but it was propagated too slowly through the network. Someone else promptly also found a valid hash value and thus a valid block, and propagated it faster than you. The longest chain wins, the inactive part that did not make it is ignored by the network and a way (orphan) is formed, the too slowly propagated block is thus dropped, hence "orphan". For the miner, of course, this is a nightmare, as he has rejoiced too early. Therefore, miners and especially beginners should always be aware that it is actually a bad idea to mine from home with your private internet connection (DSL, cable) and your full node, even if you should have 1 GBit/s fiber connection or cable connection. It is and remains a private household and the connections to the Internet are always inferior to a connection of a server in the data center. The private computer goes through dozens of routers (hops) and gateways and its bandwidth is shared with hundreds/thousands of other users in the strand. Both the ASIC miner and the full-node should therefore be located as close as possible to a performant backbone. In addition to this, the novice miner may unknowingly further aggravate his position by using VPN or TOR connections for his mining project, or even WiFi. All reputable mining pools invest in potent hardware with a damn fast internet connection in different and thus multiple data centers/locations, with DDoS protection and much more.

For now, let's move on to the next info page to help us choose a pool for solo-mining...
https://MiningPoolStats.stream/bitcoin

This page shows us all pools in the default view sorted by the total hashrate of the pool. The data is obtained through API from the respective pools. Some pools simply don't have an API or deliberately don't want to query data from such services (e.g. Foundrydigital). Here is an example screenshot of what this looks like:



On top here is foundrydigital, as a private person I don't think you can participate there at all, here are really big fish on it with millions / billions of expensive equipment and really big mining farms. There are certain requirements here, so that one can participate in the pool at all. Therefore, there is no information about the different mining types that are provided, or returns, or number of miners. The other places in the top 5 are usually shared by Antpool, F2Pool, ViaBTC and Binance. So how do you use this information to choose a suitable pool for your mining project? Well, that depends on if you want to do solo mining or if you want to mine as PPS+ or PPLNS in a community. I had dedicated myself to all types and made my experiences with it.

However, this thread is supposed to be exclusively about solo mining, so I focus on filtering out the pools that offer solo mining.

We look in the [pool/fee] column and look for the pools that have the text SOLO with red font color. Next to it is the fee that goes to the pool operator. The information "Miner Count, DailyPPS, Min.Pay, Hashrate, Blocks, LastFound" are all irrelevant for solo mining.



I'm picking out the solo mining pools:

Code:

5. ViaBTC.net (1 %)
21. zsolo.bid (0,5 %)
22. luckymonster.pro (0,5 %)
23. btcmill.cc (1 %)
24. solo.ckpool.org (2 %)
26. kano.is (0,5 %)
27. mining-dutch.nl (1,5 %)
30. solomining.io (1 %)
36. soloblocks.io (0,4 %)
38. aminingpool.com (0,95 %)
43. prohashing.com (1,99 %)

... and sort ascending by pool fee:

Code:

soloblocks.io (0,4 %)
zsolo.bid (0,5 %)
luckymonster.pro (0,5 %)
kano.is (0,5 %)
aminingpool.com (0,95 %)
solomining.io (1 %)
btcmill.cc (1 %)
ViaBTC.net (1 %)
mining-dutch.nl (1,5 %)
prohashing.com (1,99 %)
solo.ckpool.org (2 %)

Most would probably intuitively opt for those with the smallest fee, so that they have to pay as few fees as possible in the event of a block hit and reward receipt and thus more goes into their own pockets.  But whether all that glitters is gold? What I describe now shows my approach and thoughts to it. The whole thing should ultimately serve as a suggestion and idea. I rented a cheap rig from MRR for the short duration of 3h and a hashrate of 100 TH/s which I then directed to each pool in turn and took some meaningful screenshots and documented my experiences. I tested each solo pool from this list so that I could filter out and then ultimately settle on one.

How do I evaluate and what criteria matter

Website:
First impression of the website? Does it look similar to already known websites or pools then I devalue it because the operator probably wanted to save time and quickly copied a layout and changed it slightly. I know that there are self-titled "crypto experts" on the Internet who offer as a service a ready installed and configured mining pool for a fee (by abusing open-source pools for this, ugh). They offer different packages at different prices, depending on the functionalities. Such layouts are immediately noticeable, especially if the operator has made an effort for customizing or not. I downrate if the website requires JavaScript. I usually rate positive, if a clean and neat design stands out, so that everything remains clear. I like it plain and simple, without a lot of bells and whistles and dozens of buttons and tabs or submenus. So that even on the go with the mobile phone can be accessed directly and quickly. I find it positive when the statistics data of the own miner can be called directly via URL. I rate it positive if I get the impression that the pool operator has made an effort to list as much helpful information as possible. I radically devalue if you are forced to register before using the respective pool.

Server location and availability:.
Most pools offer at least 1 server and 2 different port numbers (see following paragraph "Difficulty/Configuration"). A few of them offer additional port numbers, e.g. 443 or 25, which can be advantageous for some constellations, depending on where the miner is located and where it might not be possible or even allowed to connect via the high ports (>1024). Port 25 (SMTP) and 443 (TLS) are allowed by routers/firewalls with higher security. It could be that you have your own miner somewhere on a company site, but the network there blocks all outgoing traffic on unknown ports. In such a case you could try using port 443, as this - with a bit of luck - would be treated less restrictively by the company firewall. Furthermore, MRR requires that you have at least two servers configured as a pool so that in case of a pool problem MRR interface can automatically switch to the other one. Only then you are entitled to a refund in case of problems and complaints. I consider it positive if alternative ports are offered by the pool. It is also a plus if the pool offers not only one server but several distributed over the continents, preferably all as high-end computers in data centers with direct backbone connection.

Difficulty Configuration:
All pools I know of offer at least the "varDiff" functionality. This means that the pool gives the connected miner the jobs with an initial difficulty (initial diff) and then looks how long it takes. Most pools aim for about 2-3 shares per minute. They increase or decrease the difficulty accordingly, it's kind of automatically negotiated and coordinated between the two parties. However, if the "initial diff" seems too large for the miner during the initial negotiation by the pool, the two do not get on the green branch. Miners with higher computational capacities can understandably handle higher difficulties and, above all, faster. They need a high diff. That's why all known mining pools offer their users the option to use either lowDiff or highDiff. This is achieved by connecting to a different port number. This is described in the respective instructions of the pool. Then there is additionally the functionality "custom diff", this gives the user the possibility to define and set the desired difficulty manually, mostly via the password field in the format "d=123456" where the abbreviation 'd' stands for difficulty and the value is the desired value you want to configure. However, this should only be necessary in special cases, the automatic tuning usually works quite well, as long as you have chosen lowDiff or highDiff correctly. "VarDiff" and "lowDiff/highDiff via port number" is actually part of the standard, customDiff is not offered by all. I therefore consider it a small plus.

Freely selectable worker names to distinguish the individual runs:.
Most, but not all, of the solo mining pools presented here allow users to use user-defined worker names. These worker names are appended as a suffix to the user's own Bitcoin payout address, using a period (.) or underscore (_) as a separator. Example: the own bitcoin address to be used as payout address is bc1q111222333444 and the desired worker name would simply be bc1q111222333444.foo or bc1q111222333444_bar etc. Why do this? Quite simply, to distinguish and clearly separate the statistical data collected for the particular run for further analysis. For example, I run a solo run today by renting the hashpower 500 TH/s for 6h and pointing it to the solo pool and then I see in the statistics data of the pool how many shares I managed and what my highest share (best diff share) was. Let's say my 'best diff' was 271G. Tomorrow I rent hashpower again and send 2 PH/s for 12h to the same pool with my same bitcoin address. Inasmuch as I would not have exceeded the 'best diff' value of yesterday's run (of all previous runs), I would never see what my 'best diff' was for the current twelve hour run at 2PH/s if it was less than 271G. That's because the statistics would still display 271G. Also I can't distinguish and read out how many shares were transferred in the current run. Simply because each time the same bitcoin address was used and the data is cumulated (= merged). This circumstance can be circumvented by choosing worker names. In this case I would have chosen the worker name bc1q111222333444.500TH-6h for the first run and bc1q111222333444.2PH-12h for the second run to distinguish them... at least that's how I do it, of course it's up to everyone how to choose and handle worker names 

Direct mining via own Bitcoin address without registration:.
Absolute no-go is when the solo pool forces the user to register. It is not a matter of having to register with an e-mail address, but of mining using a user name that was used during registration. Consequently, in the event of a block discovery, the reward of currently 6.25 BTC is not paid directly to the user's own Bitcoin address, but only to the defined payout address specified by the solo pool owner. The pool operator has defined this statically for his pool, and this data is stored in the coinbase transaction. In practice, in case of a block hit this means that the pool operator collects the reward of 6.25 BTC + transcation fees in the first step itself and then only pays out to the respective user to the payout address requested by the user and entered in the customer portal. In the worst case, the mining pool operator could bitch and refuse the payout or put other hurdles in the way, such as forcing the user to first perform KYC before he pays out to him. Or the operator might die in an accident or due to illness, or the company (the solo pool) goes bust and everything ends up in a bankruptcy estate and you can only hope to get your reward that you are actually entitled to. I would definitely not take such risks with such high amounts of currently > 6.25 BTC. All pools without exception that do not allow direct mining with one's own private Bitcoin address are NO-GO and red flag, even though I included them for comparison in this test.

Statistics data and information on solo mining:.
While not a statement of potential success for mining a new block, I personally find the "best diff" and "best ever" stat info to be entertaining. "Best Diff" is the highest value achieved for one's bitcoin address/worker and is automatically reset to zero by the pool should the respective solo pool find a new block (regardless of which user on that solo pool). The "best ever" however remains, it will never be reset and shows the personal 'highscore' that has ever been reached under the given payout bitcoin address. You get a clue how good or bad your own run went and can compare in the future. Other useful information would be 'number of shares' and the 'current Difficulty' that the pool gives out to its workers. This is for performance purposes, you can see how many shares/min are processed at which diff. Accordingly, you could set the Miner<>Pool like this with e.g. customDiff to adjust these works to your taste and liking. Although it shows nothing about the chances of success, some may want to do it themselves and customize, so a lot of information provided is only an advantage and never a disadvantage. In the end, those who don't need certain info can simply ignore it. In short, if the pool provides as much info/statistic data as possible, then I consider that a plus.

Background information about the operator, presence and notoriety in the scene:.
I search the internet for all conceivable information about the pool in question. Primarily here on bitcointalk of course but I also look for clues or experiences on Youtube videos, Reddit posts, IRC servers or log onto their Discord servers and follow the conversations for several days/weeks.

Number of users+workers:
I look at how many users have joined this pool and tried their mining luck there. The pool operator could of course easily fake this data on their own pool website, but I still consider it as an approximate guideline to get an idea if the pool is in demand or if it's more of a flash in the pan. The overall hash rate of a solo pool has no significant meaning for a solo miner, as this performance has no relation to the success or failure for solo mining. It only says that a few or more miners are sending hash power to that solo pool to try their mining luck. Likewise, the indication of "users" or "workers", this only serves as a rough guide to assess the pool acceptance of the mining community.

Solo Pool Success Story
Probably the most critically considered and most important question in this context is: "Has the respective solo mining pool ever been successful, has a block already been found here and has the corresponding miner received his payout without complaint?" For this purpose, one can primarily make use of this BTC pool list, the interpretation of which, however, requires explanation so as not to mistakenly compare apples with oranges. One must know here that with this list all pools are listed without differentiating between solo pool mining or community pool mining where people mine as a group via PPLNS/PPS/etc. There are pools that offer both models (e.g. ViaBTC or Kano Pool). If you look at place 29 "KanoPool" in this list, for example, there is a value of 2,433 blocks in the "mined blocks" column. However, this does not (!) mean that so many blocks were mined in the KanoPool via solo mining. In reality, the Kano.is pool as solo mining has not found a single block so far. It has also only had the solo mining model in place about 1 year ago, prior to that it offered its services exclusively as PPLNS for years. The blocks shown were mined in the PPLNS model, the last block found in PPLNS mode was found by Kano on 10/25/2021 (see details here). Likewise, this list also does not tell us how many blocks the large ViaBTC pool found in solo mining mode. The data on this list is commingled, therefore no meaningfulness of the "mined blocks" column in terms of solo mining, so this important info should be kept in mind.

[deleted]

Originated from following thread on [page 2244]
Re: KanoPool since 2014 🐈 - PPLNS and Solo 0.5% fee - Worldwide - 2433 blocks

Pictures say more than a thousand words. Here are the screenshots of the thread progress.























That's again once more typical Kano, he obviously can't take criticism, especially when he is exposed in the process and it is made public. He deleted the post and hope that no one has read it. But so that users do not fall for his dirty games and are abused, this incident hereby is made public to provide proper clarification. Interested parties can investigate and check everything themselves and make sure of it. The following post was deleted by Kano, because he apparently did not like it. Who is surprised?

On any pool you connect to they know your IP address.
You can't connect to a pool without using the internet

Of course.

When a user connects to the SoloCK pool to mine, the pool operator knows his IP address and the payout address he uses. That's all.

If a user connects to the Kano pool to mine there, then the pool operator knows the IP address, his used payout address, his email address and in case this user also uses Kanos' Discord server, smart Kano also knows the direct mapping from Discord username to Kano pool username.

This is called metadata, which you can easily do without.

Secondly, as I have already pointed out to you before, yes you can connect to discord without giving me a discord key. It is NOT MANDATORY, you are wrong. There are people on there in my channel all the time who don't have a role, who have been connected for a very long time. Edit: 8 at the moment and I'm pretty sure most of those 8 have been connected all year, if not longer. Please go learn a bit about how discord works.

Don't overload people with false information. Everyone is free to find out and look up what Discord roles are all about. Roles were not designed to create fancy colors over nicknames, but they are there to assign rights and privilege management. For example, to enable such great features as AutoKick, AutoBan and many more...

The people who use Discord every day and use other servers than yours know very well how roles work. They also know that you are usually not forced to reveal additional private information in order to participate in the server. Some servers deliberately want to prevent spam abuse and the like and perform cell phone verification, but that's a different story altogether, but it has one thing in common with your approach: the direct mapping and linking of your users' meta-data. If you really want to assign roles, you could also use automatic role assignment for that, as many Discord servers usually do.

I encourage people to get a role to avoid problems, that might happen.

Bullshit. There is no justification that any problems falling from the sky will occur. This is just another ridiculous claim on your part, behind the veils of which you try to hide your actions.

It's not mandatory and I have never said it is.
Not sure why you are spouting that.
The exact words on the web site are:

"You should get the Discord 'Miner' role, as explained further down,
to help stay connected and remove the 10 minute delay."

You as the operator of your Discord server do not allow new Discord users to stay on your server unhindered for a longer period of time. You or your few disciples, whom you have exposed and trained on it, thereby address every single newcomer on your server to absolutely carry out the Discord ID verification. In doing so, you refer to the pinned message at https://kano.is/index.php?k=support in which you write among other things:

Discord

The main support for KanoPool is on Discord.
You can use the Discord invite: Discord to access the support channel.
There's a 10 minute delay after you join the channel, before you can post messages in Discord. Make sure you stay connected otherwise you will timeout.

You should get the Discord 'Miner' role, as explained further down, to help stay connected and remove the 10 minute delay.

Note with Discord, if you don't have a role in the channel, you must always be connected to the channel to interact with others. If you timeout or disconnect, people can not send you messages, and I cannot give you the Discord 'Miner' role when you aren't connected.

To get the Discord 'Miner' role, firstly, make sure your account here at KanoPool is verified, if you haven't already verified it, at Account->Verify, then create a 'Discord Key' on the Account->User Settings page. In Discord, just tell me the 'Discord Key'. I don't need to know your pool username, and it can be different to your Discord name.
Make sure you created the 'Discord Key' just before you tell me. It can't be more than a day old when I check it. Everyone has a different 'Discord Key'.

You try to tricks your users with such phrases as: "just tell me the 'Discord Key'. I don't need to know your pool username" knowing that you will immediately know which user on your pool generated this ID by the transmitted Discord ID.
Don't continue to make a fool of yourself. The users who use Discord know very well how Discord works, they are after all daily on other servers and know the requirements and functionalities. There are several users reading here who have already gone through the registration procedure on your pool and also its one on Discord. They know very well to distinguish truths from untruths. You can no longer blind them either way. It doesn't change anything trying to rub salt in people's eyes.

Any site, every pool, you connect to knows your IP address and thus will always know your username vs your IP address.
If you don't want the pool to know where you are, you take the VERY SIMPLE AND EASY steps of using a VPN to access the web site and discord.

Mining, however, like every other pool on the planet, should never be done using Tor or a VPN coz you greatly increase the risk of losing a block due to being an orphan or stale.
Indeed if you must use a VPN, then mine somewhere else, I'm positive everyone else on the pool would not be happy about losing a block coz someone doesn't understand how bad an idea that is.

OT

Edit: yes I've deleted your reply - facts - or I delete it.

But that's what you've done. You deleted the facts. Congrats! But no worries. I have archived them here so everyone can read them.

You seem to be upset about that fact that I pointed out how you are publicly posting people's BTC address and transaction.
Well, that's what you do, so ... yeah that's how it is.

Both Willi9974 and I post publicly for our runs the transaction IDs and also the desired payout addresses of the participants. This is obviously stated in the declaration, the participants know this and do it. This is for TRUST. And for a valid reason:

Precisely so that everyone can publicly check in the blockchain whether these transactions ever took place or were faked. Everyone can look up which payment took place when exactly and to where. Both deposits and withdrawals. All in the spirit of the blockchain and pseudonimity.

Unlike you, we have nothing to hide and communicate OPENLY and HONESTLY with the participants.

In the following you see the list of participants of your last 13 Fun Runs which you advertise on your discord server. I can recommend every reader here to download the screenshots and look at them one after the other in his viewing program of choice to see clearly the differences between the screenshots. Why? Because every blind person will discover and understand that they are one and the same user and if the list is not even full it will be completed with fantasy names. Whoever sends you money, I don't want to know where it ends up and what is done with it. I can't either, because no one can verify that. Simply because you do not make it public.



























Someone who deletes something or tries to make it opaque has something to hide.

This lousy move once again confirms Kano's character. Don't let him fool you.

For the records...

I am aware that there are various wallet tools out there in the world and probably no one will know the exact behavior of each one by heart. But maybe you can answer the following question in general...

I wonder if wallet tools fundamentally and exclusively generate private keys in the 256 bit range. Or can it happen that such a tool generates a 103bit or 87bit private key when generating addresses/wallets? I would simply expect that the highest possible number of bits would always be used but do the common software/hardware wallets really do that?

Looking forward to your answers.

Hi all,

i remember reading somewhere regarding a bitcoin puzzle that someone had found a private key and deducted the prize money not only from the corresponding bitcoin (mainnet) address, but also correspondingly from Bitcoin Gold, Bitcoin SV or maybe others.

Let's say someone finds a valid private key from the well-known 32 BTC puzzle. He can quickly take his reward from the the Bitcoin address. Is there a known open-source tool that additionally to Bitcoin mainnet spits out all possible addresses from other networks from that private key? At best, it should also make an API call to query an online block explorer and check whether the respective address also is funded.

For example mass balance-check for

Bitcoin (BTC)
Bitcoin Cash (BCH)
Bitcoin SV (BSV)
Ethereum (ETH)
Litecoin (LTC)
Dogecoin (DOGE)
Dash (DASH)
Zcash (ZEC)
... or others you may think of

Of course, this should all work on the local computer and not on an online website, because you never enter private keys on an online platform, because the operator could know and abuse its content. If anyone knows of such a tool, I would be very grateful.

[Text can be]

Hello everybody,

Electrum on GNU/Linux has following command-line restore function which can be viewed in source-code here.

Code:

electrum help restore

usage: electrum restore [-h] [--passphrase PASSPHRASE] [-W PASSWORD] [--encrypt_file ENCRYPT_FILE] [-w WALLET_PATH] [--forgetconfig] [-v VERBOSITY] [-V VERBOSITY_SHORTCUTS] [-D ELECTRUM_PATH] [-P] [--testnet]
                        [--regtest] [--simnet] [--signet] [-o] [--rpcuser RPCUSER] [--rpcpassword RPCPASSWORD]
                        text

Restore a wallet from text. Text can be a seed phrase, a master public key, a master private key, a list of bitcoin addresses or bitcoin private keys. If you want to be prompted for an argument, type '?' or ':'
(concealed)

positional arguments:
  text

It works fine when I use one single private key, either by supplying it into the command-line or using a one-liner text file with the key in it.

Following two commands work

Code:

electrum restore -w my_wallet p2pkh:KyRNwetcetera

Code:

electrum restore -w my_wallet $(cat my_list.txt)

whereas my_list.txt has following content:

p2pkh:KyRNwetcetera

But as soon as I want to import several keys it doesn't work. I am using a list with several private keys. The text file I am using has one private key per each line including the prefix p2pkh, here an example:

my_list.txt

Code:

p2pkh:KyRNwetcetera
p2pkh:L3UDbPkandsoon
p2pkh:KyjLwWsomEmoRe
p2pkh:L3ve7kqlore1psum

I also tried various formatting like

Code:

p2pkh:KyRNwetcetera,
p2pkh:L3UDbPkandsoon,
p2pkh:KyjLwWsomEmoRe,
p2pkh:L3ve7kqlore1psum,

or

Code:

p2pkh:KyRNwetcetera p2pkh:L3UDbPkandsoon p2pkh:KyjLwWsomEmoRe p2pkh:L3ve7kqlore1psum

or

Code:

p2pkh:KyRNwetcetera,p2pkh:L3UDbPkandsoon,p2pkh:KyjLwWsomEmoRe,p2pkh:L3ve7kqlore1psum

or

Code:

p2pkh:KyRNwetcetera\np2pkh:L3UDbPkandsoon\np2pkh:KyjLwWsomEmoRe\np2pkh:L3ve7kqlore1psum

nothing works, the error is:

Seed or key not recognized

or

usage: electrum [-h] [--version] [-v VERBOSITY] [-V VERBOSITY_SHORTCUTS] [-D ELECTRUM_PATH] [-P] [--testnet] [--regtest] [--simnet] [--signet] [-o] [--rpcuser RPCUSER] [--rpcpassword RPCPASSWORD]
                [-w WALLET_PATH] [--forgetconfig]
                <command> ...
electrum: error: unrecognized arguments: p2pkh:KyRNwetcetera p2pkh:L3UDbPkandsoon p2pkh:KyjLwWsomEmoRe p2pkh:L3ve7kqlore1psum

any clues ?

[keyhunt (+BSGS)]

EDIT:
Due to multiple requests, I try to link the tools in each case. I try to link to the original author's github repository when possible. If I have linked incorrectly or made a mistake in the author, please correct me - I am very grateful for corrections. I have also added few entries and info to the list.

Hi all,

there are dozens of tools available out there and I am not sure if I listed them all. Please add them if they're worth to mention. I am trying to find out which tools are preferable and mostly used out there. This list is focused on GPU capable tools, because using CPU only is kinda useless (except BSGS) for puzzle solving above #66. I thought I'd create an overview from which we can all benefit. I want to define the areas of application, which tool is suitable for which purpose, etc. Perhaps the developers of these tools can also get in touch and add the missing information or correct the information found here if something should be wrong. Please forgive me if I have described something wrong.

keyhunt (+BSGS) (github link, forum link)
- as far as I know, this is CPU version only. Keyhunt is memory-bound and makes use of lots of it in order to find keys.

keyhunt-cuda (github link 1, github link 2)
- this is the modified version of Albertos' original keyhunt which now is capable of CUDA. What's the main difference between keyhunt-cuda and bitcrack? both support CUDA

Bitcrack github link, forum link)
- supports GPU, but not really multi-gpu capable as described in its readme. You need to open one window and access gpu1 on your system (first bitcrack process running), open an additional new window and run another copy of bitcrack (second bitcrack process running) and so on.
- does not support random mode
- no progress status, you never know how much of the keyspace you already have scanned.
- in my findings so far the keyrate achieved with Bitcrack or Bitcrack2 is always about 30% lower than when using keyhunt-cuda for searching the same keyspace. Your mileage may vary.

Bitcrack2 (github link 1, cannot find forum link)
- as far as I can tell the only addition in BitCrack2 is, that you can run it in random mode. It will then search randomly through the range search space.
- has progress status, you see how many % of the keyspace search is completed and you also see what was the last keys that were tested so you get an idea where the search currently is located at
- in my case the keyrate achieved with Bitcrack or Bitcrack2 is always about 30% lower than when using keyhunt-cuda for searching the same keyspace.  Your mileage may vary.

VanBitCracken(Random) (github link, forum link)
VanBitCrakcenS (github link, forum link)
- VanBitKracken family of software was developed very recently in 2020-2021 by WanderingPhilosipher I have no idea how old and useful this tool might be and what the main differences to the other tools here presented are. Any information?
EDIT: As the autor said in the forum link for this tool, this is Windows only edition, does not work on Linux. This is a mixed tool, something like between VanitySearch and BitCrack, especially made for supporting the Nvidia 3070 cards. As there are no source code files available on his github repository, only a windows .exe (which is highly dangerous to execute! no trust), I removed this tool from the list.

Kangaroo (github link, forum link)
This tool can be only used when the pubkey of an adress is known. That means that there must have been minimum one outgoing transaction from this address or a message that was signed by this address or the pubkey has been revealed otherwise.

BSGS (github link )

BSGS-Cuda (github link)
- runs on CPU only and cannot make use of GPU. As far as I know there is a CUDA-capable modification available, however I was not able to install and run it. Is there anyone out there who can provide a download link for the old and free version of purebasic v5.3 ? Without purebasic it's impossible to run this tool which was made by Etayson. The user was online hear about 1-2years ago for the last time, no reaction at all. Any clues?

Rotor-CUDA (github link)
- was that a tool that was created and published before or after Bitcrack2, Kangaroo, etc... ? I have no idea how old and useful this tool might be and what the main differences to the other tools here presented are. Any information? As I understand Rotor-CUDA can use random search but Bitcrack2 is also capable of random searches as well as keyhunt-cuda. Did I miss any important feauture info ? What's that tool good for in comparison to the other mentioned ?

Brainflayer (github link, source)
that tool allow use to brute force the hex privatekeys in order to find the hash160 of an address. Basically it hunts for brainwallets. You feed it with a word list of phrases and try to find matches to valid and funded bitcoin addresses.

Looking forward to hear your comments, what tool is best-suited for which purpose and case and which tools you puzzle-hunters out there are using.

[62599e]

I am trying to learn Python and am currently facing the following question. I have a small program that generates random keys within a defined range. For this I have used the random library. Please bear with me if I have used bad code for this and I am of course happy about corrections or suggestions and hints how to do it better.

Code:

$ cat rand_generator_within_range.py

#!/usr/bin/python3
# generate n keys within specified range
# by citb0in@bitcointalk.org, 2022/11/19
import random
def gen_prvkey():
    low  = 0x000000
    high = 0xFFFFFFF
    return str(hex(random.randrange(low,high)))
counter = 1
while counter <= 10:
    print(gen_prvkey())
    counter += 1

Here are 5 examples of output when I run the program on my computer:

0x7532e18
0x7034239
0x9172e57
0xcffbf6c
0x8b2aae1
0xc2ab798
0x19521ee
0xea443e7
0xf6e445e
0x1932bba

0x78bc5a5
0x6554548
0x48a3554
0x782c14c
0x8932a36
0x68069ab
0xbc701b4
0xb29fa05
0x209db37
0x62599e

0xbbc0afa
0x5eede30
0x8e7799d
0x9d08774
0xbaf7a7d
0x6056a86
0xc4d4863
0xcaf4ded
0x4c83c67
0x3c1310d

0x5348039
0x1e73913
0x3c25c99
0x8f16f1
0x61ca173
0x5dead1b
0x9a9d314
0xf314f8a
0x32af92e
0xec09cde

0xdfcfd55
0x21e1e56
0x927f524
0x3d94474
0xc4c42a7
0xa34b810
0x74ec8f7
0xe91077
0x694504e
0xc9502fd

If at all, at most only one key is generated, which consists of 6 characters. All other generated keys are always in the 7-character range. Why so few 6-characters keys? I don't understand why obviously and clearly keys are generated from the upper range half. I would actually have expected by random generation that the generated keys would be wildly distributed in the specified span. However, randomness does not seem to work well here. Where do I have the thinking or programming error? Looking forward to any helpful answer.

[67890158460000000000]

I have two numbers which I want to do simple addition math with.

Dec / Hex

Number 1 is:
67890123456789012345 / 3AE2A2B962F52DF79

Number 2 is:
35000000000000 / 1FD512913000

If I add decimal values of nr.1 and nr.2 the result is:
67890123456789012345 + 35000000000000 = 67890158460000000000

When I convert this decimal value to hex I get as result:
3AE2A4B6C0147D800

Now I try the same thing but only using the hex values. I use 'bc' tool on Linux for this calculation:

Code:

$ bc

bc 1.07.1
Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006, 2008, 2012-2017 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'.
obase=16;ibase=16
3AE2A2B962F52DF79+1FD512913000
3AE2A4B6B41E40F79

As you see the result differs from the 1th method.
3AE2A4B6C0147D800 != 3AE2A4B6B41E40F79

Then I thought I check online with any of the available hex calculators <https://www.calculators.tech/hex-calculator>
I enter HexValueA=3AE2A2B962F52DF79 plus (+) HexValueB=1FD512913000 and the
Result = 3AE2A4B6B41E40000[/color]
This same result was output by another online hexcalc (https://purecalculators.com/de/hex-calculator)

I got three different results. What the #!R(T$F2M?!?

[Example:]

Is there any tool or python snippet available out there that can split a defined range into equal n parts and outputs the results in hex (omitting the 0x prefix for hex values) but as well as decimal ? It should also work vice-versa, so it should allow inputs in hex or in decimals. When entering 0x it should treat the user input as hex value, in all other cases as decimal value.


Example:
1st argument = start of the range
2nd argument = end of the range
3rd argument = create n equal parts

Code:

./split_range.py 0x1000000 0x2000000 2

User Input Range
Start (Hex): 1000000
End (Hex): 2000000
Span (Hex): 1000000

Start (Dec): 16777216
End (Dec): 33554432
Span (Dec): 16777216

2 Slices for that range

Slice1:

Start (Hex): 1000000
End (Hex): 1800000
Span (Hex): 800000

Start (Dec): 16777216
End (Dec): 25165824
Span (Dec): 8388608


Slice2:

Start (Hex): 1800000
End (Hex): 2000000
Span (Hex): 800000

Start (Dec): 25165824
End (Dec): 33554432
Span (Dec): 8388608

[EDIT:]

Hello everybody,

can anyone run Keyhunt-Cuda in check mode and post his results, please? I just realized that the check outputs an error.

Code:

./KeyHunt -c

KeyHunt-Cuda v1.08


Checking... Secp256K1

Check Generator :OK
Check Double :OK
Check Add :OK
Check GenKey :OK
Adress : 15t3Nt1zyMETkHbjJTTshxLnqPzQvAtdCe OK!
Adress : 1BoatSLRHtKNngkdXEeobR76b53LETtpyT OK!
Adress : 1Test6BNjSJC5qwYXsjwKVLvz7DpfLehy OK!
Adress : 16S5PAsGZ8VFM1CRGGLqm37XHrp46f6CTn OK!
Adress : 1Tst2RwMxZn9cYY5mQhCdJic3JJrK7Fq7 OK!
Adress : 3CyQYcByvcWK8BkYJabBS82yDLNWt6rWSx Failed !
 16S5PAsGZ8VFM1CRGGLqm37XHrp46f6CTn
Adress : 31to1KQe67YjoDfYnwFJThsGeQcFhVDM5Q Failed !
 1CTVCniYaK1sxerz1mpVzwfm2HRWYLfeHV
Adress : bc1q6tqytpg06uhmtnhn9s4f35gkt8yya5a24dptmn Failed !
 1LDMEYi5HfGkZCJqEa4pmY3BXCirjCS5u3
Check Calc PubKey (full) 1ViViGLEawN27xRzGrEhhYPQrZiTKvKLo :OK
Check Calc PubKey (odd) 18aPiLmTow7Xgu96msrDYvSSWweCvB9oBA:OK


Checking... Int

GetBase10() Results OK
Add() Results OK : 357.143 MegaAdd/sec
Mult() Results OK : 30.395 MegaMult/sec
Div() Results OK : 12.346 MegaDiv/sec
R1=1000003D1
R2=1000007A2000E90A1
Field characteristic size: 256bits
ModInv()/ModExp() Results OK
ModInv() Edge cases Results OK
.Avg = 6.13
ModInv() Results OK : 701.034 KiloInv/sec
ModInv() cycles : 3560.44
ModSqrt() Results OK !
IntGroup.ModInv() Results OK : 9.974 MegaInv/sec
ModMulK1() Results OK : 41.672 MegaMult/sec
ModSquareK1() Results OK : 42.508 MegaSqr/sec
ModInv() Cost : 60.6 S
ModMulK1order() Results OK : 5.469 MegaMult/sec

I had discovered a similar issue with VanitySearch and we know that those tools build up on VanitySearch, if I'm not mistaken. Maybe there is a connection. In the VanitySearch thread I posted HERE my finding and how I mitigated the culprit be downgrading. In the next step I was able to pinpoint and eliminate the problem and finally use the latest version of VanitySearch. The problem was in the compiler, see HERE. The fix was to use g++-9 in the Makefile.

I used the same procedure here on KeyHunt-Cuda, that means I am explicitly using g++-9 in its Makefile. But it doesn't help, I still get those errors in the check. Any clues how to fix this? It makes no sense to me using KeyHunt-Cuda without ensuring its working fine. Looking forward to any helpful comment. Thank you.

EDIT:
I'm playing around with keyhunt-cuda and trying to solve puzzle 25 but it doesn't work. Either I'm missing something, doing something wrong, or the program doesn't work reliably. Can someone of you please check this and post the result here?

Puzzle #25

Address = 15JhYXn6Mx3oF4Y7PcTAv2wVVAuCFFQNiP
hash160 = 2f396b29b27324300d0c59b17c3abc1835bd3dbb
Pubkey = 03057fbea3a2623382628dde556b2a0698e32428d3cd225f3bd034dca82dd7455a
Range = 100000-200000
PrivKey = 1FA5EE5

I tried feeding keyhunt-cuda with all three possible files: address in clear-text, address as hash160 and address as hash160 in binary as converted by the supplied python script "addresses_to_hash160.py". I also tried using CPU only or GPU only. It makes no difference, keyhunt-cuda does NOT find the key for that puzzle, whatever I tried so far.

Code:

$ cat 25_addr.txt
15JhYXn6Mx3oF4Y7PcTAv2wVVAuCFFQNiP

$ cat 25_addr_hash160.txt
2f396b29b27324300d0c59b17c3abc1835bd3dbb

$ cat 25_addr_hash160.bin
/9k)�s$0
Y�|:�5�=�

I tried following command variations:

Code:

./KeyHunt -t 0 -g --range 1000000:2000000 -m address -i 25_addr_hash160.bin

Code:

./KeyHunt -t 0 -g --range 1000000:2000000 -m address -i 25_addr_hash160.txt

Code:

./KeyHunt -t 0 -g --range 1000000:2000000 -m address -i 25_addr.txt

Code:

./KeyHunt -t 4 --range 1000000:2000000 -m address -i 25_addr_hash160.bin

Code:

./KeyHunt -t 0 -g --gpui 0 --gpux 256,256 --range 1000000:2000000 -m address -i 25_addr_hash160.bin

I even tried wider ranges, like ...

Code:

./KeyHunt -t 0 -g --range 10000:200000000 -m address -i 25_addr_hash160.bin

It works only when provided with the address in the command line, e.g:

Code:

$ ./KeyHunt -t 0 -g --gpui 0 --gpux 256,256 -m address --coin BTC --range 1000000:2000000 15JhYXn6Mx3oF4Y7PcTAv2wVVAuCFFQNiP

Conclusion --> KeyHunt-Cuda in single address mode requires an address as input, it does not work with a hash160 no matter if its binary or not.

However my first part of this post and the question "Why does Keyhunt-Cuda check throws errors", still remains.

[15]

Hi all,

to what extent can the performance and the hit probability of these two tools be compared and what significance do they then have?

For example:

- we run Kangaroo in multi-GPU mode on several modern GPUs and achieve a displayed speed of 15 GKey/s

- we run keyhunt in BSGS mode on 8 CPU threads with about 16GB RAM allocation and get about 80 PKey/s.

Is Kangaroo with multi-GPU usage more advantageous and more likely to get a hit, even though keyhunt with CPU usage in BSGS can process 80 PKey/s?

From this numerical example, one would think that keyhunt with the 80 PKey/s would have to be worlds better. But is that the case or is it not possible to compare this at all and the given speed rates are completely useless for the comparison?

In terms of software development, what is the most efficient and performant way to generate the derived three bitcoin addresses ( uncompressed 3..., compressed 1..., segwit bc1q... ) from a private key? If you have only a handful of private keys, you can do it with all conceivable and available bitcoin tools out there. But if you have a million private keys, what is the fastest way to fulfill this task, what do you suggest? is there any python snippet you're aware of ? Thank you