But, as discussed, will also result in your losing your coins. There is absolutely no way you can take 8 colors and print them out, and then later scan them back in and recover the same hex codes. You must include the raw codes or this method is useless. And if you include the raw codes then you need to hide them, because why else would someone have 8 random hex codes written down? And if you can hide them, then you can just hide the seed phrase and not add in all the additional risks of writing down a mistake, using this unreviewed code, being dependent on this code to regenerate your seed phrase, and so on.

Almost certainly. But it is also inappropriate to suggest to someone looking for their first self custody wallet that they need to run their own node, then set up their own server, then connect Electrum to that server. Doing so simply risks overloading them with information, making them throw their hands up in defeat, and leave their coins in the hands of Binance.

For new users it needs to be kept simple. Once they are familiar with Electrum, then they can explore running their own node if they desire.

Running a pruned node compared to a full node makes no difference to your safety. What it does mean is that you can't bootstrap new nodes and you can't scan for old transactions. Your IP will always be revealed regardless of the type of node you run. If you don't want that, then use Tor. If you don't want to broadcast your own transactions from your own node even over Tor, then use something like http://mempoolhqx4isw62xs7abwphsq7ldayuidyx2v2oethdhhj6mlo2r6ad.onion/tx/push.

If you don't broadcast the transactions, then nothing happens. The network never learns about them, your coins never move, and you pay no fees. As far as the wider network is concerned, those transaction do not exist until you broadcast them. If you never broadcast them and delete them instead, then it is as if they never existed.

7-of-7 for uncompressed public keys, 15-of-15 for compressed keys, in a P2SH multi-sig. This is based on the limit of 520 bytes as you say, although OP_CHECKMULTISIG would actually support up to 20 keys.

In taproot, OP_CHECKMULTISIG/OP_CHECKMULTISIGVERIFY are replaced with OP_CHECKSIGADD (0xba), which allows up to 999 keys. Here is a transaction which spends a 998-of-999 taproot multisig: https://mempool.space/tx/7393096d97bfee8660f4100ffd61874d62f9a65de9fb6acf740c4c386990ef73

Yes. You can choose any subset of the number of keys you like. So you could have 1-of-3, 2-of-3, or 3-of-3. Or you could have 4-of-8. Or 9-of-10. Or whatever you like.

m-of-n is just a common way of describing multi-sig set ups. The m stands for how many signatures you need, and the n stands for the total number of cosigners. For example, in a 2-of-3 multi-sig, there will be 3 cosigners, with the signatures of any 2 of them needed to spend the coins.

Although P2MS is very rarely used now, the script used in P2MS is the same script which is used in newer P2SH/P2WSH multi-sig addresses, so still worth a read.

Sure, but KYCed bitcoin and tainted bitcoin are two entirely separate things.

Not sure how you reached that number. Given maker fees of 0.075%, then I can set my own spreads and pay combined transaction and network fees of <0.5% all in, provided I am not in a rush.

Swapping for any other coin which is completely traceable is completely pointless.

So? So blockchain analysis knows I sold my KYCed bitcoin for monero. Then what? They can't trace that monero, so they can't pinpoint when I trade it back in bitcoin.

If the address isn't in the wallet in Core, then Core won't scan it. The usual explanation for this is that it is beyond the "gap limit". Given that it is possible to generate billions upon billions of individual addresses from one set of extended keys, wallets cannot possible scan them all. So they will usually scan the first handful and stop, unless you specifically tell the wallet to scan for more.

So it all comes down to exactly how you have set things up. Did the consolidation transaction send coins to an address in the same Sparrow wallet, or to a new wallet? Is the wallet you have open in Core simply the one that Sparrow creates automatically, or have you created it yourself by importing keys or descriptors?

Here's a transaction made using the set up discussed in that thread: https://mempool.space/tx/1c41724a7b16ecd5e11867864d834eb24e9d22b372c86aa7869c4cc0b6b36d52. It signs from one mandatory key, and then also signs from a 2-of-3 multi-sig, essentially making it a 3-of-4 with one required key.

Just use taproot, and then your 4-of-6 transactions will be no bigger.

You don't need to apologize for taking the first steps towards self custody!

No payment required. The most straightforward way is to download a verify a reputable wallet such as Electrum (https://electrum.org/) or Sparrow (https://sparrowwallet.com/). A more secure method is to purchase a good quality hardware wallet such as a Passport.

Given how many centralized exchanges have been going bankrupt or outright scamming their users, it's certainly a good idea to start looking in to self custody.

Signing a message from an address allows you to prove ownership of that address. Some exchanges are starting to require signed messages so they know you are only withdrawing coins to your own addresses and not sending them somewhere else. This is just yet another way they want to control you and monitor everything you do.

Signing a transaction uses almost the exact same process as signing an arbitrary message. Both Electrum and Sparrow as I've suggested above allow you to sign messages.

On Bisq right now the spread between buy and sell orders for the BTC/XMR pair is 163 sats, which is less than 0.03%. The trading fee for a taker is 0.575%, and the trading fee for a maker only 0.075%.

Within a 1% price spread on Bisq, there is approximately 0.6 BTC of volume for selling XMR, but about 14 BTC of volume for buying XMR. This is only one platform, however, and there are plenty of others you can choose from. https://kycnot.me/

This is just as much a risk with the methods we are discussing here. The correct approach to this issue is to never use any centralized exchange or service which attacks the fungibility of bitcoin by buying in to the provable nonsense of "tainted" coins.

He has a lot of money and will hire a lot of very smart lawyers. Remember it's one set of rules for the rich and another set for the rest of us. He'll be able to either argue or bribe his way away from jail, I'm sure.

If there is one person you should trust less than CZ in this space, it's Justin Sun. He is a plagiarizer and a scammer.

Yes. You can choose to reduce the amount being sent to one or more of the outputs of your transaction and use that to pay a higher fee instead.

For example, let's say you have a transaction which spends one input of 0.03 BTC, sends 0.02999 BTC to another address and pays 1000 sats in fees. You could replace that with a transaction spending the same 0.03 BTC, but paying 0.02998 BTC and paying 2000 sats in fees.

Most wallets should give you the option of including an additional input from that wallet, if you want to.

Not at all.

Let's say I have a wallet containing UTXO A on Address A, and UTXO B on Address B. I create a transaction sending UTXO A to a third party to pay for some goods or services. I later want to bump the fee on this transaction, but I don't want the third party to receive any less. So my wallet can create a new transaction which includes UTXO B alongside UTXO A, pays a higher fee, and then sends the rest to a change address.

Now let's say I also have a completely separate wallet which contains UTXO C on Address C. I could also manually create a transaction which includes UTXO A and UTXO C, sends the same amount of coins to the third party, and pays a higher fee. All I need to do then is sign it separately with the first wallet and then with the second wallet, and then broadcast it.

The network, and the RBF mechanism, have no concept of which addresses are in the same wallet and which are in different wallets. You can combine any UTXOs from any wallets in the same transaction.

That's not right. As I said above, if you want to keep the outputs the same and bump the fee then you can include another input from anywhere else. The extra input does not have to be from the same address, or even the same wallet, as your original inputs.

Telling people not to empty their sending address is poor advice since it encourages address reuse, and as I've explained is entirely unnecessary.

Monero is the only coin which is truly private and which blockchain analysis firms have been entirely unable to break. If you have doubts about the privacy provided from monero, then it would be absolutely insane to think you would somehow get better privacy from wBTC or similar.

Yes it can. You just decrease the value of the outputs and put those extra sats to the fee instead. Alternatively, you can include an extra input from any other address to give you extra coins to spend on the fee.

Technically speaking, every RBF transaction is a double spend, since it includes at least one of the same inputs. Those inputs are being spent in a second transaction which conflicts with the first, and it is therefore a double spend. It just so happens that many (or maybe even most) RBF transactions happen to double spend to the same addresses as the original.

It will make a difference to the order in which transactions are chosen by miners to be included in blocks, but it will make no difference whatsoever to the total number of unconfirmed transactions.

You are using an old version.

https://github.com/spesmilo/electrum/commit/a383f56909f1090ffc155a6dca7db0246cb564f0

This is incorrect for two reasons.

First of all, a transaction cannot be the same except for a higher fee. If the fee is higher, then either you need to include an additional input or you need to reduce one or more of the outputs. Something else must change in order to free up funds to contribute more to the fee.

Secondly, the transaction can in fact be completely different. You can make a replacement transaction spending any one of the inputs of the original transaction to any address you like (including an address not present in the original transaction), and you will replace the original transaction. This is why you can use RBF to "cancel" a transaction, which actually replaces the transaction with a new one sending the coins back to yourself instead of to the original recipient(s).

It's also worth pointing out that full RBF is gradually replacing opt-in RBF, and so soon every transaction will be able to be RBFed, even if not opted in.