Fuck you you ruined my all hardwork.
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.
Weird you're the one who got blamed twice[1-2], when another user is the one who discover possible connection between 2 account.
[1]
https://ninjastic.space/post/65911205[2]
https://ninjastic.space/post/65911179
User:
Xun huAdditional information (optional):
* This user receive multiple accusation of spamming with AI/chatbot. See
https://bt.irlbtc.com/view/5456516.msg65841781#msg65841781 and
https://bt.irlbtc.com/view/5456516.msg65906318#msg65906318.
List of post:
I have a python script that can pull all the RSZ and pubkeys from an addresses out going transactions. the only input is the address.
it took me a long time to get it perfected.
worth anything to anyone??
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.
1. Off-topic/unhelpful since @mrnimbus only ask whether his script is worth/useful for other person and doesn't ask for advice.
2. Mentioning privacy implication when collecting pubkey is rather weird, when Bitcoin blockchain is publicly available for everyone.
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 youll 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
For context, the goal is "Visualizing Bitcoin On-Chain Data". This suggestion isn't very helpful, since Bitcoin Core doesn't have address index or other index that can be used to obtain necessary data quickly for data visualization.
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.
1. This thread initial posted on Development & Technical Discussion board. So those general suggestion aren't exactly helpful for those who visit this board.
2. 2FA feature usually available on web wallet, shared custodial wallet or custodial service, where it may pose more security risk or involve 3rd party which may not be desirable for one's security.
User:
LiocenAdditional information (optional):
* This user receive at least one accusation of spamming with AI/chatbot, see
https://bt.irlbtc.com/view/5482297.msg65910655#msg65910655.
List of post:
I have a Mycelium wallet on Android, which works fine. But when I import the seed into Electrum, not all addresses show up. I see incoming transactions from 2020, but I don't see incoming transactions from 2025. I do however see the change that came from sending the transactions received in 2025!
Just in case, I tried increasing the gap limit to 500+, but that didn't help. All addresses are native Segwit addresses, so I'd expect all of them to use the same derivation path.
I now have Bitcoin in Mycelium that doesn't show up in Electrum using the same seed, and that doesn't feel right.
Any ideas where to start searching for a cause?
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:
m/84/0/0/0
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
m/84/0/1 m/84/0/2 m/84/0/3
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 Electrums Wallet → Information and check xpub/zpub, and match it with Myceliums.
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.
1. This post is unhelpful according to the one who asked question,
https://bt.irlbtc.com/view/5561541.msg65893053#msg65893053.
2. Mentioning derivation path of legacy/P2PKH and nested segwit/P2SH-P2WPKH address when the one who asked question already mentioned all address is native segwit.
3. XPUB comparison doesn't make sense when his previous guidance is importing extended public key rather than BIP39 words/seed.
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 Bitcoins 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.
1. Bitcoin UTXO actually can be spend if the TX provide appropriate ScriptSig. It can be something else other than providing correct signature, such as providing multiple expected signature or creating the TX after certain block height.
2. OP_CHECKTEMPLATEVERIFY, OP_CAT and OP_TXHASH are just bunch of OPCODES. It's not part of covenant itself and have other potential usage.
3. Other issue with this thread already stated by other member on
https://bt.irlbtc.com/view/5561784.msg65900263#msg65900263.