The point there is to use a better wallet. Network rules are not bound or limited by third party developers failing to implement basic functions in their software. Being able to replace an unconfirmed transaction is an increasingly basic function of bitcoin. If your wallet does not allow you to do that, then find a better wallet which does.

The only danger is if you accept zero confirmation transactions. However, these have never really been safe to accept in the first place, but some businesses accepted that risk for the convenience they brought. Full RBF makes no difference to confirmed transactions.

Hot wallets are insecure. This is just a fact of life. Yes, we all use them, but the funds in them are never truly secure. Think of all the apps on your phone, all the links you click on, all the files you download. Any one of these could contain malware.

Alternatively, are you absolutely certain no one could have accessed your seed phrase? You've never typed it in anywhere, or imported it to any other wallet, or saved it electronically, or even copied it to a clipboard? I've seen lots of cases where people have been careless just once, and that's all it takes for their coins to be stolen.

Miners, as in the large ASIC farms you are probably thinking of, don't have mempools. Nodes have mempools.

When the node belonging to a mining pool operator receives a block, it must validate that block and every transaction in it. Once it has done that, it must remove all the transactions in that block from its mempool. Then it must construct a new candidate block from its updated mempool, before calculating the Merkle root and then sending that block header to miners to be worked on. All this takes some time. Rather than having thousands of ASICs sitting idle during this time (and therefore wasting money), it will have them work on an empty block for the few seconds it takes for this process to happen. Occasionally they get lucky and mine an empty block.

If mining pools immediately created candidate blocks which were full, then chances are they would end up including transactions which were already confirmed in the block they just received but had not yet validated. This would result in this candidate block being invalid. So instead they create empty candidate blocks, and then update them to full candidate blocks a few seconds later once they have fully validated the last block.

Also note the timestamps on blocks are not actually accurate enough to tell you how long it took between mining blocks. The timestamps give an average time over days to weeks, but are inaccurate at the individual block level.

12 words are more than sufficient. 24 words are harder to brute force, yes, but brute forcing 12 words is already impossible. The number of words makes no difference if an attacker compromises your back up.

If the seed phrases from your multi-sig set up have never touched an internet connected device, then they remain as safe as possible.

What you should really be focusing on is how your hot wallet was compromised. How did you store the seed phrase back up, and did you import it anywhere else? It could well be that the device which was hosting this hot wallet is infected with malware, meaning you will need to think about formatting it and reinstalling your OS.

Amazing you finally got it working. Big props to nc50lc for the ingenious solution!

The error messages just mean the signature was incorrect for whatever reason (most likely it was signed with the wrong private key). I'm also curious about the derivation path and am half tempted to download the wallet myself to figure it out, but at the same time I don't want a wallet with such a crazy system as a 1-of-1 multi-sig and unknown back up processes on my computer.

This is a great lesson for everyone - stick to the industry standards. When you try and do weird things in terms of addresses, scripts, seed phrases, back ups, etc., then more often than not you just create more problems than you are trying to solve.

In case anyone was unaware, mempool.space have implemented an RBF tracker which also tracks all full RBF replacements. You can find a ticker on the landing page, or the full view here: https://mempool.space/rbf

I'm also noticing a lot more full RBF replacements, as well as more mining pools including them, such as AntPool, F2Pool, and Binance pool.

You can read the discussion regarding this change here: https://github.com/mempool/mempool/pull/3867

He's too far in at this point. He knows that everyone knows he isn't Satoshi, but he can't admit he's been lying all these years because he'll end up in jail for the amount of blatant fraud he's committed, much of it under oath. He will never stop. Not to mention he is massively in debt and his lifestyle is being entirely propped up by the handful of rich idiots he has managed to fool or are complicit in his lies in the hope of future gains. Unfortunately for them, the price of BSV speaks for itself, as it recently hit an all time low of just 0.001 BTC.

Bear in mind this case had nothing to do with whether CSV is Satoshi, only if he had been defamed by McCormack's statements. While it is easy to point out lies in his written and oral testimonies, I still worry that judges will be less able to point out the lies in any technobabble CSW spews forth.

---

And the most recent piece of CSW lulz: https://nitter.nl/hodlonaut/status/1684123886139453441

CSW wants the court to throw out the statements made by CSW, as CSW claims CSW's statements are "rank hearsay". 

Yeah, I'm looking forward to this. They already have a prototype running on testnet apparently: https://nitter.nl/SamouraiDev/status/1679092893171040256#m

Would be great to run your own coordinator over the same liquidity pool, kind of like how Joinmarket works. I wonder if their fee model will change if you are running your own coordinator?

Ahh right, sure.

You'll want to go back to the mempool.space page for the transaction you sent me, click on "Details" again, and copy and paste the text after where it says "OP_PUSHBYTES_37" for each address. There's one of those for each address. Each one will start with "5121" and will end with "51ae".

If you paste that string in to coinb.in and hit load, it will find the address.

That's an entirely separate court case involving CSW and Cobra, rather than Peter McCormack. So no, this judgement won't make any difference.

UK users can of course trivially bypass this using Tor or a VPN, or simply download from here instead: https://bitcoincore.org/bin/

Full judgement here: https://www.judiciary.uk/wp-content/uploads/2023/07/Wright-v-McCormack-judgment-260723.pdf


More damning quotes to go with all the damning quotes from the original trial. Love to see it.

The original trial was not whether or not CSW's claims about being Satoshi were true (they obviously are not), but whether McCormack had hurt CSW's feelings by calling out his bullshit. Since McCormack was technically guilty of that, then CSW won that trial. But since CSW is so completely full of shit, the judge awarded him only £1 in damages. My understanding is that by letting CSW "win" the trial, the judge closed off some avenues of appeal which CSW would otherwise have abused. CSW is now appealing on the grounds that he should have been awarded thousands in damages instead, and three higher up judges have all just agreed with the original judge, so all he gets is £1.

Still waiting and hoping the he is also forced to pay McCormack's legal fees.

I mean, surely any OP_RETURN output can be a vanity output given that you can encode any arbitrary data you want in it. It's just a case of decoding the script in to ASCII characters, which is really no different to when we encode the script to Base58 or Base32 to generate a vanity address.

For example, https://mempool.space/tx/27f9a5ddbee89c7471c4fc6456599d923d60e7d8d83e4ba51bd688f72e3baeca. Counterparty could just have easily had people send coins to an OP_RETURN output called "Counterparty".

I am forgetting that mSIGMA has not been updated since 2017, and that Electrum exports transactions in PSBT format, which was only released in 2017 in BIP174. I wonder if this is the issue.

Why not try importing your addresses and creating the transaction using https://www.coinb.in/#newTransaction instead. This will export your transaction as plain hex, which is hopefully the format mSIGMA uses too, and then try importing that to mSIGMA for signing?

If that fails, then I think the easiest thing is going to be to try to sync your mSIGMA wallet with NotATether's node as he kindly offered above.

As global hashrate goes up, then we find blocks more quickly. As we find blocks more quickly, the difficulty adjusts every 2016 blocks in order to maintain the average block time at 10 minutes. It does this by reducing the target number miners are trying to find. By making the target smaller, we need more hashes in order to find a number which meets that target, hence it is more difficult.

Sometimes the hashrate falls and so the difficulty adjusts downwards (making the target larger), but it's been pretty close to an exponential trend upward for many years. You can see all difficulty adjustments here: https://btc.com/stats/diff

This, however, is all to do with mining blocks, which uses hash functions. This is completely separate to the security of private keys, which uses elliptic curve mathematics. The security of your private keys will be 128 bits regardless of where the network as a whole has 100 hashes per second or 100 trillion hashes per second.

Correct. You can't prove it, so calling it a "proof of burn" is misleading. Coins in burn addresses are not provably burned. Coins in OP_RETURN outputs are.

I disagree.

If a users looks at this transaction (https://mempool.space/tx/d83973b11443e6151ef62f5644e92599c9ec9824b0fc128eeee64903972f2c98), they see coins being sent to a funny looking address, but an address nonetheless. I wouldn't expect a newbie to know that such an address is likely unspendable.
Conversely, if they look at this transaction (https://mempool.space/tx/af0bfe175f4e04a6958984534b4e98a45fd2ea227d321c9c50448ab5250fdcf1), they see coins being sent to something called OP_RETURN which is very clearly not an address. It is much more obvious that something unusual has happened to these coins which means they can't be spent.

This sounds like your transaction is too large for mSIGMA to handle for some reason. Are you trying to consolidate a lot of inputs at once? Perhaps split your transaction in to two and try again with fewer inputs?

Ahh well then, that changes everything! This should (hopefully) be the easiest option going forward then. What I would do is the following:

• Get a list of all the addresses which still have funds on them
• Create a new Electrum wallet, select "Import bitcoin addresses or private keys", and insert all your addresses
• In that Electrum wallet, create a transaction sending all those coins to a regular address you control
• At the bottom left of the transaction window, select "Export" (you might have to select "Finalize" first), and export to clipboard
• Import it from the clipboard in to mSIGMA and (hopefully!) sign it
• Export it from mSIGMA, import it back in to Electrum, and broadcast it

It's here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020937.html

It's not possible for the Lightning network to start using version 3 for its mainnet transactions without mainnet upgrading to allow version 3 transactions, so version 3 will absolutely be coming to mainnet too. It won't be a case of "all transactions" as OP suggests, though - we still have plenty of version 1 transactions despite version 2 being the standard for years now. I assume what will happen is Core and the main Lightning implementations like LND will start using v3 first, various other Lightning wallets and clients will then be the next to switch over the following months, and wallets and clients which don't use Lightning will just stick with version 2 for the time being.

For OP, you can track the progress of v3 and package relay here: https://github.com/bitcoin/bitcoin/issues/27463. It seems there is still lots to be done, and there is no mention of it in the 26.0 milestones, so at the very earliest you are look at 27.0 which is almost a year away.

This is almost certainly the same address which another used claimed to have created in this thread:
https://bitcointalk.org/index.php?topic=5455368.msg62364885#msg62364885
Archive - https://ninjastic.space/post/62364375

It seems that a scammer might be selling the private key to this timelocked address to multiple users who then realize they are unable to claim the coins and come here looking for help.

If ECDSA is broken and it is possible to recover the private key from the public key, then even if we depreciate ECDSA signatures then there is nothing stopping an attacker still recovering the private key and also making a transaction on the new algorithm and stealing your coins. As discussed above, the only way around this would be to require a zero knowledge proof of some other piece of information such as the parent chain code or the seed phrase which derived that private key, but that would only be possible for addresses which were part of an HD wallet.

Rather, we would need to have a quantum resistant address type well in advance of ECDSA being broken, everyone would have to generate new quantum resistant addresses from new private keys, and then move their coins to these addresses prior to them becoming vulnerable.