I am sure I am not the first one for whom this thought crystalized so clearly, and I think Michael Saylor did say something along these line...

If there was a time machine which could take you into the future, but only you and none of the other things including your cash, your gold, your smartphone/computer, and not even Bitcoin. But then you realize that all you have to do is take yourself into the future while your Bitcoin will travel into the future all by itself, and will be there waiting for you.

Just something I felt like sharing with others.

Bitcoin market cap is about $2T as of today. All world assets are valued at around $900T today. Let's say in 30 years this number may climb to $10,000T due to money printing.

In extreme case, Bitcoin may capture all world assets, and therefore its market cap may increase 5000 times - from $2T to $10,000T. [ I disregard 1.3 million additional Bitcoin left to be mined on top of existing 19.7 million Bitcoin already in circulation because this entire calculation is so imprecise]

At roughly $100,000 per BTC, today 1 sat = $0.001. If in 30 years BTC price increases by the factor of 5000 then 1 sat = $5 in remote future.

30-50 years ago, you could buy something for 5 cents, but now 5 cents is worth almost nothing. Similarly, $5 will be worth very little in 30 years, and therefore there may be no need to subdivide 1 sat into smaller chunks.

Even if LN fees get very small and measured in fraction of a sat (which I believe is already the case), there is nothing wrong in using fractional sat, milli-sat, or even micro-sat similar to how in metric system we use fractional meter, millimeter, and micrometer.

There seems to be no good reason to make drastic changes, especially considering the fact that BTC and sat units have been widely adopted, cause no confusion, and honor Bitcoin creator.

What is reasonable is to implement fractional sat (e.g. 0.2 sat), milli-sat, and micro-sat.

Just my two sats... LOL

This is encouraging - a few recent solo mined blocks, with the most recent one mined by 0.5 TH/s miner (there is a thread about it on the board). Go to mempool.space, type "solo" in the search field, and pick 'Solo CK'.

887212   ‎2025-03-10 15:22:04

881676   ‎2025-01-31 14:40:16

875750   ‎2024-12-21 11:15:27

871258   ‎2024-11-20 18:32:47

Hey -ck, could you reply to post #5392.

Wow! Congratulations to the lucky one!

Since we are on the subject, could someone explain the meaning of the following parameters in bold for my LV07:

"hashrate1m": "1.45T",
 "hashrate5m": "1.18T",
 "hashrate1hr": "1.07T",
 "hashrate1d": "1.03T",
 "hashrate7d": "893G",
 "lastshare": 1741637207,
 "workers": 1,
"shares": 301228264,
 "bestshare": 5021642.977807073,
 "bestever": 245888437,
 "authorised": 1740352205,

My LV07 shows 85,490 shares, and 246M all time best difficulty which is consistent with "bestever: 245888437" number above.

Got it. Thanks.

To clarify, here is the recent snapshot from the pool:

=====================================
solo.ckpool.org/users/bc1bla-bla-bla

{
 "hashrate1m": "1.19T",
 "hashrate5m": "1.06T",
 "hashrate1hr": "1.01T",
 "hashrate1d": "1.02T",
 "hashrate7d": "873G",
 "lastshare": 1741555965,
 "workers": 1,
 "shares": 281621832,
 "bestshare": 245888437.7731853,
 "bestever": 245888437,
 "authorised": 1740352205,
 "worker": [
  {
   "workername": "bc1bla-bla-bla",
   "hashrate1m": "1.19T",
   "hashrate5m": "1.06T",
   "hashrate1hr": "1.01T",
   "hashrate1d": "1.02T",
   "hashrate7d": "873G",
   "lastshare": 1741555965,
   "shares": 281621832,
   "bestshare": 245888437.7731853,
   "bestever": 245888437
  }
 ]
}

====================================

Here is the info from the miner admin screen:

Model:   LV07
Uptime:   3 days
WiFi Status:   Connected!
Free Heap Memory:   8420560
Version:   1.2.0

Hash Rate
1.13 TH/s

Shares
65,400

Efficiency
19.56 J/TH

Best Difficulty
246M all-time best

============================

I am confused, and trying to reconcile different numbers. Here is what I mean.

1. My miner says it submitted 65,400 shares in roughly 3 days. Sounds about right - corresponds to around 15 shares/min. But the pool says: 281621832 shares. What?

2. Watching log file: minimum difficulty was 971, and I've seen actual difficulty around 1500 - 2000 - 3000. However, both the miner and the pool refer to 246M as all time best (the miner) and 245888437 (the pool). For comparison, recent block 887080 has difficulty of 112,149,504,190,349, or roughly 112T.

As an exercise, I did calculate minimum hash value for bits 0x17028281, checked a few blocks, and verified that their hash value was less than the minimum set by the bits, while the spread for about 10 blocks I checked was within that range and was clearly somewhat random. I also divided 00FFFF... value (for difficulty 1) by the actual hash for a couple of blocks, and got the same difficulty number (around 112T) as specified for each block. So, aside from inconsistencies above, I am getting a decent handle on basic understanding.

Ugh.. Hmm.. A bit confused. I think I am missing something. I just watched my LV07 submit 8739 shares to ckpool in 1 minute, and it's been doing that consistently - this is what the pool shows (not the miner). This is a lot more than 18 shares from the example above. However, my hash rate (displayed by both, the pool and the miner) is around 1 TH/s.

Also, where did the number 8190 come from? Maybe it should be 8192 (2^13). But then, why 2^13?

On the other hand, miner itself shows 1 share about every 2-3-4 sec - which is consistent with 18 shares/min.

Here is the fragment of the miner log, which is consistent with about 18 shares per minute while watching it in real time:

₿ (149791716) asic_result: Ver: 2CAD2000 Nonce 6504004D diff 498.6 of 971.
₿ (149792476) asic_result: Ver: 2197C000 Nonce F31C000D diff 1494.4 of 971.
₿ (149792476) stratum_api: tx: {"id": 36816, "method": "mining.submit", "params": ["bc1rqk-bla-bla-bla", "67444bb00004c2b8", "0b1a010000000000", "67cc3f06", "f31c000d", "0197c000"]}
₿ (149792676) stratum_task: rx: {"result":true,"error":null,"id":36816}
₿ (149792686) stratum_task: message result accepted

I understand some of it, but would be nice to understand more:

a) minimum difficulty is set by the pool to be 971. Is it 971 times more difficult than the base difficulty of 1?
b) the first result is ignored because its hash's difficulty of 498.6 is below the set limit of 971.
c) nonce F31C000D is transmitted to the pool as well as the verification 2197C000 (although verification was transmitted as 0197c000).
d) the result was accepted by the pool.

What do the other numbers mean?

Interesting! Thank you. That could explain why re-plugging the coax cable could clear internal log of saved packets.

I don't have logging feature on my admin screen provided by my ISP, but will try calling them and asking whether there is any option like that which they can control on their end. I am reluctant to tell them what I am running, so will have to just tell them something generic.

Oh... One more question that I am not able to find an answer to. How the pool knows my hash rate if my miner only submits lower difficulty hashes it manages to find. Does the pool just estimate my hash rate based on that information?

LOL, I think I am good for now. Thank you guys for all detailed explanations.

Pretty amazing how it all works together, and how well it is all thought through. As a software developer of many years, I can only appreciate the beauty of the thing.

Now, back to my Lucky Miner which is stuck at 246M difficulty, LOL

Oh, another but unrelated question. Maybe someone gives me an idea what's going on...

My Internet speed is 300 Mb/s download and 20 Mb/s upload (was 20/20 before the upgrade - see further below). A few months ago, I set up a node. Right off the bat, my router (or external network) would start freezing after a day or a few. Specifically, connection to router for all home devices is fine, but no traffic goes though (including to/from the node). Rebooting the router clears the problem - until next time - in a day or a few. I also discovered that there was no need to reboot the router. Unplugging coax cable for a few seconds does the trick, and everything goes back to normal in a few seconds.

Never happened before I set up my node. If I shutdown the node, everything is fine for days and days. Started the node - same issue.

Upgraded to the newest router from ISP - same issue. Asked my ISP if there was a quota for uploads. They said NO.

Via experimentation, I determined that limiting upload to 5GB/day solves the problem - runs smoothly for weeks with no issues.

Any ideas?

That was helpful. Thank you. It is now clear that two miners side-by-side would be using completely different inputs.

But what about ALL MINERS in the world? Is the number of different "sig" variations great enough so that each pool changing "sig" in a certain way leads to unique inputs for each miner across the board? I am guessing it is because mempool.space shows ScriptSig to be about 100 bytes in size, of which I am guessing about 90 bytes could be anything, and that's 2**180 - huge number. I guess I answered my own question.

Completely different question... I remember reading something along the lines that a new block cannot be mined 2+ hours ahead of most recent block at the top of the blockchain. What happens when 12 freshly mined blocks are mined faster than in 2 hours? Do miners all over the world stop and wait until some time passes in order not to violate that rule? In other words, what happens to all miners if blocks are mined a little too fast for a few hours?

Thank you for the detailed replies. After I read everything, and played with illustrations, I still cannot answer a simple question:

If I have two identical ASICs sitting in a room, pointed to the same pool, and using the same connectivity - will they be following the same sequence of input parameters? If not, who and how makes them different?

1. How does a pool know miner's hash rate? I know miner sends easier successful hashes (shares?), but that's not a direct hash rate.

2. What inputs are used for hashing? I've read about Nonce, timestamp, extra Nonce.

3. What is the algorithm for input variations?

4. Is there a random element in how input variations are determined so that two identical miners do not follow the same input sequence? Because if there isn't then they would arrive at exactly the same sequence of hashes, and therefore a miner with better Internet connection (less latency) wins.

5. I am guessing that there is randomness. In this case, is there a chance that the same combination of input parameters may be repeated, thus wasting valuable hash rate? Or is the number of combinations of input variations is so great that there is little chance of that happening?

6. Why hash rate keeps fluctuating? E.g. for my LV07, it averages 1.0TH, but fluctuates between 0.85TH - 1.2TH.

7. My LV07 frequency is set to 575 MHz. It generates around 1.0 TH. This means that during every tick the ASIC calculates (1.0 Th / 575 MHz) = 1739 hashes. How is that possible? Each hash is a complex calculation, and doing 1739 of them in a single tick!?! A regular CPU may execute a simple operation in a single tick - like moving data from register to memory, or perform an addition, etc.

What's up, gang? I did a quick search, and was unable to find satisfactory answer.

My main objective is to contribute to decentralization of Bitcoin mining, and not making money. If I end up making a few dollars a day, that's cool. Or, if I mine solo for a small chance to win a block within a few years, that's cool, too.

I am in the area with electricity cost of $0.25/kWh, not to mention I don't want 'them' to know, hence using solar is a good choice. I am guessing I could generate a few kWh/day, and I am guessing could run solo rig for a couple of hours per day.

I don't want to waste time on experimentation. Most likely, someone already knows what would be a reasonable setup. My budget is about $2000 for initial setup, and have space for around 20 sq ft for solar panels. Have small shed outside to store ASIC/battery.

Please point me in the right direction. Thanks.