Using AxeOS latest version

Version:   v2.6.5
ESP-IDF Version:   v5.4
Board Version:   204

The best share was found since the last block find as I try reset each time so the best share of 600m should be showing on the pool.

https://solo.ckpool.org/users/bc1qtesc50ye5euqtr67sdqke8xdwef6klasc5vx59

Missing a best share on here.

Should be 600m like the image.

I think there is a issue CK.

I now have 2 miners and 1 of my own saying there best shares are not showing on the pool.

I can share one of mine is not showing the correct best share.





Best share is not the same as shown in the miners.
Also can't think of any reason why one miners best share after a block find would not reset and others best shares are not being reported.
If needed I have more images and this is not just a issue for me another miner who is mining on the pool has the same missing best share.

Did you change something on the pool?
The fact is it's not just 1 issue here or just 1 person its multiple issues and not the same people which leads me to think pool issuse.


https://solo.ckpool.org/users/bc1qa8r4up9nchkvdnhcf9feexv2jfantrk48ef374

Defo not right that the block finders best share didn't reset everyone elses did and now we have multiple users claiming there best shares are not being reported.

Please have a dig CK something is wrong.

Best Regards!

Why has his best share not re-set? 

Soon as a block is found my one starts again but this one still says his best share is the one that found the block? 

You should make a back up of the file before trying anything on it
this is always advised just incase something happens.

If you think you know the password you could try decrypt the file and output the contents with

You could also give this command a go see if there is a secret key for the file


If the file was encrypted with a symmetric cipher (passphrase only, no public/private key),


If you still have no luck you could try export the packets and see if they hold any additional information


Another good solution is PGPDUMP


If you have or can recover the private key associated with the key ID (5EB…)


If you still unsure you could try bruteforce it with gpg2john

gpg2john recovered_file.gpg > hash.txt
john hash.txt

This will convert the GPG file’s passphrase hash into a format compatible with John the Ripper for brute-forcing.

Good luck!

Ahh I thought there may have been some method to the number.

Thanks CK and Nexus9000 for the reply

I'm blocked by most people so that defo is not me. 

Luke = Blocked me
Lopp = Blocked me
Todd = Blocked me

Probably some others too.  Seem to be the way they shhhh anyone trying to raise any concerns.

if Liquid can have a side chain why can't we just have a data sidechain? Is ir really that hard keep Bitcoin main chain for UTXO's transactions and money based and have a side chain.  Litecoin runs many side chains no issue.  Why Bitcoin can't just do the same is beyond me.

The overall consensus I fell is users do not want this change to occur, granted they may not be well informed on the matter or understand the nature of the changes as not everyone is a tech guru or coder out there we must keep this in mind. 

Rather than lets have another big fall out over some changes lets find soltutions that fit and work and keep bitcoins core finance.  If you really need or want data do it on a side chain.  Why the need to have the data in the main bitcoin blockchain is beyond me.

BuT BrUh MoNkEy JpEg LoOkS cOoL is not a reason.

In some respects yes but in others still have concerns that it might lead to bigger problems later.

Like any big change there is always going to be sketical side and the arguments about it pushing users off the network is always valid imo.

https://prnt.sc/lpI2lKmt0X6L

I mean at this point we are already reaching into the $2000+ a year for running a full node block generator or not if size runs away this could cause some run away growth leading to increased cost for many.

We should always be looking to cater to the many rather than the few in my view and this change is for the few not the many.

Thanks for the reply raise some good points.

Regards.

So the removal of OP_RETURN size limit will allow for larger data payloads to be embedded into Bitcoin transaction, which potentally could lead to significant increase in the blockchain size, unlike witness data wich can be pruned in segwit tx's the OP_RETURN data is stored in the UTOX set which will lead to permanent bloat as the blockchain grows. Increaing computational requrements storeage and bandwith to run a full node.

This could price out individuals and smaller users from running full nodes dew to increased cost or higher hardware cost. The effect of this could lear to fewer nodes and have a impact on the decentralization of the network.  A less decentralised network is more vulnerable to censorship, collusion or controll by a small set of well-resouced bad actors. Miners or corporations. 

The pull request acknowedges that some parties are already store data in unspendable output adding bloat to the UTXO set, but also argue that OP_RETURN is less harmfull of a alternative.

However, removing the limits entirely risks exacerbation of the problem rather than a mitigation of it.

Many will claim that data anchoring is inevitable and that OP_RETURN is more efficient way to handle it compared to fake addresses or unspendable outputs.  But the argument that the market for block space will naturally regulate use via fees.  This assumes miners prioritize long term netork health over the short term fee revenue which isn't guaranteed, especially given the pull request not that major miners already bypass these limits for profit.  As many see it Bitcoin core's streanth lies in its simplicity and stablilty which minimize attack surface and ensure long term reliablity.  Removing OP_RETURN limits and associated configuration option such as -datacorrier and -datacarriersize introduce new code paths and behaviours than mist be tested and maintained.

Larger OP_RETURN outputs could amplify existing attack vectors, such as mempool spam or flood-and-loot attacks, as noted by commenter Brazy Development in the pull request.

An attacker could flood the mempool with large OP_RETURN transactions, increasing memory and bandwidth demands on nodes. While nodes have resource management tools (maxmempool size, minimum relay fees ect), these are tuned for typical transaction patterns.  Massive OP_RETURN payloads could push smaller nodes to their limits, delaying transaction processing or causing nodes to crash. Attacks could also cause some disruption the network’s reliability, increase transaction fees, and disadvantage smaller miners who rely on efficient block propagation. The pull request notes that slow block propagation caused by non-relayed transactions getting mined already benefits larger miners, and removing OP_RETURN limits could exacerbate this by enabling more data-heavy transactions.

Proponents such as James Lopp are giving the argumentthat the market for block space and existing node defenses like fee based eviction mitigate these risks. It's being claimed attackers would face high economic costs. However, a well funded attacker like a state actor or competitor chain could absorb these costs to destabilize Bitcoin, and smaller nodes would bear the brunt.  The frustration everyone feels with developers “playing with people’s money” by adding complexity is a common sentiment among Bitcoin maximalists. The pull request’s proponents, like petertodd, argue that OP_RETURN limits are already bypassed and cause harm (UTXO set bloat from fake addresses), but their solution removing limits entirely feels like a capitulation to non monetary use cases rather than a defense of Bitcoin’s core principles.

Why we are not focused on more payment solutions and being the money anymore is beyond me.

What once was is no longer and this could be the very turning point many had the fear would come.

Don't forget where we came from and don't make changes that could damage the nature of the network.

But hey. What do I know.

So what is the point of only 18 shares per min?  Surly with such a beefy pool we should be able to sumit way more shares.

Something that has puzzled me about the diff and pools for time is why restrict us to such a low value of share per min.

18 is hardly a drop in the ocean compaird to the power of the server.

If there is no serious load then why limit to 18 shares per min? 

Would this not also have some effect on the time expected for a block?
If you are exected to solve a block when your shares are on par with network diff then it would take approximately 13 million years to submit 123 trillion shares at 18 shares per minute.

That cannot be correct. 

No good can come from this.

Feels like another attack on Bitcoin.

Can we just get back to being the money again?

Thanks

Here is a quick breakdown of how it works or how I think it works 

MakeNewKey calls OpenSSL’s EC_KEY_generate_key function to generate a new private-public key pair for the secp256k1 curve.


It then steps inside the EC_KEY_Generate from OpenSSL it then generates a random number between 1 and the order of SECP256k1 this number is the private key.

It then multiples the curve base point (G) which is a fixed point on the secp256k1 curve.  the output will be points X,Y on the curve which is the public key. 

Both the private key stored as a scalar and the public key as a point are in the pkey object.



It then Initializes a new EC_KEY object with the 256k1 curve in NID_secp256k1 in OpenSSL



It then converts the private key to DER format with i2d_ECPrivateKey and returns it as CPrivKey wich is a vector of bytes with a secure allocator.  Typical size being 279 bytes and incluses metadata and the 32 byte private key.



GetPubKey converts the key to byte vector using the i2o_ECPubKey format would be uncompressed 65 bytes and start with 0x04 and followed by the 32 byte X and the 32 byte Y coordinates

Other things to look at might be CBigNum which is a wrapper around OpenSSLs BIGNUM it's not used in key generation but is used in other cryptographic op's

BigNum handles large integers (keys, hashes, ect)
Provides a mehtod to convert between formats hex, binary and uint256.
Use for signing and verification ie manipulation of the hash in Sign and Verify.

1. Make a key


2. Get PK



3. Generate Pub Key


4. Hash pubKey to create the address.

5. User privKey to sign the TX.

You might want to poke over the early source code since bitcoin early codebase is not that extensive not too hard to pull it apart.

Can I ask why your looking for these things? seems interesting!   

Good luck.

You might want to start with a early version of Bitcoin if your looking to make changes.

The later versions are not suitable for a new blockchain.

If you are looking to make changes and mine a new chain I would do so in a VM with older versions of Bitcoin bitcoin-0.10.0.tar.gz is a good one for making altcoins with.  Just be aware the packages used and code DO have security issues so local VM with no internet for the build is advised.

Once you have created your chain and mined some blocks you can then start for forward port the software the real issue is Bitcoin today is just not as suitable a codebase for making new chains.

Your numbers do not add up for HEX64.

yea ok VOD lets just let them keep gettiing away with this spam will we...

And yes my spelling is terrible I have issues...
Don't move the subject off the spam comments thanks and stay away from personal attacks.

1. a lot more than you have ever done that is for sure..
2. and stealing coins just because "You think you can" is not a excuse to do so..
3. There is no "criteria" for a lost wallet your just trying to justify stealing..   If a bank keeps a gold bar for 30 years in a valut don't mean you can break in and steal it because it has dust on it and has not moved for time..

Legit your rat theif and not welcome here.. -1 trust for being a scumbag and trying to convince people YOU know there coins are lost.

How fooliish.

Why do all these OPs assume the coins are lost and just not being held by the users.

Just because something don't move don't make it fair game...

At this point the forum should really stop allowing these types of cracking hacking stealing topics.

YOU have no proof the coins that have not moved are lost.  ZERO proof...

The mainstream are semi-floating the idea becase they would love nothing more than to do something to try "recover" the "LOST" (or sleeping) coins.

These topics are nothing more than brute force attemts on other people property.

Build something usefull....Not destructive.

What is this crap... Why are there so many new accounts posting absolute bullshit..

What is worse your replying to it to boost your comments.

This is clearly a AI generated post.. 

Either your farming your ROOBET affliliate link or your dumb..