Yup. It's their current favorite bullshit. A few years ago it was all about how bitcoin is single handedly causing global warming. But now it's about how bitcoin is single handedly funding terrorism. Next up will be something like bitcoin is single handedly going to collapse the economy and your IRA/pension will be worthless.

Although their current mass surveillance has achieved nothing, all that proves is that the government needs more mass surveillance, right?

It's already been disproved: https://nitter.cz/nic__carter/status/1717210060777009636#m. Just more absolutely worthless made up trash from blockchain analysis companies which the government use to justify literally anything they want.

I wasn't referring to your reply, but rather to the general advice in the thread regarding bumping the child transactions.

I would go against the advice being given above and I would completely replace the first transaction with a new transaction.

First, two of your transactions are sending coins to the same address. This is unnecessary and you will end up spending a lot of extra fees given the current state of the mempool.

Secondly, your first transaction uses 7 inputs when any one would be sufficient. Again, given the current state of the mempool, now is not the time to be consolidating UTXOs. This is even more pertinent since you are using a 2-of-3 multi-sig and your first transaction is rather large at 815 vbytes.

And thirdly, given the fee rate of your first transaction is as low as it is many nodes will have already dropped it as they will have exceeded the default limits, and so any RBF of the subsequent transaction or any further CPFP may not even be accepted by many nodes since they do not know about the unconfirmed parent any more.

I would spend one of the inputs used in the first transaction, and only that input, to send the ~0.00013 to the exchange as you were trying to do. Your transaction will end up being around 192 vbytes, and you will need a fee of around 150 sats/vbyte, which will be around 29,000 sats in total. However, as well as your transaction actually being confirmed, you will save the over 80,000 sats you have already spent in fees, and you will avoid creating even more change outputs in your wallet which will need consolidated again in the future.

You don't need to enter different paths prior to using "Detect existing accounts" - Electrum will scan the common ones automatically. Was Electrum definitely synced when you did this (green circle in the bottom right)?

BRD wallet uses m/0' for both legacy and sewgit addresses. Import your seed to Electrum, select BIP39, choose legacy, and enter m/0' as the derivation path. In the wallet it creates for you, make sure it is synced as above.

If the wallet is empty, go to the console and enter the following two commands separately:

This will generate more receiving and change addresses. Let those sync too. If still empty, check the wallet for any historical transactions.

First of all, I would be very cautious importing your seed phrase in to so many different wallets and websites. You are at high risk of it being stolen unless you are doing this all on an airgapped computer.

Secondly, have you tried using the "Detect existing accounts" button on Electrum? If I remember correctly, that worked for another user and it found his BRD wallet account.

I've also read reports of people having success importing BRD seed phrases in to Blue Wallet. You could try that as another option.

I mean, I don't think I need to imply this - it's already happening. They quite clearly want bitcoin to only be used via fully KYCed exchanges. Just read the proposals. They have even deliberately chosen the words they use to make anything else sound negative. It's no longer "self custody", but rather "non-hosted wallets".

Terrorists, foreign governments, criminals, un-patriotic, what are you trying to hide, tHiNk Of ThE cHiLdReN, and a whole variety of other pearl clutching nonsense.

That's not quite accurate. For segwit, since the signature is moved to witness data, this field is left empty, and the preceeding script length field will be 0x00.

Here's a 998-of-999 taproot transaction: https://mempool.space/tx/7393096d97bfee8660f4100ffd61874d62f9a65de9fb6acf740c4c386990ef73

Correct. Or maybe 141 vbytes, depending on the exact size of the signature for the input.

Correct. Not only cheaper, but also more private by avoiding creating change. If you hold a variety of UTXO sizes, then you can usually find one close to the size you need and can maybe add a few more products in to your basket to make up the difference.

Also correct. Whether you are sending a thousand sats or a thousand bitcoin, it's always 8 bytes. Also note that this number is little endian. So if I wanted to send you 1 BTC, that would be 100,000,000 sats, which in hex is 0x0000000005F5E100, which would be encoded as 00E1F50500000000.

Minimize the number of inputs and number of outputs. Ideally spend from taproot addresses and send to native segwit addresses, but in reality just use either native segwit or taproot, which ever you prefer, since the difference is very small.

I'll use your table to answer your parts in red:

The transaction includes the following parts:

Version	4 bytes
# of Inputs	(VarInt. Will typically be one byte, unless you have more than 0xFC (252) inputs.)
Inputs	Each input's size (*)
# of Outputs	(VarInt. Will typically be one byte, unless you have more than 0xFC (252) outputs.)
Outputs	Each output's size (**)
Locktime	4 Bytes

* Each input consists of the following fields:

TXID	32 bytes
VOUT	4 bytes
ScriptSig Size	(VarInt. Will typically be one byte for a ScriptSig of 252 bytes or fewer. 3 bytes for a ScriptSig of 10,000 bytes (the upper limit prior to taproot).)
ScriptSig	(Depends entirely on the ScriptSig. Typically ~107 bytes for a standard legacy P2PKH input.)
Sequence	4 Bytes

** Each output consists of the following fields:

Value	8 bytes
ScriptPubKey Size	(VarInt. Will typically be one byte for a ScriptPubKey of 252 bytes or fewer. 3 bytes for a ScriptPubKey up to 10,000 bytes.)
ScriptPubKey	(Again, depends on the ScriptPubKey. 25 bytes for a standard legacy P2PKH output.)

VarInts are encoded as vjudeu has explained above. Anything up to 252 bytes is encoded in a single byte up to 0xFC. Anything above that and up to the maximum of 10,000 bytes will be encoded in three bytes with a 0xFD prefix, such as 0xFD2222.

ScriptSigs will vary depending on a number of factors such as address type, locking script, grinding for small R values, and so on. These will also be calculated differently for segwit inputs given this is witness data. (Transactions spending segwit inputs will also need a segwit flag in the header). A standard P2PKH ScriptSig will typically be ~107 bytes. A standard P2WPKH segwit ScriptSig will typically be 107 vbytes, which will then work out to 26.75 bytes.

ScriptPubKeys will vary depending on the output type:
P2PKH - 25 bytes
P2SH - 23 bytes
P2WPKH - 22 bytes
P2WSH - 34 bytes
P2TR - 34 bytes

Here is a very thorough explanation which might help you further: https://bitcoin.stackexchange.com/questions/92689/how-is-the-size-of-a-bitcoin-transaction-calculated

Miners don't set consensus: https://en.bitcoin.it/wiki/Bitcoin_is_not_ruled_by_miners

Further, mining pools are not a single entity. F2Pool, for example, does not own or operate all its hash power, or even a majority of its hash power. Miners are individuals, businesses, and other entities around the world, which collaboratively point their hash power at a pool in order to simplify the mining process and smooth out their earnings. If a pool is bought over by the government and starts censoring transactions, then the miners who are mining with that pool are free to switch to another pool, and indeed are incentivized to do so since by staying with their censoring pool they will be earning less since they will be deliberately excluding some high fee paying transactions.

You can always wipe the outdated OS and use a FOSS one instead. In addition to the distros ETFbitcoin has already mentioned, there is also Ubuntu Touch. Your best bet will probably be LineageOS or DivestOS though, which both support a wide range of old Samsung models:

https://wiki.lineageos.org/devices/#samsung
https://divestos.org/pages/devices

If you are only using the wallet to store a single UTXO received from elsewhere and then to later send that UTXO to your trading partner, then there will be minimal privacy loss from using a third party Electrum server via Tor. The server would be able to see all the other addresses in your wallet, but provided you are never going to use them for anything then that is irrelevant. It does mean using a new wallet for each trade you make, though, otherwise the server would be able to link all your trades to the same person.

Exchanges simply won't support this. You think Coinbase is going to set up a process by which every time anyone makes any trade, they notify Coinbase in advance exactly which coins they are intending to trade with. And Coinbase keep a record of not just the balance on everybody's account, but exactly which coins were bought when, which coins were sold when, and which coins were traded when? This effectively means Coinbase would have to trace every single individual satoshi in their custody at all times. Logistical nightmare. And so when exchanges simply refuse to support this, everyone will default to FIFO and get hit with outrageous tax bills.

Yet another reason not to use centralized exchanges. You can easily avoid this by trading exclusively peer to peer, since whenever you sell any bitcoin you will be choosing which outputs to use and should know where those outputs came from, or you can use software to track it all for you as mentioned above.

Kruw has been endlessly copy and pasting a post of his and spamming it across multiple threads where a user has deliberately consolidated unmixed change outside of Whirlpool as "proof" that Whirlpool is flawed. But when someone is tracked through a Wasabi coinjoin, it's entirely the user's fault and nothing to do with Wasabi?

Peak double standards.

You might want to tell that to Binance, who are investigating after the attacker's failed "mixing" with Wasabi: https://nitter.cz/RMessitt/status/1724139247127425209#m

Another example of a Wasabi coinjoin completely failing: https://nitter.cz/ErgoBTC/status/1723700744576971012#m

25 stolen BTC were coinjoined in Wasabi (wait, I thought their blacklisting was supposed to prevent that? ), and has been easily traced to a variety of exchanges. Oh, and some of the stolen coins were split off as "toxic change" and combined with presumably KYCed coins from a Binance account: https://nitter.cz/coinableS/status/1723806321441710412#m. You know, the same thing Kruw has been telling us is impossible with Wasabi.

I'm sure we'll be treated to the usual litany of excuses, but the bottom line is that Wasabi does not work.

No no no, you've got it all wrong. Every bitcoin transaction should be ran past Kruw personally to make sure that he approves of it before being broadcast. You are only allowed to spend your coins in ways that he thinks are acceptable.

That becomes far more clunky and time consuming, as well as error prone. Since the airgapped wallet does not know anything about which inputs to be used, then you will also need to copy across individual inputs and then manually craft your transaction since I don't know of any airgapped wallet which allows you to import individual inputs.

As I said above, although Sparrow lets you chose a different SIGHASH to use, it doesn't actually show you which SIGHASHes were used once the transaction has been created. So importing a signed transaction to Sparrow instead of Electrum does not solve this issue. The only way to know for sure at the moment is to manually examine the transaction data and check it uses 0x01 for SIGHASH_ALL on each input.

It would be a fairly simple change for the preview transaction screen on either wallet to display the SIGHASH type for each input next to that input.

I would clarify that Wasabi were not pressured or harassed in to implementing blacklists. There were no regulations at the time which forced them to do so, and currently regulations such as the FinCEN one are still in a proposal stage and not law. Wasabi preemptively started censoring their users in an attempt to cover their own backs.


Although as we've just seen with Swan telling people not to use Wasabi, their preemptive censorship didn't actually achieve anything.

What an absolutely damning indictment of Wasabi. So even though they pro-actively started censoring people of their own volition, and not because of any regulations at the time, when said regulations do start to take hold the centralized exchanges discriminate against Wasabi all the same. So Wasabi's direct funding of blockchain analysis and their direct censorship of Wasabi users has achieved absolutely nothing for them. It would make you laugh if it wasn't so tragic. And terrible behavior from Swan as well. This new FinCEN proposal is just that - still a proposal. They are also trying to comply with regulations which don't exist yet, and are selling out their users as they do so.

This preemptive complicitness from the likes of Wasabi and Swan is disgusting. It empowers the government to push ahead with such regulations, and indeed, to go even further in the future.

I very much doubt it. They will continue to use chain analysis for transactions which don't involve centralized exchanges. They aren't going to abandon their mass surveillance just because they're achieved complete surveillance of a subset of transactions.

Because they don't have to pay for this. It's inefficient to continually pay for a block analysis company when you can just make it law for exchanges to hand you the data directly.

We have less privacy today than ever before in history, and with each passing year it gets worse and worse. Everything spies on you these days - your computer, your phone, your TV, even your car.

Yes, they can't enforce it, but they can make it illegal which as Fiatless points out will be enough to discourage the vast majority of people from buying and owning bitcoin. And it doesn't just stifle adoption for individuals, but will also stifle adoption for business and services who don't want to jump through endless hoops and start having to collect KYC information from their customers, so will just opt not to accept bitcoin at all.