The wallet itself is still 2-of-3, but if you have neither the seed phrase nor the master public key from the third share, then the first two seed phrases alone cannot regenerate your wallet and so cannot spend the coins. If you only back up three seed phrases and lose one of them, your coins are lost.

You are correct in saying all the master public keys only allow the creation of watch only wallet which cannot spend your coins, but such a wallet also completely compromises your privacy and makes you a target for the attacker who was able to compromise your master public keys to now attempt to compromise your seed phrases.

---

You have three options, ranked in order of security from best to worst:

1) Write them by hand carefully, double check your work, and then test that you can recreate the wallet from what you have written. If you can, then you can rest assured you have not made any mistakes.
2) Print them using a dumb printer.
3) Save them electronically.

This discussion happened yesterday in IRC: https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2023-05-04#919305;

Looks like fairly unanimous support for adding Russell Yanofsky as a new maintainer. As achow101 mentioned, a GitHub proposal should appear in the coming days.

So with the recent surge in transaction fees and backlog of unconfirmed transaction, there has been a definite increase in the number of full RBF replacements being mined.

While previously we were maybe seeing 3-4 a day, there are now upwards of 20 a day. I'm also seeing more starting to appear in blocks being mined by F2Pool, in addition to those being mined by Luxor.

As before, you can check it out for yourself here: https://fullrbf.mempool.observer/

Nail on head. KYC is about mass surveillance, nothing more.

And again. I've brought this up several times before - there is absolutely zero evidence that widespread KYC prevents money laundering or aids in tracking down criminals, just as there is absolutely zero evidence that mass surveillance prevents terrorism, or any of the other stupid reasons (tHiNk Of ThE cHiLdReN) that politicians give to justify monitoring everything you do.

KYC achieves two things only - mass surveillance, data harvesting, and control on behalf of your government and a variety of three letter agencies, and innocent people having their identities stolen.

Good news! Wishing you all the best.

This is a slightly tangential issue to money printing, which involves the US' arbitrary debt ceiling. No doubt we'll have the usual back and forth nonsense of both sides blaming the other while both do absolutely nothing to address the our ballooning debt, before raising it at the last minute as usual.

I mean, it's currently only $31.4 trillion and hasn't been raised in over a year! Lets bump another few trillion on there! What could possibly go wrong!

This is cool.

So for instance, if I was planning to use a bunch of different notes over the coming days/weeks/months, then rather than generate them on the website and back them up individually, I could generate a seed phrase locally and then just starting pulling individual private key/address pairs from that seed phrase to use as notes?

Well, too late for this transaction, but in future you could migrate to a better wallet which does support RBF. There really is no excuse for wallets not to support RBF when it's been around for 8 years.

None. You'll either need to wait for it to be confirmed, or wait for it to drop from the majority of mempools altogether.

First go to the history tab in Electrum, right click on your unconfirmed transaction you want to replace, and click on "View Transaction". Copy the Transaction ID (TXID) from the box at the top.
Then you need to delete this transaction from your Electrum wallet by going to the console and running the following command (replacing TXID with the TXID you just copied):


By doing this, the coins that this transaction spends will appear back on your addresses in Electrum, as if the previous transaction never existed.
Then create a brand new transaction from scratch which spends at least one of the same inputs and has a high enough fee to replace the unconfirmed transaction.

If you feel that's too complex then the way you did it obviously still works, but you end up paying the fees for an unnecessary transaction.

I think that is unnecessary and risks both confusing them as well as them making a mistake. There is no need for them to migrate wallet four times.

All they need is something safer than a hot wallet if they are going to be storing an amount of bitcoin which is significant to them. Personally, I'm a big proponent of a separate device, fully airgapped, connectivity hardware removed, running a clean install of Linux, with full disk encryption. But I am also under no illusion that such a set up is fairly complicated to set up and use safely, and indeed, suggesting it to everyone will definitely lead to some people messing up and losing all their coins. For most people, the best approach will be with a good hardware wallet such as a Passport.

Which wallet software are you using? The exact process will differ.

Not at all. An RBF transaction can completely change any or all of the outputs of the transaction it is replacing, including adding new outputs or taking some outputs away.

Two comments I would make on this:

First, always using the same fee is a bit dumb. Half the time you will overpay far more than you need to, and the other half you'll end up with a stuck transaction needing to bump the fee. It takes 5 seconds to load https://mempool.space/ and choose an appropriate fee.

Secondly, it seems that you used RBF to replace that transaction you linked, sent your coins back to yourself, and then immediately made another transaction to send those coins to the first address you initially tried to pay in your first transaction. This middle transaction (sending the coins back to yourself first) was an entirely unnecessary transaction. You could simply have directly replaced the first transaction with your third transaction, without the need for this intermediate transaction. All that transaction did was cost you a few thousand sats in fees.

The fact remains that your private keys are stored on a hot wallet - that is, a wallet which is on a device with an internet connection. This exposes them to potential attacks. Even if they are encrypted at rest, they must be decrypted in order to sign a transaction or a message, an attacker could try to brute force your decryption key, they could plant a key logger on your machine, and so on.

Hot wallets as described above are one of the least secure types of wallet. You should look in to either a good hardware wallet (such as Passport), or a permanently offline system.

A separate brand new device is a possibility, but only if it never connects to the internet and remains permanently airgapped. This means not connecting it just to download an update, or just to download Core, or just to broadcast a transaction, etc. It should never connect to the internet. Put Core (or Electrum) on it via a USB drive, and transfer unsigned and signed transactions back and forth via USB drive or QR code.

Sorry, I seem to have missed this reply. I do agree. There is no doubt that setting up and using a multi-sig wallet is harder than setting up a standard wallet, with or without an additional passphrase.

I like passphrases. I think more people should use them. They provide additional security should your seed phrase back up be discovered, and they also provide plausible deniability in the event of a $5 wrench attack. However, in most cases, people will still use them on a hot wallet. At some point you need to progress to a safer set up. This could take three basic forms - multi-sig, airgapped, or hardware. Even better if you use some combination of the three, and still use passphrases on top of that too.

So yes, multi-sigs are more complicated to set up and use, but at some point it becomes worth it to just sit down and learn how to use something more complicated than a standard hot wallet for your own safety.

It is fully functional. Many of us have been using it for several years now but that doesn't mean it isn't still in an early stage of development with plenty of room to grow.

Plus it is responsible for securing millions of dollars worth of value; such things should not be rushed. Centralized shitcoins regularly have critical bugs which result in huge losses - bitcoin is different.

Block size in bitcoin has already been increased from 1 MB to 4 MB. There are very good reasons to not just endlessly increase block size, but if large blocks is what you want then there are a selection of shitcoin forks you can choose from. The fact that every one of them is constantly losing more and more value against bitcoin should tell you something though.

There are thousands of completely free pieces of software with no steady income stream out there which survive just fine. There is also a donation link on the Aegis website if anyone is so inclined.

Still, even if development stops tomorrow, nothing changes with the app you have already downloaded and are running. And of course, you should utilize Aegis' ability to create encrypted exports of your database, so even if you can't install Aegis on a new device you can still import your 2FA codes in to a different app.

I've spoken about this before too: https://bitcointalk.org/index.php?topic=5346270.msg57336047#msg57336047

The explanation is that lots of people just blindly accept the fee that their chosen wallet or website tells them, and that the vast majority of wallets and websites are absolutely awful at suggesting an appropriate fee. As you say, all it takes is one exchange to kick start the process by dumping a bunch of overpaying transactions in the mempool, and then 90% of wallets and websites out there start matching those exorbitant fees, and we get in to a vicious cycle. If everyone (exchanges included) actually just paid attention to the fee they are paying, then everyone could save 90% on all their fees, all the time.

Some wallets do not support it. Which was kind of my point - if he is using wallet software which does not support RBF, then time to find better wallet software.

And also more expensive.

As there is only a single output, and the transaction is not opted in to RBF, then the only realistic possibility to speed this transaction up would be for whoever owns the receiving address to utilize a CPFP transaction. I am assuming that the receiving address does not belong to you, so this is not an option unless you can convince the receiving party to do so.

Why did you not opt in to RBF? Silly not to, especially when the mempool is as it is. RBF would allow you to bump the fee at any time. As it stands, your options are to either wait for the mempool to empty down to 6 sats/vbyte, or if that hasn't happened within 14 days, then you correct in saying your transaction will drop.

This is incorrect.

Firstly, I would point out that bitcoin.com is a BCash scam site entirely designed to trick newbies in to believing a dying shitcoin is the "real" bitcoin. I would avoid it like the plague.

Secondly, the current average block time for this difficulty epoch is around 10 minutes and 12 seconds. This is the difference between 144 blocks a day and 141 blocks a day. This is a difference of 3 blocks and therefore 3 MvB at most, and not nearly enough to explain the >100 MvB of unconfirmed transactions we currently have.

This quote in particular goes to show the author has absolutely no idea what he is talking about:
The time it takes a single block to be found is utterly meaningless when considering the global hashrate or the average for the epoch. We could double the hashrate and still wait an hour for a block, or we could lose 90% of the hashrate and still find the next block in 20 seconds.

If you want to understand fees better, then I would suggest actually reading and understanding the responses you got when you posted a thread about fees previously: https://bitcointalk.org/index.php?topic=5437047.msg61679766#msg61679766

As I said to you before, measuring a fee in a flat amount of fiat currency is absolutely meaningless. It could be a huge overpay or a tiny underpay, and no one can tell you otherwise based on this information alone. You should be measuring fees in satoshis per virtual byte, or sats/vbyte.

The cheapest time to send a transaction is generally between around 0200-0600 UTC on the weekend. There is no need to wait for this to broadcast a transaction though, you can easily send it with a lower fee now and then just wait for it to be confirmed. If you make sure to enable RBF, then you can always bump the fee at a later date if you get tired with waiting.

If you are in a hurry, then right now a fee of 30-40 sats/vbyte is likely to be confirmed soon. If you are not in a hurry, then I would personally set it around 15 sats/vbyte and wait.