On transactions, not on addresses.

Not possible.

If I create a timelocked transaction which cannot be spent for 100 years, then I won't be able to broadcast that transaction since all nodes will reject it until after the timelock has expired. The transaction won't be accepted to the mempool, so the transaction won't even show up as unconfirmed (let alone as confirmed) - it will simply be rejected as invalid. As far as the merchant is concerned, you haven't paid and so they won't release the goods.

You are confusing different concepts here, I think. There are timelocked addresses and timelocked transactions.

In the case being discussed here, the address itself is timelocked by nature of the OP_CHECKLOCKTIMEVERIFY code in the script. Only the person who owns the address can set up an address in this way. Any and all coins sent to such an address cannot be spent until after the specified block height or Unix time.

Then you have transactions which can be timelocked by nature of the nLockTime field in the transaction. Only the person(s) who is creating the transaction can set up a transaction in this way. The transaction cannot be broadcast until after the specified block height or Unix time is reached.

A merchant doens't need a "no timelocked transactions" policy. They simply won't set up a timelocked address locking themselves out of their own coins (because why would they?), and since timelocked transactions cannot be broadcast until after the timelock has expired, if someone tries to send money this way either the merchant will receive it normally, or the transaction won't broadcast at all.

My point is we do not need to wait on any further information from Ledger.

We already know the following pieces of information:

So in summary:
1 - Your Ledger Nano device creates three encrypted shards
2 - These shards are transmitted to three third parties for storage
3 - The decryption key must also be stored by at least one of these third parties, since you can recover everything using a brand new device.*

Therefore, we can deduce that at some point, all the information necessary to recover your seed phrase (shards + decryption key) must be transmitted from your Ledger Nano device to these third parties. The only way for this to happen is via your internet connected computer. It does not matter if the encryption takes place solely within the Nano device, nor does it matter what decryption algorithm is used. All the information must pass through your computer. Therefore, if your computer is compromised, your funds can be stolen.

---

*The only alternative to this is that the decryption key is identical for every Ledger Nano device and so is simply stored on the device itself and not transmitted at all, but in this case any attacker can just buy a Ledger Nano and have access to the decryption key, so it makes no difference to the final conclusion that if your computer is compromised your funds can be stolen.

It was established a week ago this is a scam, and OP has obviously disappeared after being called out for being a scammer. Why are we still bumping this topic needlessly? By doing so we are simply giving it more visibility. Please let it die.

Correct, but that doesn't affect me. There's nothing stopping anyone doing all manner of stupid things with their bitcoin, like locking it behind scripts which are impossible to ever unlock, or burning it entirely. But no one can lock up bitcoin they are sending me unless I first agree to it by creating such a timelocked address in this case (or via covenants in the future, etc.)

The source for everything to do with a Passport is viewable on their GitHub.

The physical Passport assembly can viewed here: https://github.com/Foundation-Devices/passport-assembly
The hardware for the three boards within a Passport can be viewed here: https://github.com/Foundation-Devices/passport-electronics
And finally the firmware: https://github.com/Foundation-Devices/passport-firmware

For Passport Version 2, the physical and hardware files are here: https://github.com/Foundation-Devices/passport2-hardware
And the firmware is here: https://github.com/Foundation-Devices/passport2

The companion app Envoy is here: https://github.com/Foundation-Devices/envoy

No, the coins remain under your control in either Samourai (mobile) or Sparrow (desktop), but with the obvious risk that these are hot wallets.

The central coordinator keeps track of all previous coinjoin outputs. As long as your wallet is online and connected to the coordinator, then any of your previous coinjoin outputs which you have spent are eligible to be included in a future coinjoin for free, with the new entrants paying the transaction fee as I described above. The coordinator sets this up, but your wallet signs the transaction for your input. Your wallet also doesn't need to remain online 24/7. You can shut down your phone or computer for days or even weeks at a time, and when you start it back up your unspent coinjoin outputs will still be eligible to be selected for new coinjoins.

The biggest downside to this is time. Your first mix is almost instant, since you are paying the fee. After that, free remixes can take a long time, since you depend on new volume entering the pool to create new coinjoins, and random chance that your outputs are selected. There is no time limit to how long you can wait or how many free remixes you can have, but sometimes you can be waiting over a week for a single remix.

This address (39QWbnkbcPFcrJFEB6yvVDc12eX5zqVt3y) doesn't have a private key though: It has an unlocking script, the details of which I've given above. The private key needed in the script is the one belonging to the uncompressed public key in the script, which leads to the address 1PE3udPhhcSP4RAkVVuTPwQrGidVtkcaA4.

If you try to sell someone that private key, they will see an empty (although previously used) address. To lead them to the given address you'd need to first teach them about scripting. And if they can understand the script well enough to generate the given address, then they'll see through the scam.

You have chosen "Preserve payment". This means Electrum will not change the amount(s) you are sending to the output(s) of your transaction, so any additional fee has to come from another input, but your wallet does not currently contain a suitable output which can be used as another input in to your transaction to contribute additional fees.

You have three options if you still want to bump this transaction using RBF:

1 - Send some more coins to this wallet in order to create a suitable output which can be included to bump the fee.
2 - Swap from "Preserve payment" to "Decrease payment". This will reduce the amount(s) being sent to the output(s) of your transaction, and use this money instead to pay a higher fee.
3 - If you want to "Preserve payment" and not have to make an additional transaction as in Option 1, then manually create a transaction including an additional input from elsewhere to pay a higher fee and sign it separately. (You could also do this option by importing all the necessary private keys together in to the same wallet, but this carries the additional risk which comes with handling and importing raw private keys.)

Creating an OP_RETURN output means that that data is forever stored in the blockchain, yes. However, OP_RETURN outputs are not stored in the set of unspent transactions, so they do not burden nodes in the same way that burn addresses do.

It's the only other option at the moment, since you shouldn't go anywhere near Wasabi for obvious reasons.

In terms of being cheaper - it's variable, and difficult to compare exactly. The fees for Whirlpool are all flat, as opposed to based on amounts or number of coinjoins. You have to pay a fee to join the pool, which depends on which pool you are joining. So if I join the 0.01 BTC pool, then my Tx0 pays a 50,000 sat fee. But I pay that fee regardless of whether I enroll one UTXO or one hundred UTXOs. Then each input needs to pay the transaction fee for its first coinjoin. So if we take the 0.01 BTC pool transaction I linked to in the first post, you'll see two inputs paying more than 0.01 BTC - one paying 5,000 sats more, and one paying 15,000 sats more. But then once you are in the pool and coinjoined once, you get unlimited free coinjoins for as long as you are happy to leave your coins in the pool.

So in summary, if you coinjoin a small number of UTXOs a small number of times, your relative fees are high. But if you coinjoin lots of UTXOs lots of times, the relative fees are much smaller.

As Loyce says, don't create the address in the first place.

As I explained above, the address in question is generated from a script which contains a timelock. For you to have such an address, you would have to specifically create it. It's not the case where a regular address can be turned in to a timelocked address, nor for me to send coins to your regular address and specify how or when you are allowed to spend them in the future.

This was a mistake on behalf of the person who created that address, not on behalf of the person who sent coins to that address.

Why do you think that? The upper limit as I stated above is two hours in the future based on network adjusted time. If I give it a timestamp of the network adjusted time (NAT), then that is obviously less than NAT + 2 hours.

The timestamps of my previous 2,015 blocks do nothing to change the network adjusted time.

Take the script OP shared above:


Breaking that down, we get the following:

48   -   Size of script (72 bytes)
30   -   Header byte indicating signature
45   -   Push 69 bytes to the stack
02   -   Header byte for R
21   -   Length of R (33 bytes)
00a6....460c   -   R
02   -   Header byte for S
20   -   Length of S (32 bytes)
3f87....292e   -   S
01   -   SIGHASH_ALL
--------------------------------
49   -   Size of script (73 bytes)
03   -   Push 3 bytes to the stack
a0f26c   -   Little endian encoding of 7,140,000
b1   -   OP_CHECKLOCKTIMEVERIFY
75   -   OP_DROP
41   -   Push 65 bytes to the stack
0453....a2b2   -   Uncompressed public key
ac   -   OP_CHECKSIG

Looking at the second half of this script - if we haven't hit the necessary block as specified, then OP_CHECKLOCKTIMEVERIFY will terminate the script with an error. If we have reached the necessary block, then OP_CHECKLOCKTIMEVERIFY will verify, OP_DROP will clear the stack, and then all that is left will be the pubkey and OP_CHECKSIG as it would be in a old school P2PK output.

Now, if we take that part of the script:

Take the RIPEMD160(SHA256(script)):

Add the network byte 0x05, and then compute and append the checksum:

And then encode in Base58:

So all coins sent to the address 39QWbnkbcPFcrJFEB6yvVDc12eX5zqVt3y are locked by the above script, meaning they can only be spent when we hit block 7,140,000.

If you are a newbie who cannot code, then both tasks are equally impossible. And if you are a newbie who cannot code, then you will be exponentially safer using Electrum than you would be using some random paper wallet generator you found via Google.

Paper wallets are an excellent option if you can vet the code you are using, you understand how to set up and use a truly airgapped system, and you understand how to spend from these wallets without ruining your privacy and security or losing any coins. But this is complicated to do. Suggesting them as an alternative for everyone leaving Atomic or other closed source wallets is bad advice.

So this is a completely different scenario to what you described in your first post. You cannot fix a corrupted block by editing your Bitcoin Core files, since the two things are entirely separate. You also shouldn't try to manually edit your blk*.dat files to fix a mistake, as you will almost certainly just create more errors in the process.

As nc50lc says, the correct approach to a corrupted blk*.dat file is to run Bitcoin Core with the -reindex option. This will wipe your block index and your chainstate and build them from your blk*.dat files. If it finds a corrupted block or blocks, it will request a replacement from peers.

This is poor advice.

There have been a number of paper wallet generators over the years which have also been malicious and have stolen any funds sent to the paper wallets they generate. And even if someone happens to pick legitimate paper wallet software, paper wallets are difficult to set up and use correctly without making a critical mistake, exposing your private keys to the internet, sending your change to an address you cannot access, and so on. They should not be used by newbies as a "best place to start".

The best advice for newbies who cannot review code has always been to choose an open source, reproducible, widely used, widely reviewed, and reputable wallet. This is why Electrum is so popular and so often recommended

With the discussion of 2 out of 3 custodians being compromised, don't forget that this set up has a single point of a failure, and the breach of this single point of failure is enough to steal your coins.

Just like every other Shamir's Secret Sharing set up, there is a single point of failure in the device which is used to create and communicate the secret shares. For Ledger Recover, even if we assume that the Nano S/X hardware device itself is secure, the only way for those shares and the associated decryption key to leave the Nano device and reach the third party custodians is via your computer. Therefore, your computer must receive, store, process, and transmit all the information necessary to empty your wallets. If your computer is compromised while you do this, or if the data is stored in memory and recoverable, then your coins can be stolen by compromise of your computer alone. This is the exact same situation as any hot wallet.

Just as a cold wallet which has connected to the internet once or twice is no longer a cold wallet, a hardware wallet which has exposed your seed phase to the internet once or twice is no longer a hardware wallet.

This is the exact same method as using QR codes to transfer transactions between online and airgapped wallets. This method simply says "transfer the transaction file to your offline machine (e.g. with a usb stick)."

Transferring with QR codes or USB sticks are both equally possible. I prefer using QR codes for two reasons. First of all, it's a bit quicker to simply point a camera at a QR code than it is to save a file, transfer to a USB stick, and move that USB stick between devices. Secondly, and more importantly, is it is harder to transfer malware or leak private keys via a QR code than it is via a USB stick. Even the smallest USB stick will have hundreds of megabytes of empty space in which malware could copy itself to, whereas this is largely not possible (or at least far more difficult and noticeable) with QR codes.

So yes, you can use USB sticks if you like, and it is still very safe, but QR codes are safer (provided you are double checking everything as I explained two posts up).

Let's say I implement a change which considers all segwit transactions invalid. As such, my local chain rolls back to block 481,825, and I consider everything after that invalid. Even before I successfully mine a block at height 481,826, can we not say that I am working on a forked version of the main chain?