Going to mention this guy here for a proper tag:

Liocen

A pure merit farmer account, probably the 10th account started by the same person. They were a self-professed newbie in July but are now summarizing complicated Bitcoin script ideas with what I suspect is purposefully-mangled AI text.


As pointed out by Satofan44:


The emdashes are a big giveaway that AI was used in the creation of the post. But the edits they made to avoid detection render the post largely unreadable. And obviously its not totally AI because AI wouldn't write something this stupid:


And I kind wonder who "we" is:


This was their excuse:


Its hard to read this without thinking you're having some kind of stroke. He didn't really say anything other than "this is my opinion."

To @Liocen: stop making new accounts. You are so concerned with getting merits and ranking up that you have neglected to learn pretty much anything about Bitcoin. Nobody is going to be impressed if you take something AI wrote for you and change the wording, grammar and punctuation so much that its barely understandable, especially not in the Dev & Tech Discussion board. It is obvious this isn't your own text, please stop lying.

Your plan was very stupid. It never would have worked. I saved you time by letting you know now instead of others letting you know later.

Hey, for high-activity addresses, batching scans and parallelizing can save a lot of time, but watch out for RPC or API limits to avoid throttling memory management is keykeeping a cache for seen inputs and streaming results to disk prevents overload, especially on busy addresses.  
always validate your extracted RSZ and pubkeys against decoded TX hexes from a node or testnet. logging intermediate results helps catch mismatches and confirm accuracy. the collected data can also power research like transaction clustering, pattern detection, or analytics dashboards. timestamped logs make everything reproducible and easier to debug.
 
One last thing: mass collection of pubkeys has privacy implications. If testing on mainnet, include disclaimers and be mindful of sensitive patterns. Balancing speed, memory, and validation while staying responsible is the best way to handle complex addresses.

solid goal

No need for fancy APIs your full node itself is a goldmine grab blocks via bitcoin-cli getblock, pick the fields you care about (height, timestamp, tx count), dump a few hundred into a CSV or lightweight DB, then chart with Plotly/Grafana
start small, watch patterns emerge, and you’ll soon see things no API can show mempool waves, dust floods, or fee spikes straight from your node.

RPC docs are your roadmap: https://developer.bitcoin.org/reference/rpc/

trust me once your node feeds your charts, the blockchain suddenly feels alive

Firstly, we should explore some wallets to check their interface so that we can choose a more user-friendly interface. In this case, research the wallet reviews and community feedback to judge its reputation.

Secondly, we should choose a recovery-friendly wallet, meaning if anyone loses access to the wallet, there should be an easy recovery option.

Thirdly, we need to choose a wallet that supports our preferred coin.

Finally, security is the most important feature. There must be 2-factor authentication and encryption options to double-secure our valuable wallet.

Thank you for reading the post.

This issue is mainly caused by the difference in derivation path
Although you said that “all addresses are native SegWit”, Mycelium and Electrum sometimes use different derivation paths.
The default path for native SegWit (bech32) in Electrum is:
But Mycelium in some versions (especially older or multi-account versions) can use any of the following paths:
m/44’/0’/0’ → legacy (1… address)
m/49’/0’/0’ → nested SegWit (3… address)
m/84’/0’/0’ → native SegWit (bc1… address)

Or a custom path if you have created multiple accounts. For example When you import a seed into Electrum, it only scans addresses on one path. So even though transactions from 2020 are visible, if new receive addresses from 2025 are created on a different path, Electrum will not scan them.
Possible solution to the problem:
By checking the derivation path in Mycelium:
Go to the “Accounts” section in Mycelium and tap on your active account.
If you go to “Account Info” or “Export” → “Show XPUB”, you will see the Extended Public Key (xpub/zpub).
Copy that zpub.
Create a new wallet with a custom derivation path in Electrum
Open Electrum → File → New/Restore
“Standard wallet” → “I already have a seed” → enter your seed → “Options” → check “BIP39 seed”
Then enter the Mycelium path in “Derivation path” (e.g. m/84’/0’/1’ etc., multiple attempts may be required)
After the wallet is created, check if the missing balance is visible.
XPUB comparison:
Go to Electrum’s “Wallet → Information” and check xpub/zpub, and match it with Mycelium’s.
If different → you are using the wrong derivation path.

You have decided to increase the gap limit, but it will only take effect if the derivation path is correct.

In an effort to control and make Bitcoin transactions more secure, developers have created a script called Covenant Script. Covenant Script is a scripting concept that can restrict the future use of Bitcoin’s UTXO (Unspent Transaction Output).
Normally, when you send Bitcoin, that output can be spent by anyone in a future transaction — if they provide the correct signature.
But with Covenant, you can say:
“This output can only be spent in the future on this specific script, or this specific type of output.”
Thus, Covenant imposes a “rule” or “condition” that controls the natural free flow of Bitcoin.

Although Covenant scripts (such as the OP_CHECKTEMPLATEVERIFY, OP_CAT, or OP_TXHASH proposed codes) enable a new generation of scaling and privacy tools such as Ark, Vault, and Channel Factory,
some people are still hesitant to use them due to their risks or controversial aspects.

They explain the following conclusions about its risks_
▫️ Since Covenant allows anyone to create scripts that force transactions to be sent to specific addresses or conditions.
This allows governments or large organizations to create policy-enforced address lists and apply “whitelists/blacklists”.
If Covenant is used incorrectly, the fungibility and independence of Bitcoin can be damaged.
▫️ If Covenant is designed incorrectly, “recursive” or repetitive covenants can be created —
that is, a Covenant will continue to impose the Covenant on subsequent UTXOs, acting as a kind of self-propagating script.
Unexpected script loops can be created in the network,
node verification can become complicated,
even “locked output” (stale coins) can be created on the blockchain.
▫️ Using Covenants makes some transaction patterns “predictable” —
such as Ark or Vault transactions having to be in a specific format.
Although this increases privacy, analysts will be able to identify Covenant-type outputs.
▫️Every new Opcode or Covenant type change means adding new rules to the consensus layer.
If all nodes or miners do not agree, then a chain split (soft fork contention) can occur.

So is Covenant dangerous?
Not at all, Covenant itself is not dangerous,
But it is dangerous if the user uses it dangerously. Moreover, it is powerful.
Just as caution is required when using powerful tools, proper security design and setting limits are essential in the case of Covenant.

Developers working on Covenant have proposed different versions to see if this capability can be added without breaking the consensus rules of Bitcoin Core. For example-
Jeremy Rubin proposed “OP_CHECKTEMPLATEVERIFY (CTV)”
Gleb Naumenko proposed “OP_TXHASH or TXHASH”

Covenant Script Modern Upgrade or New Vulnerability Door? We would like your valuable opinion on this.

I'm sorry 😓 I didn't understand. If I understood, I wouldn't have posted like a fool. If I understood, I would never have posted. After I came to the forum, I thought that I could express my thoughts

Yes, changing your network settings on macOS can inadvertently redirect Bitcoin Core's data storage location, especially if you've moved your installation to an external drive. Here's how to locate and manage your Bitcoin Core data:

1. Verify Bitcoin Core's Data Directory

Bitcoin Core typically stores its data in the following default directory:


~/Library/Application Support/Bitcoin


To access this folder:

Open Finder.

Press Command + Shift + G to open the "Go to Folder" dialog.

Enter the path above and press Return.

If you've configured Bitcoin Core to use a custom data directory, the location might differ. To confirm the current data directory:

Launch Terminal.

Run the following command:

  defaults read org.bitcoin.Bitcoin-Qt datadir


This command will display the path to the data directory Bitcoin Core is currently using.

2. Check for Disk Space Usage

To determine where the blockchain data is stored and how much space it's occupying:

Open Disk Utility (found in Applications > Utilities).

Select your external drive from the list on the left.

Click on the "Info" button (i) to see detailed information about the drive, including the amount of used and available space.

If the external drive is nearly full, it's possible that Bitcoin Core has started using your internal drive for additional storage.

3. Locate Blockchain Files

The blockchain files are typically stored in the blocks directory within the Bitcoin Core data directory. To find these files:

Navigate to the Bitcoin Core data directory (as identified earlier).

Look for a folder named blocks.

Inside the blocks folder, you'll find files like blk00000.dat, blk00001.dat, etc., which contain the blockchain data.

4. Ensure Correct Data Directory Usage

If you want to ensure Bitcoin Core uses a specific data directory (e.g., on your external drive):

Open Terminal.

Stop Bitcoin Core if it's running.

Run the following command to start Bitcoin Core with the desired data directory:

  /Applications/Bitcoin-Qt.app/Contents/MacOS/Bitcoin-Qt -datadir="/path/to/your/external/drive/Bitcoin"


Replace "/path/to/your/external/drive/Bitcoin" with the actual path to your desired data directory.

This command will launch Bitcoin Core using the specified data directory, ensuring all data is stored on your external drive.

You're correct in asserting that merely having a trusted party (like Charlie) sign a note linking an in-game item to a Bitcoin preimage doesn't establish a truly atomic transaction. This approach introduces a reliance on reputation and doesn't provide verifiable proof that the specific item traded corresponds to the Bitcoin preimage. To achieve true atomicity in such trades, the game would need to emit a signed, publicly verifiable receipt for the exact trade, or utilize a Trusted Execution Environment (TEE) attestation.

A notable example of integrating TEEs with blockchain technology is the Ekiden project. Ekiden combines blockchains with TEEs to enable confidentiality-preserving smart contracts. By leveraging TEEs, Ekiden ensures that the execution of smart contracts remains private and secure, while still benefiting from the blockchain's integrity guarantees. This approach addresses the critical gaps in current blockchain systems by providing both confidentiality and performance improvements.
arXiv

Implementing such a system in a game would allow for the creation of verifiable receipts or attestations for in-game item trades. These receipts could then be used as Bitcoin adaptor signatures or HTLC triggers, ensuring that the trade is atomic and secure. This would eliminate the need for a trusted third party and provide a verifiable link between the traded item and the Bitcoin preimage.

In summary, while the current approach relies on trust and doesn't provide verifiable proof, integrating TEE-backed smart contracts could enable true atomic trades in games, ensuring security and confidentiality.

Sorry for the delay in answering your question. I was ready to prove myself. But you unnecessarily considered me negative. ABCbits and nutildah you gave me negative trags only because I wanted to know something on the technical board.

Initially, when I came to the forum, I was very happy, I also saw a specific local board of my community. There, two contests were also organized after I came. I have never done food carving in my life but seeing my fellow travelers, I became interested in doing food carving and later when another contest was organized on the occasion of our Victory Day, I also drew a picture there, only inspired by the activities of the forum members.

I thought that this is another world of the internet where I can learn something extraordinary along with learning something ordinary.

Sorry for the delay in answering your question. I was ready to prove myself. But you unnecessarily considered me negative. ABCbits and nutildah you gave me negative trags only because I wanted to know something on the technical board.

So should I assume that no questions can be asked on the BitcoinTalk forum?

Can't make even the slightest mistake?

Or there is no helper who can correct someone's mistake?

I thought that this is another world of the internet where I can learn something extraordinary along with learning something ordinary. But I did not know that making mistakes is not normal here. I don't know what goes on here and in what context the IDs are collected? But I learned this thing that someone can easily suspect another person of being a bad person.
However, whatever I say here, you may not believe it or you may be annoyed.

And you could have banned me for the mistake I made that such a mistake cannot be made.

Nutildah and ABCbits, will you forgive the accusation brought against me and remove the negative tag? And if not, tell me that I will not come to the forum again. Because I have no previous experience about the forum, I will ask you a second time and again I will get a negative tag from you. I am waiting for your answer.

A 12-word BIP39 seed phrase already gives you 128 bits of entropy, which is considered secure enough to protect a Bitcoin wallet. While you can use longer phrases-like a 24-word seed providing 256 bits of entropy-it doesn't really make your wallet any safer in practice. This is because a Bitcoin private key in itself only requires 128 bits of security to be effectively unbreakable. So, while using more words may feel extra safe, for real-world security 12 words are already enough and very strong.

That's actually a very smart approach. Doing those additional sanity checks before connecting a watch-only wallet to the network can save you from some serious mistakes. Many people overlook such small but crucial steps. Testing commands like dumpwallet and making sure that it fails with "private keys are disabled," or checking that signrawtransactionwithwallet refuses to sign a dummy transaction, really confirms that your setup is secure. Better safe than sorry, especially when it comes to wallets. All this verification means you're just observing funds, not putting them at risk in any way.

That’s a very good reminder, actually. Most people don’t know that PSBTs contain some sensitive information regarding derivation paths and global xpubs that can compromise their privacy once shared with online devices or third-party tools. It would be smart to use the setting `bip32derivs=false` or strip the derivation data before sharing. It will ensure that no extra information is leaking about your key structure. It might be a small step, but it can save a lot in keeping your wallet setup private and your security uncompromised, especially in dealing with partially signed Bitcoin transactions across devices.

With that said, it is true that the blockchain is not totally impervious to bad actors, and concerns about CP and other illegal or harmful material being stored on it certainly are valid. But people should realize that the blockchain doesn't condone or encourage it it's a decentralized system for recording data in perpetuity. Unlike X or TikTok social platforms where one instantly shares and sometimes publicly views content, anything illegal stored on a blockchain is usually encrypted and inaccessible to normal users. There is no perfect way to prevent misuse without introducing censorship, but the transparency and immutability of blockchain make it so much more reliable and resistant to tampering compared to centralized databases.

The merit page says it all. https://bitcointalk.org/index.php?action=merit;u=3652862