"Hey China. I know we owe you over a trillion dollars. But we are just going to not pay that and write off the entire currency. Sorry you lose all that money. Hey, want to sell us some goods? We're going to pay in USD2.0. This time you'll definitely get paid back though! Pinky promise!"

Right. I'm sure that will work out swimmingly!

But the Fed can't print platinum out of thin air, so of course that will never happen.

Multiple suggestions making the rounds on Twitter that Coinfirm is the secret blockchain analysis company which Wasabi is partnered with. For example:

https://nitter.net/LaurentMT/status/1654501466537615361#m
https://nitter.net/1440000bytes/status/1654688048125460481#m

And in a piece of spectacular timing, the CEO of Coinfirm posts this thread (https://nitter.net/MirceaMihaescu/status/1653441220805263388#m), boasting about how Coinfirm deanonymizes bitcoin transactions.

There is no need to "cancel" a transaction first, and indeed, there is no such thing as cancelling a transaction. All you are doing when you cancel a transaction via RBF is using RBF to replace the transaction with another one which sends the funds back to yourself. If you are then going to send those funds back out with a higher fee, then there is no need to send them back to yourself first. You can just directly replace the existing transaction with your new one.

You sound confused. Once a transaction has its first confirmation, the fee it pays and how congested the mempool is are both irrelevant. It will gain one more confirmation with each and every block which is found from that point on.

Miners do not broadcast transactions. Nodes broadcast transactions to other nodes, while miners use the data from their node to generate a block to attempt to mine.

---

I'll link here my response in another thread for anyone else who is interested: https://bitcointalk.org/index.php?topic=5451060.msg62205489#msg62205489

In addition to hosseinimr93's suggestions above, there is also package relay in development which would allow you to use CPFP even when the parent's fee is too low to be accepted to the mempool, and you can sign the timelocked transaction with a specific SIGHASH which would allow the recipient to add an extra input in order to pay a higher fee.

Lol what? And how do you expect us to import literally anything when we've just shown the entire world that our currency is completely worthless? How do we operate on a global scale when we just ignore the trillions of dollars in debt we owe other countries?

The Fed don't actually have to mint physical coins - they can just change numbers on a screen to print trillions of dollars. And there are plenty of examples of countries undergoing hyperinflation which will show you what would happen if we start printing quadrillions of dollars.

But this is only true if you have backed up your master public keys as you should have done. If you only have seed phrases, then to recover your wallet you must import all those seed phrases in to the same device, which completely removes the benefit of a multi-sig wallet requiring the compromise of multiple devices.

No problem. Happy to help.

As always, before you lock up any significant amount of bitcoin, create a test transactions first with only a very small amount of bitcoin which has both a timelock and uses SIGHASH_SINGLE | SIGHASH_ANYONECANPAY, check you cannot broadcast it before the timelock is up, and then check you can add a second input to it and broadcast it after the timelock is up.

So you can already do this, but it requires the timelocked transaction to be set up in a specific way when it is first created.

All bitcoin transactions contain a field known as the SIGHASH. You can read more about this here: https://btcinformation.org/en/developer-guide#term-signature-hash. Essentially, it's a field which tells the protocol which part of the transaction you are signing. The vast majority of transactions use the default SIGHASH_ALL, which as the name suggests, means you are signing all the inputs and all the outputs, so no inputs or outputs can be changed or added.

However, there are other options available. For this scenario, the person making the timelocked transaction could sign it using SIGHASH_SINGLE | SIGHASH_ANYONECANPAY. This means that they sign their input and output so these cannot be changed, but they allow the addition of other inputs and outputs in to the transaction as well. So years later you can take the timelocked transaction, add your own additional input to it, use some of that input to pay a higher fee, add your own change address for the rest of your input to go to, and then sign and broadcast this new transaction. The core of the timelocked transaction (send x BTC from A to B) can't be changed, but you can add an extra input and output to increase the fee before you broadcast it.

At the moment, yes, those are your only two options.

When you broadcast transactions to other nodes, each transaction must pass all policy requirements on its own merits. It doesn't matter if you also broadcast a CPFP transaction with a high fee - receiving nodes will not at present consider both transaction as a unit, and so the parent transaction with the low fee will not be accepted.

However, there is a proposal known as "package relay" in active development which would change this. This will allow you to broadcast a "package" of transactions, and have receiving nodes consider the overall fee rate of the entire package, not the individual fee rate of individual transactions. See here for more information: https://github.com/bitcoin/bips/pull/1382. This means that you could simultaneously broadcast your low fee timelocked transaction along side a high fee CPFP transaction, and have nodes accept both based on their overall fee.

The transactions are stored by both parties involved in the channel. Lightning software does this automatically.

They are just as immutable as any other bitcoin transaction. Lightning channels are a 2-of-2 multi-sig, so both parties must sign every transaction, and neither party can edit or modify the transaction without invalidating it completely. The risk is not in one party being able to change one of the transactions - as I said, this is impossible. The risk is with one party attempting to broadcast an old outdated transaction which favors them more than the most recent transaction. But as I mentioned above, if one party tried to do this, the other party can take all their coins as punishment.

RBF will definitely help, and my default settings node has a current minimum fee of around 10.9 sats/vbyte, which is in keeping with mempool.space's 11 sats/vbyte. Seems like you are just connected to a bad server.

Correct. Transaction size (and therefore your fee) is based on the number of inputs and outputs in your transaction, and not on the amount of bitcoin being sent.

Electrum.

Your transaction is opted in to RBF, so it is trivial for you to bump the fee using Electrum if you wish. So either do that, or just wait. (You'll likely be waiting at least several days, though.)

10 sats/byte. Note that it is per raw byte, not per virtual byte.

Half the point of a multi-sig is to have redundancy in the set up. A 2-of-3 wallet allows you to lose one seed phrase and still be able to recover your wallet, provided you have all three master public keys. If you don't save the master public keys, then you need all three seed phrases in order to recover the wallet, even if the wallet itself is 2-of-3.

You should absolutely back up your master public keys alongside your seed phrases. Without a copy of your master public keys, then you need to recover every single one of your seed phrases, which defeats the point of having a threshold number of signers.

Yes.

You could try actually reading this thread. It is already implemented, but only a minority of miners have currently enabled it.

As I said above - pay a mining pool to include your transaction privately, so by the time it is public it is already confirmed.

As soon as you broadcast the transaction, it is not possible to prevent double spending.

It is not an address on the bitcoin network, but rather an address on the Whirlwind platform.

They should be sending coins via the Whirlwind website (not via a bitcoin wallet) to the address which starts with "ww".

Sending coins to 12xmfzikTonuQc3iw7Xezvd9qwHibxryRj via a standard bitcoin transaction will not have them show up on Whirlwind. This is just a standard bitcoin transaction. You could access these coins by importing your Whirlwind private key in to a normal wallet, but this transaction has nothing to do with Whirlwind.

If someone wants to send coins to ww2xmfzikTonuQc3iw7Xezvd9qwHibxryRj, then they do so via the pay to note feature on Whirlwind. These coins will only show up on Whirlwind and will not show up on the bitcoin network.

It is not possible to use Electrum (or any other bitcoin wallet) as you have tried to do to sends coins to an address which begins with "ww", as such a transaction will be invalid.

Why do you keep posting when you consistently ignore all the advice you are given? You have been told multiple times in this thread and your other one I linked to before that you should use something like https://mempool.space/ to select an appropriate fee. Picking the same fee you used before is in no way an appropriate way to select a fee.

Correct. You will be waiting an unknown amount of time given the current mempool. Could be a few hours, could be two weeks and your transaction doesn't confirm at all.

Did you enable RBF as previously suggested? I suspect not.

Someone can already do this and pay a mining pool privately to include their competing transaction over the one in the mempool. Full RBF makes it easier, but it is already possible.

If you don't want the public key revealed, then you could also do the same and pay a mining pool privately to include your transaction.

We are specifically talking about full RBF, not opt-in RBF.

We know part of what will happen, because it's happened several times before: https://en.wikipedia.org/wiki/Government_shutdowns_in_the_United_States

Government departments shut down, and millions of employees have their pay delayed or just aren't paid at all. The economy takes a hit of billions of dollars. If it goes on long enough, then emergency funding for things like social security, medicare/medicaid, food stamps, etc., runs out, and so all these things shut down as well, and we cease to pay the interest on our debt. If we default on our debt, then who knows what happens at that point. All government spending stops. The stock market crashes. Millions of job losses. Economy tanks. Borrowing costs rise. The global market starts to abandon the US dollar, compounding all these problems further. Will make 2008 look like a blip.

100 years ago the US national debt was somewhere around $20 billion, so around 0.06% of where it is today. It took about 60 years from then to hit the first trillion dollars. And yet in the last 10 years, we've added 15 trillion dollars. 60 years for the first trillion, now an average of 8 months per trillion. Not only is the debt constantly increasing, it is increasing at an exponential rate.

The debt cannot continue to increase unchecked indefinitely. At some point, we hit a debt crisis where the interest payments alone are unsustainable. And the whole thing comes crashing down.

Indeed. So make sure they know nothing about your assets to start with. Never complete KYC, only trade peer to peer, obfuscate your transactions through mixers or coinjoins, run your own node, self host everything, and so on.

I was putting the first three things in the list as one category under "government spying", but I take your point.

Well, since you were talking about 1984, then I'm sure you'll agree 2+2=5.

Yes, but doing so is pointless. If you are going to create or restore the wallet only using seed phrases, then why have a multi-sig wallet at all? The whole point of a multi-sig is to remove the single point of failure. Each wallet should only be created or restored using a single seed phrase, and the master public key from all the other shares, so that any single wallet is insufficient to spend the coins. If you are going to create or restore your multi-sig by putting all three seed phrases in to the same device, then all you have achieved with your multi-sig is increasing the size of your transactions and the fee you have to pay.

Each seed phrase should never leave the device on which it was generated, other than to be written down by hand as a back up. The only thing which should be transferred between devices are the master public keys.