I agree that spam should be eliminated from Bitcoin. I think that the minrelaytxfee is not an effective tool for that. In fact, genuine monetary transactions are the most sensitive to fee levels while spam is not - as evident from blocks full of spam and the highest fees in the last 2 years.

For spam protection, there is the which is much more effective. Also, there is the (OP_FALSE OP_IF) filter bugfix implemented in Bitcoin Knots.

I disagree. Miners and mining pools may either accept low fee-rates or lose opportunity to earn them otherwise.

The minrelaytxfee default value of 1000/kvB (1 sat/vbyte) has been set in Bitcoin nodes since 2013 or earlier. In 2013, 1000 sats were priced at $0.01, today it is about 100 times more. Wouldn't you like to consider adjusting your node configuration and lower the hurdle, perhaps? I would suggest setting (which translates to 0.001 sat/vbyte) as a rule of thumb. The value could be set in a bitcoin.conf file. There is negligible number of such reconfigured nodes relaying transactions with fee-rates below 1 sat/vbyte currently.

There is the intention to unblock transactions with fee-rate below 1 sat/vbyte in Bitcoin. Probably consolidation and multisig types of transactions would benefit the most.

Are there any pools that accept transactions with a fee which rate is fewer than 1 sat/vbyte, perhaps? Or do they all just reject such transactions even if mempools are empty?

More info at https://github.com/OCEAN-xyz/datum_gateway.

No, there isn't any sacrifice of security.

I agree up to a point. While English words may be easier for English speakers, others may have little clue how to spell (write) them. Also, some words in the BIP39 dictionary are mistake-prone, e.g. chief and chef.

Not exactly. They are not completely random letters. There is a syllabic structure/pattern that a string follows.

Correct.

To be precise: base-126 with 2-character digits (except for single/1 character vowels).

Thank you all for sharing your opinions.

Thanks for feedback.

Yes, the aim is to keep a private key in another form/representation which is easier to read and write/type. As an example the BIP39:
"legal winner thank year wave sausage worth useful legal winner thank yellow"
would be equivalent to:
"iqogu sovyza cusydy huvifi zyhole suvyfu je".

Private key written as in the example:

"duboli kufuzu naleqy lyfety dohihy rutoqa rageli kilyly vetyka himujy teluzi fuoda va".

Why not? Can I ask you to review the SylUI concept, please? There is location of the demo and more information: "gregtonoski.github.io/sylui/".

I can confirm. There aren't commands like create, sign, send transaction etc. supported by Sparrow Wallet in a command line , unfortunately.

I recommend not to use BIP39-XOR with Electrum "seed" because of its differences from BIP39 (specification). Auto-generated "seeds" will not be compliant with Electrum ones. However, XOR results of manually (user) input "seed" should be identical in both cases (Electrum "seed" and BIP39).

Yes, you could use another open source program, e.g. "https://bitcoiner.guide/seed/", "https://spacehodler.github.io/SeedXOR/".

False.

Thank you for feedback, again.

Can I ask you to consider giving a star in GitHub if you find https://github.com/GregTonoski/BIP39-XOR interesting, please? More than 50 starts are required by package repositories, e.g. brew.sh to accept software for distribution.

Can I ask you to suggest command line (CLI or TUI - text-based) wallet software packages for Bitcoin, please? I would like to compile a complete list of all of usable ones.

The ones that I can think of:

• Bitcoin Knots
• Bitcoin Core
• BDK CLI https://github.com/bitcoindevkit/bdk-cli
• gocoin https://github.com/piotrnar/gocoin
• Electrum https://github.com/spesmilo/electrum
• Bitcoinlib https://github.com/1200wd/bitcoinlib

Thanks for feedback. I agree that plausible deniability is a feature that the BIP39-XOR tool may be used for.

Word of caution: there aren't different 3 XOR methods and names. As a matter of fact there is only one - just like there is only one correct addition, multiplication etc. There may be many implementations and they may differ due to bugs (and look/cosmetics like mixed visual encoding in so-called "seed-otp" etc.). I would ask not to perpetuate confusion arising from giving various names to the same technique: "seed-otp", "seedxor", "bip39-xor" are names of implementations/programs that attempt to acheive the same using the same XOR cipher.

Is BIP-322 a failure case? Is it unfinished and isn't there any conclusion?

(https://github.com/bitcoin/bips/pull/1347#issuecomment-2092033174).

There is "simple" variant (taggedHash "BIP0322-signed-message") implemented in Sparrow: https://github.com/sparrowwallet/drongo/blob/f8f50c0dd907fac674ea363443b96772b6a0b658/src/main/java/com/sparrowwallet/drongo/crypto/Bip322.java#L18
and
https://github.com/ACken2/bip322-js
and
https://docs.rs/bip322/0.0.7/bip322/.
Anywhere else?

(I haven't verified if the implementations above are compatible).

I am grateful to aliashraf for thoughtful analysis and suggestions.

There isn't anything blocking anybody to implement XOR encryption and embed (integrate) it in a hardware wallet. As a matter of fact, it has been widely used in military grade applications for more than a century. There is (imperfect) attempt by the Bitcoin harwdare wallet Coldcard producer (SeedXOR) and unfinished one in SeedSigner firmware. I don't know about other instances.

XOR as a solution (technique) is more than 100 years old. It's not something invented by me.

Thank you for information. To clarify - I am interested in data covering any country, metropolis, jurisdiction etc. I would like to track how BTC sucks in monetary premium from real estate.

Where data or price chart of BTC vs real estate market(s) could be found?

What alternative software do you think could be used instead of Kleopatra and KeyPassXC?

Spam is not a person by definition. It's junk data/message like arbitrary data in OP_RETRUN, OP_FALSE OP_IF etc. in the Bitcoin protocol. (I suspect a trolling attempt and give the benefit of the doubt)

Replies with explanations of choices are encouraged.