1800 😮 — Now that is a variance number for sure!

I think the drops can also be mining on 4334 if the miners don't find a share over 1m for some time the hashrate drops.
Miners didn't disconnect they just didn't submit anything in that period that was above 1m Diff.

I also wondered about the runs and realised this can be something to do with 4334 rather than miners not being connected or leaving.

I testing with 500gh/s on 4334  you will see your hashrate shows dropping by the pool when the machines are not submitting shares 1m diff or higher.

So looks a bit like disconnection.  But I think in the background the machines are still working it's just artifact of high diff share attempts.

Actually they do if you have law enforement contact them. You need to be fast though and normally the authoritys have no clue about crypto in general but I have had sucesss in recovering close to 100k over the last 3 years for people with fast reporting and the person who lost the fund sending the corrospondence.   Few of the cased the funds were frozen and took 3-4 months before they were released but they are paying attention and they do freeze accounts if the correct law enforcement response happens quickly enough.

Not only that these accounts are KYC'd so one slip up from the theif and its game over for them.

Not to mention they lose there accounts.

Tracking Report Updated.

https://www.breadcrumbs.app/reports/11165

Looks like the address has seen funds from Kraken and sent to Binance and done swaps for WETH.



You should contact the exchanges and send them the breadcrumbs link and let them know your funds are being sent in.
Maybe the person has KYC so you could also report the stolen funds and give them the information of the exchanges linked to the address.

How did you lose the funds private key leak? Malware? Interaction with some shitcoin contracts?  

Hacker address is in the center showing incoming transaction and outgoing transactions.

They moved USDT to Binance and others listed.


Feel free to update the report it's public with more information.

Looks like you have a few issues.

Multiple entries like check_asic_number_with_power_on showing inconsistent ASIC counts (from 1 to 24 to 0).

The voltage readings and adjustments appear to be fluctuating.

The log ends with ERROR_SOC_INIT and stop mining: soc init failed!, indicating a system-on-chip initialization failure.

Check your PSU is not on dying this can be a issue with voltage.  Ensure all power and data cables are securely connected. Loose connections can lead to intermittent ASIC detection.

Verify that the power supply is stable and providing consistent voltage. Fluctuations in power can lead to initialization failures.

Have you over/under clocked the device?  

Are you using the Bitmain firmware?

You could try re-install the firmware see if this works.

https://shop.bitmain.com/support/download

If this fails you may have a faulty board and may need repair.

Actually I believe OP_CAT is required for many reasons outlined below some which people may or may not have thought about.
Below is a draft of ideas for why OP_CAT should come back.

This proposes the re-introduction and standardization of the OP_CAT operation in Bitcoin Script. OP_CAT concatenates two stack items and can significantly enhance the flexibility and functionality of Bitcoin scripts. By allowing scripts to combine multiple data elements directly on the stack, OP_CAT can streamline complex operations, reducing the need for more convoluted and error-prone workarounds. This proposal details the opcode's utility through four specific use cases: multi-signature time-locked escrows, conditional multi-party agreements, atomic swaps, and proof-of-ownership verifications. These examples demonstrate the enhanced capabilities and efficiencies that OP_CAT can bring to Bitcoin scripting, enabling more sophisticated financial contracts and decentralized applications.

Motivation
Bitcoin Script currently lacks a native concatenation operation, significantly limiting its capability to handle complex conditional logic efficiently. The absence of OP_CAT forces developers to rely on more cumbersome and error-prone methods to achieve similar outcomes. This not only increases the risk of scripting errors but also makes scripts more challenging to audit and maintain, reducing overall script reliability and security. The re-introduction of OP_CAT would enable more sophisticated scripting possibilities, thereby supporting a wider range of financial contracts and decentralized applications. By simplifying the concatenation process, OP_CAT can enhance the expressiveness of Bitcoin scripts, making it easier to implement advanced features such as atomic swaps, multi-party agreements, and time-locked contracts. These capabilities are essential for creating innovative decentralized financial products that can operate efficiently on the Bitcoin network.

Advanced scripting possibilities brought by OP_CAT will foster innovation within the Bitcoin ecosystem. For example, atomic swaps, which enable the exchange of different cryptocurrencies without a trusted third party, can be implemented more efficiently. Multi-party agreements, which require more complex conditional logic to ensure that all parties' conditions are met before a transaction is finalized, can also be simplified. Time-locked contracts, which control the timing of transactions, will benefit from the more straightforward implementation of concatenated scripts.

Moreover, this proposal addresses the security concerns associated with the original OP_CAT operation. The re-introduced OP_CAT includes robust error handling and validation measures to ensure secure and reliable script execution. These measures are designed to prevent the vulnerabilities that led to the initial removal of OP_CAT, providing a secure environment for advanced scripting.

This expansion of scripting capabilities is crucial for the continued evolution and adoption of Bitcoin as a programmable digital currency. As Bitcoin aims to compete with other programmable blockchain platforms, enhancing its scripting language is essential to attracting developers and fostering a vibrant ecosystem of decentralized applications. By making Bitcoin Script more powerful and versatile, OP_CAT can play a significant role in enabling new use cases in decentralized finance, thereby driving the next wave of Bitcoin innovation.

In summary, reintroducing OP_CAT to Bitcoin Script addresses current limitations, enhances script expressiveness, supports advanced financial contracts, and ensures secure execution. This proposal not only fosters innovation and broadens the range of possible applications but also aligns with Bitcoin's ongoing evolution as a leading programmable digital currency.

Specification


Use Cases

Multi-Signature Time-Locked Escrow
Alice deposits funds into an escrow that Bob can access if both Alice and Bob sign off, or Charlie can arbitrate if needed. If a certain time passes without resolution, funds automatically return to Alice. This complex conditional transaction is efficiently managed using OP_CAT to concatenate and evaluate conditions based on signatures, public keys, and a locktime.

In this scenario, Alice wants to ensure that her funds are secure in an escrow arrangement that can only be released under specific conditions. Here’s how the script is structured to manage these conditions:

Initial Stack Setup:
The stack starts with Alice’s signature (sig1), Bob’s signature (sig2), Alice’s public key (pubkeyA), Bob’s public key (pubkeyB), Charlie’s public key (pubkeyC), and the locktime.

Condition 1: Alice and Bob Agreement:
The script first checks if Alice’s public key matches the provided key.
If Alice’s key matches (OP_DUP <pubkeyA> OP_EQUAL), the script proceeds to check Bob’s public key.
If Bob’s public key matches (OP_DUP <pubkeyB> OP_EQUALVERIFY), the script then uses OP_ROT and OP_CAT to concatenate the signatures and compare with the locktime.

OP_ROT rotates the top three stack items, placing sig1 and sig2 in the correct positions.
OP_CAT concatenates sig1 and sig2, creating a single data item for comparison.

Locktime Check for Alice and Bob:
The concatenated signatures are then compared with the locktime (OP_GREATERTHAN).
If the combined signatures are valid and the locktime condition is satisfied, the script validates the signatures (OP_CHECKSIGVERIFY and OP_CHECKSIG), allowing Bob to access the funds.

If the signatures do not meet the locktime condition, the script checks if Charlie’s hash matches (OP_HASH160 <CharlieHash> OP_EQUAL), allowing Charlie to arbitrate.

Condition 2: Charlie as Arbitrator:
If the initial check for Alice’s key fails, the script checks if Charlie’s key matches (OP_DUP <pubkeyC> OP_EQUALVERIFY).
If Charlie’s key matches, the script proceeds similarly by rotating the stack and concatenating the conditions.
The locktime is then checked to see if it is less than the current block time (OP_LESSTHAN).
If Charlie’s signature and the locktime condition are valid, Charlie can sign and release the funds (OP_CHECKSIGVERIFY).

Return Funds to Alice After Locktime:
If none of the above conditions are met, the script defaults to returning the funds to Alice after the locktime expires.
This is handled by duplicating the locktime and verifying it against the current block time (OP_DUP <locktime> OP_CHECKLOCKTIMEVERIFY).
If the locktime condition is met, the script drops the locktime from the stack (OP_DROP) and verifies Alice’s key (OP_DUP <pubkeyA> OP_EQUALVERIFY).
Finally, Alice’s signature is checked, and if valid, the funds are returned to her (OP_CHECKSIG).


Conditional Multi-Party Agreement
Alice, Bob, and Charlie enter into an agreement where funds are released based on the concatenation of conditions set by any two of the three parties. This setup can be particularly useful in complex business transactions, joint ventures, or any scenario where the approval of multiple stakeholders is required before releasing funds. This script demonstrates how OP_CAT can be used to concatenate and evaluate conditions efficiently.

Initial Stack Setup:
The stack initially contains two conditions (cond1 and cond2), and the public keys of Alice (pubkeyA), Bob (pubkeyB), and Charlie (pubkeyC).
Conditions can represent various requirements such as specific signatures, hash pre-images, or other data necessary for the transaction.

Condition 1: Alice and Bob Agreement:
The script starts by checking if Alice’s public key matches the provided key using OP_DUP <pubkeyA> OP_EQUAL.
If Alice’s key matches, the script then checks if Bob’s public key also matches using OP_DUP <pubkeyB> OP_EQUALVERIFY.
If both keys match, indicating that Alice and Bob are in agreement, the script rotates the top three stack items using OP_ROT to prepare for concatenation.
OP_CAT is used to concatenate cond1 and cond2, forming a single condition.

The concatenated condition is then compared with a pre-agreed value (<condition>) using OP_EQUAL.
If the condition is met, the script verifies the signatures of Alice and Bob (OP_CHECKSIGVERIFY and OP_CHECKSIG), allowing the funds to be released.
If the concatenated condition does not match, the script checks if Charlie’s hash matches (OP_HASH160 <CharlieHash> OP_EQUAL), which can be a fallback mechanism for arbitration or an additional condition.

Condition 2: Alice and Charlie Agreement:
If the initial check for Alice’s and Bob’s keys fails, the script proceeds to check if Charlie’s public key matches (OP_DUP <pubkeyC> OP_EQUALVERIFY).
If Charlie’s key matches, indicating that Alice and Charlie are in agreement, the script again uses OP_ROT and OP_CAT to concatenate the conditions.
The concatenated condition is compared with the pre-agreed value (<condition>) using OP_EQUAL.

If the condition is satisfied, Charlie’s signature is verified (OP_CHECKSIGVERIFY), allowing the funds to be released.

Fallback Mechanism:
If neither of the above conditions are met, the script includes a fallback mechanism to ensure that the funds can still be managed securely.
This involves checking the condition against a locktime using OP_DUP <condition> OP_CHECKLOCKTIMEVERIFY.
If the locktime condition is met, the script drops the condition from the stack (OP_DROP) and verifies Alice’s key (OP_DUP <pubkeyA> OP_EQUALVERIFY).

Finally, Alice’s signature is checked, and if valid, the funds are returned to her (OP_CHECKSIG).


Atomic Swap
Alice and Bob wish to perform an atomic swap, exchanging assets on different blockchains without the need for a trusted intermediary. Each party must provide a secret, and when these secrets are concatenated and hashed, they verify the transaction. This script outlines the conditions necessary for the atomic swap to occur securely using OP_CAT.

Initial Stack Setup:
The stack begins with Alice’s signature (sig), Alice’s public key (pubkeyA), Bob’s public key (pubkeyB), Alice’s secret (secretA), Bob’s secret (secretB), and the hash of the concatenated secrets (hash).

Alice and Bob Agreement:
The script starts by checking if Alice’s public key matches the provided key (OP_DUP <pubkeyA> OP_EQUAL).
If Alice’s key matches, the script proceeds to check if Bob’s public key also matches (OP_DUP <pubkeyB> OP_EQUALVERIFY).
If both keys match, indicating Alice and Bob's agreement, the script rotates the top three stack items to prepare for concatenation (OP_ROT).
OP_CAT is then used to concatenate Alice and Bob's secrets (<hash> and <secretA>) to form a single hash.
The concatenated hash is compared with the pre-agreed hash value (OP_EQUAL).

If the hash values match, the script verifies Alice's signature, allowing the swap to proceed (OP_CHECKSIGVERIFY).

Bob and Alice Agreement:
If the initial check for Alice and Bob's keys fails, the script proceeds to check if Bob's public key matches (OP_DUP <pubkeyB> OP_EQUALVERIFY).
If Bob's key matches, indicating Bob and Alice's agreement, the script again rotates the stack and concatenates the hash with Bob's secret (<hash> and <secretB>).
The concatenated hash is compared with the pre-agreed hash value (OP_EQUAL).
If the hash values match, Bob's signature is verified, allowing the swap to proceed (OP_CHECKSIGVERIFY).

Fallback Mechanism:
If neither of the above conditions is met, the script includes a fallback mechanism to ensure that the swap can still occur securely.
This involves checking the hash against a locktime using OP_DUP <hash> OP_CHECKLOCKTIMEVERIFY.
If the locktime condition is met, the script drops the hash from the stack (OP_DROP) and verifies Alice's key (OP_DUP <pubkeyA> OP_EQUALVERIFY).

Finally, Alice's signature is checked, and if valid, the swap proceeds (OP_CHECKSIG).


Proof-of-Ownership Verification
In this scenario, a user needs to prove ownership of multiple linked assets by providing concatenated ownership proofs and a combined hash for verification. This script outlines the process of proving ownership using OP_CAT and verifying the combined hash.

Initial Stack Setup:
The stack initially contains the user's signature (sig), the user's public key (pubkey), ownership proof for asset A (proofA), ownership proof for asset B (proofB), and the combined hash of the ownership proofs (combinedHash).

Ownership Verification:
The script starts by verifying that the provided public key matches the expected key (OP_DUP <pubkey> OP_EQUALVERIFY).
It then rotates the stack and concatenates the ownership proofs (proofA and proofB) to form the combined hash (OP_ROT OP_CAT <combinedHash> OP_EQUAL).

If the concatenated hash matches the pre-agreed combined hash value, the script proceeds to check the user's signature (OP_IF OP_CHECKSIG).
If the signature is valid, ownership of the linked assets is confirmed.

Fallback Mechanism:
If the concatenated hash does not match the expected value, the script includes a fallback mechanism.
This involves hashing the combined hash and comparing it with a pre-calculated hash (OP_ELSE OP_HASH160 <combinedHash> OP_EQUAL).
If the hashed combined hash matches the pre-calculated hash, the script proceeds to signature verification (OP_CHECKSIG).
If the verification is successful, ownership of the linked assets is confirmed.


Rationale
The reintroduction of the OP_CAT operation is a strategic enhancement to Bitcoin Script that addresses current limitations in scripting capabilities by allowing the concatenation of stack items directly within the script. This fundamental operation is crucial for a variety of reasons, each contributing to the efficiency, security, and versatility of Bitcoin scripts, ultimately promoting a more robust and functional Bitcoin ecosystem. Firstly, OP_CAT simplifies the scripting process by enabling the direct concatenation of stack items, which significantly reduces the number of steps required to achieve the same result through alternative means. Without OP_CAT, developers must employ more convoluted and error-prone methods to combine data within scripts. These methods often involve multiple operations that increase the complexity of scripts, making them harder to read, write, and debug. By reducing the script complexity, OP_CAT directly enhances the maintainability and auditability of Bitcoin scripts, thereby reducing the potential for scripting errors and increasing overall security.

The ability to concatenate stack items directly impacts the creation of more complex conditional checks within Bitcoin scripts. Conditional logic is essential for implementing advanced financial contracts such as multi-signature wallets, atomic swaps, and time-locked contracts. For instance, in multi-signature wallets, different conditions based on multiple signatures from different parties need to be evaluated efficiently. OP_CAT can concatenate signature data or other relevant information to streamline these evaluations, making the scripts more efficient and easier to implement.

Atomic swaps, which are cross-chain exchanges of cryptocurrencies without the need for a trusted third party, benefit significantly from the introduction of OP_CAT. These swaps rely heavily on the ability to handle complex conditional logic and data concatenation to ensure that both parties fulfill their parts of the transaction simultaneously. By simplifying the script logic required to check and enforce these conditions, OP_CAT makes atomic swaps more secure and reliable, enhancing trust in decentralized exchanges.

Time-locked contracts also stand to gain from the reintroduction of OP_CAT. These contracts require conditions to be met only after a specific time has passed, necessitating precise and often complex concatenation of data elements such as timestamps and transaction conditions. OP_CAT allows for straightforward concatenation of these elements, simplifying the creation and execution of time-locked contracts, and thus, enhancing their reliability and usability.

Additionally, the reintroduction of OP_CAT addresses previously identified security concerns by incorporating robust error handling and validation mechanisms. These measures are designed to prevent potential vulnerabilities that could arise from improper data concatenation, ensuring that scripts execute securely and as intended. By focusing on security in its design, the updated OP_CAT operation mitigates risks associated with its use, fostering confidence among developers and users in the enhanced scripting capabilities. Beyond individual use cases, the broader implications of reintroducing OP_CAT are significant for the Bitcoin ecosystem. By enabling more sophisticated and versatile scripting, OP_CAT contributes to the development of a wider range of decentralized applications (dApps) and financial instruments on the Bitcoin network. This expanded functionality is crucial for Bitcoin's competitiveness as a programmable digital currency, particularly as other blockchain platforms continue to innovate and offer advanced scripting capabilities.

The reintroduction of OP_CAT aligns with Bitcoin's ongoing evolution and its goal of becoming a more programmable and versatile digital currency. It empowers developers to create more efficient, secure, and advanced financial contracts, which can drive innovation and expand the range of use cases for Bitcoin. By enhancing Bitcoin Script's expressiveness and utility, OP_CAT plays a pivotal role in supporting the continued growth and adoption of Bitcoin in the decentralized finance (DeFi) space.

In conclusion, reintroducing OP_CAT to Bitcoin Script is multi-faceted, addressing current scripting limitations, enhancing security and efficiency, and fostering innovation within the Bitcoin ecosystem. By simplifying script logic, enabling more complex conditional checks, and ensuring secure execution, OP_CAT represents a crucial step forward in the evolution of Bitcoin as a leading programmable digital currency.

Backward Compatibility
Introducing OP_CAT does not affect existing scripts but expands the script capabilities for new transactions. This ensures that all pre-existing scripts remain functional and unaltered, maintaining the integrity and stability of the Bitcoin network. However, existing nodes and wallets would need to update their software to recognize and support the new opcode. This update process, while requiring coordination among developers and users, is essential to unlock the enhanced scripting capabilities provided by OP_CAT.

Historical Use of OP_CAT
In the past, OP_CAT was part of the Bitcoin scripting language but was disabled due to concerns over potential vulnerabilities and the complexity of verifying the security implications of concatenation operations. Despite its removal, the demand for OP_CAT has persisted among developers who recognize its utility in simplifying complex scripts. The opcode's ability to concatenate data directly on the stack is a fundamental operation that can greatly streamline script logic, reducing the need for multiple, more cumbersome steps to achieve the same outcome.

Current and Future Use Cases
The reintroduction of OP_CAT is necessary to meet the evolving demands of Bitcoin's scripting language, particularly as more sophisticated use cases emerge. Some specific reasons OP_CAT may have been used in the past and why it is required today include:

Efficient Data Handling:
Past: In early script designs, concatenating data directly was necessary for implementing complex scripts efficiently. Without OP_CAT, developers had to use multiple steps and additional opcodes, making scripts longer and harder to debug.

Present: Today, as the complexity of financial contracts and decentralized applications increases, the need for efficient data handling becomes even more critical. OP_CAT allows for more concise and readable scripts, enhancing maintainability and security.

Simplifying Conditional Logic:
Past: Scripts requiring conditional logic often needed to concatenate data to verify multiple conditions in a single step. This capability was crucial for multi-party agreements and advanced transaction types.

Present: Modern use cases, such as multi-signature time-locked escrows and atomic swaps, benefit significantly from the ability to concatenate conditions and secrets directly within the script. This simplifies the implementation of complex conditional checks, making smart contracts more robust and easier to execute.

Enhanced Security:
Past: Direct concatenation within scripts reduced the risk of errors and potential vulnerabilities associated with handling multiple stack operations separately. By using OP_CAT, developers could ensure that data concatenation was performed atomically, minimizing the attack surface.

Present: As the Bitcoin network continues to evolve, maintaining a high level of security in smart contract execution is paramount. OP_CAT provides a straightforward and secure method to concatenate data, reducing the complexity and potential points of failure in script execution.

Test Vectors
Test vectors for OP_CAT should include cases where stack items are concatenated successfully and where operations fail due to insufficient stack items.
Successful Concatenation:


Implementation
The implementation of OP_CAT involves modifying the Bitcoin script interpreter to recognize and execute the opcode. The interpreter should be updated to handle the stack operations for concatenation and include error handling for edge cases.


Reference Implementation
Below is an example of how OP_CAT could be implemented in the Bitcoin Core codebase. This code should be integrated into the script interpreter to handle the concatenation of two stack items. The EvalScript function, which is responsible for evaluating script operations, would need to include the logic for OP_CAT as shown below. This implementation ensures that OP_CAT correctly handles stack operations, concatenates data securely, and manages error conditions.



Stack Size Check
The first step in the OP_CAT implementation is to ensure that there are at least two items on the stack. This is crucial because OP_CAT requires two inputs to concatenate. The check is performed using:


If the stack does not have the required number of items, the script execution fails with an INSUFFICIENT_STACK_ITEMS error. This prevents the operation from proceeding and ensures that the script does not produce invalid results or crash due to insufficient data.

Retrieving Stack Items
Next, the top two items on the stack are retrieved. These items, typically represented as valtype, are stored in vch1 and vch2:

)   

Here, stacktop(-2) and stacktop(-1) are used to access the second-to-top and top items on the stack, respectively. This ensures that the correct elements are selected for concatenation.

Concatenation Operation
The actual concatenation is performed by appending vch2 to vch1:


This operation modifies vch1 to contain its original content followed by the content of vch2. The use of insert ensures that the elements of vch2 are added to the end of vch1, effectively concatenating the two byte arrays.

Stack Management
After concatenating the items, the original elements are removed from the stack to maintain stack integrity. This is done using popstack:

   

These calls remove the top two elements (which were vch1 and vch2) from the stack.
Finally, the concatenated result (vch1) is pushed back onto the stack:


This ensures that the result of the OP_CAT operation is available at the top of the stack for subsequent script operations.

Error Handling
Proper error handling is a critical aspect of implementing OP_CAT. The script must handle scenarios where there are insufficient items on the stack gracefully. The implementation ensures that if the stack size check fails, an appropriate error is returned, and script execution is halted. This prevents any undefined behavior or security vulnerabilities that could arise from attempting to concatenate non-existent stack items.

Testing and Validation
To ensure the reliability and security of the OP_CAT implementation, extensive testing and validation are required. This includes:
Unit Tests: Create unit tests to verify that OP_CAT behaves as expected in various scenarios, including edge cases where the stack contains exactly two items or more than two items.

Integration Tests: Verify that OP_CAT works correctly when integrated with other script operations and in real-world transactions.
Security Audits: Conduct security audits to ensure that the implementation does not introduce vulnerabilities, such as buffer overflows or improper memory handling.

Integration into Bitcoin Core
Integrating OP_CAT into Bitcoin Core involves modifying the script interpreter and updating related components to recognize and process the new opcode.

This includes:
Script Interpreter: Modify the script interpreter to include the OP_CAT case within the EvalScript function.
Opcode Table: Update the opcode table to include OP_CAT, assigning it the appropriate hexadecimal value (0x7e).
Documentation: Update the Bitcoin Core documentation to reflect the addition of OP_CAT, providing developers with information on its usage and behavior.
Network Upgrade: Plan a network upgrade to activate OP_CAT, ensuring that all nodes and wallets are updated to support the new opcode. This typically involves a soft fork, requiring consensus from the community.

By carefully implementing and integrating OP_CAT, the Bitcoin network can leverage enhanced scripting capabilities, enabling more complex and secure financial contracts and decentralized applications.

Final Thoughts
Re-introducing OP_CAT enhances Bitcoin's scripting language, enabling more sophisticated and efficient scripts. This opcode re-establishes a critical function that simplifies the process of concatenating stack items, thus streamlining complex script operations. This paper outlines its utility through multiple use cases, demonstrating its potential to improve conditional transactions, multi-signature arrangements, and proof-of-ownership mechanisms. These enhancements show how OP_CAT can significantly reduce the complexity of script development, making it more accessible for developers to create advanced and secure financial contracts.

By adopting OP_CAT, Bitcoin can support a broader range of decentralized applications and financial contracts, furthering its capabilities as a programmable digital currency. This capability is crucial for expanding Bitcoin’s functionality beyond simple transactions, allowing it to serve as a foundation for more complex financial instruments and protocols. The increased script efficiency and flexibility brought by OP_CAT will enable developers to implement a variety of new use cases, from more secure and user-friendly escrow services to intricate multi-party agreements and beyond.

This expansion will likely drive greater innovation within the Bitcoin ecosystem, attracting more developers and fostering a more vibrant community focused on decentralized finance.

Moreover, the addition of OP_CAT helps position Bitcoin as a more competitive platform for smart contracts, complementing its existing strengths in security and decentralization. As the demand for decentralized financial solutions grows, having a more versatile scripting language will be vital for Bitcoin to maintain its leadership in the blockchain space. Therefore, integrating OP_CAT not only enhances current functionalities but also prepares Bitcoin for future advancements and emerging trends in the digital financial landscape.

References
Bitcoin Script documentation: https://en.bitcoin.it/wiki/Script
Previous discussions on OP_CAT: https://github.com/kanzure/diyhpluswiki/commit/ae30250ed66ea2d88a331a48924806f49f84fe45.diff
BitcoinTalk.org: Using OP_CAT https://bitcointalk.org/index.php?topic=764189.20
BitcoinTalk.org: Alt chains and atomic transfers https://bitcointalk.org/index.php?topic=193281.0
BitcoinTalk.org: https://bitcointalk.org/index.php?topic=255145.msg2766532#msg2766532
Bitcoin-dev: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2011-August/000398.html
auhf66ozdfsdf

Acknowledgment
Special thanks to the Bitcoin development community for their ongoing efforts to improve the Bitcoin protocol.  
Used ChatGPT to format and correct spelling issues.

BLOCK  https://btc.com/btc/block/844437

"diff": 182.0, This one is taking it's sweet time been a while since we had a big diff number!

Keep hashing everyone!

About time we brought back all the OP_codes..

Still don't believe this message was from Satoshi...

I think people here know more than they be letting on about the removal of some of the codes.

Something to hide lads?

Works well in LTC as proof of concept.

I don't see why Bitcoin could not add MWEB and give users privacy tools.

One of the reason is probably the mixers and coinjoin services would lose there income as people stopped using them.

This is more of a reason you would not see it added.

{"hashrate1m": "2.1E"}
{"diff": 118.0,}

Someone pushing hard.  I think block hits before 120.

I will say it again I don't see any reason you should not fire the normal pool up again.
I'm sure hashrate would land on it now with everything going on.

Spoke about it before but maybe there would be scope for it again now?

Pool is on fire!! Great to see the blocks flowing!

Keep lucky everyone <3

I would assume fees would take over and big farms may vanish.

I always wondered if bitcoin will come back to the home miners in future.

Never say never! 

Well done to the lucky miner. 

Tick tock next block.

While Bitcoin's pseudonymous nature offers a level of privacy, all transactions are public on the blockchain, allowing for potential analysis that could link identities to transactions. To enhance privacy and security, advanced cryptographic techniques such as homomorphic encryption can be applied. using Microsoft SEAL, a C++ library for homomorphic encryption, to demonstrate how privacy could be further protected in Bitcoin transactions, particularly in privacy-focused protocols like CoinJoin.

Homomorphic encryption allows computations on encrypted data without needing to decrypt it first. This property can be particularly useful in Bitcoin transactions for various reasons...  Users can participate in transactions without revealing their transaction amounts or other sensitive data to other parties or the public blockchain.

Secure Multi-party Computations, enables the creation of complex multi-party protocols where inputs are kept private.

Setting up Encryption Each participant uses a common encryption scheme set up using Microsoft SEAL. This ensures all parties can operate on the data homomorphically. users encrypt their UTXO values. This encryption does not reveal the amount of bitcoins each user intends to mix, but allows operations to be performed on the encrypted values.

Serialize and Share Encrypted UTXOs, Once encrypted, UTXO data can be serialized and securely shared with other participants or a coordinating server without revealing the actual values.

Aggregate Encrypted UTXOs, A trusted coordinator or the participants themselves can aggregate the encrypted UTXOs. This aggregation is performed homomorphically, ensuring that no individual inputs are exposed.

Check Aggregated UTXOs Against Threshold: To ensure the transaction meets certain criteria (e.g., minimum input threshold for a CoinJoin), a homomorphic operation checks if the aggregated encrypted value meets the required threshold.

Finalize Transaction: If the check passes, the transaction can proceed. This step would typically require converting the homomorphically encrypted data into a format suitable for a Bitcoin transaction, which may involve securely decrypting the data under strict protocols or through a zero-knowledge proof mechanism to maintain confidentiality.



While it's not 100% solid idea yet could be worth exploring further.

They work perfect for solo hunting low power,  low noise.  Also opensource.

Just make sure you buy one from a reputable seller.

On average running higher freq and voltage I see sometimes 650gh/s or more but you should add some extra cooling if you turn it up.

For the money they are great boards.

Well worth getting one!

https://www.thesolomining.co/

Someone been pushing hard last few days saw 1.2EH at one point again! 

Love the new Cpool dash top work VKBIT.

Currently sitting in 9th place!

You forked my project and didn't give any credit.

https://github.com/DaCryptoRaccoon/BitcoinSoloPy

Sooner everyone jumping on this bandwagon get rekt the better.

Doing nothing for Bitcoin users in the long run other than costing them money.

When someone can't send funds or make transactions because of spam junk crap we have a problem.

If you want to join the solo race I advise buying a BitAxe stand alone miner.

This will get you hashing away don't burn out your GPU on your machine trying while you CAN still hash the odds of a find on a GPU or PC today are astronomical. 

You can get a Bitaxe from https://www.thesolomining.co/  and the main developer is active on the forum.

Buy the miner,  point it at the solo pool  https://solo.ckpool.org

And hope for a big share!

Good luck!