Lol, what? So it's Samourai's fault if users consolidate inputs together even before they go anywhere near Whirlpool in the first place?

You can absolutely spend it. If it's large enough, coinjoin it in a smaller denomination pool. If it's too small for that, swap it for Monero or for Lightning. Easy peasy.

That's not what you said. You said that Whirpool doesn't provide "any anonymity at all", which is clearly false.

But hands all your addresses and UTXOs directly to a blockchain analysis company.

Right. So address reuse is stupid, but when Wasabi reuses addresses, that's ok?

I really don't think you want to play the "cherry pick individual transactions" game, but since you started it, then how about this one: https://mempool.space/tx/dae13b2d015587a3033d7ab7949a7efa6d6ed7aa782168b0651ab37a2d8390f8

There is exactly one input which could have created the 6.46652537 BTC output. Zero privacy gained.
That 6.46652537 BTC output is then coinjoined a second time with Wasabi, and again, there is an output of 4.39250624 BTC which could only have come from that input. Zero privacy gained.
Great job Wasabi!

If you choose to encrypt the wallet file, then you can gain no information whatsoever without the password.
If you add a password but choose not to encrypt the wallet file, then only the private keys are encrypted. This means you can open the wallet file and view the addresses, balance, and transaction history, but cannot spend anything without the password.

---

I would add that taking advice from accounts with zero trust asking you to message them privately is incredibly high risk. You can very easily set up and run btcrecover yourself, and you can get all the advice you need to do that in public on this thread.

At the pre-mix stage, Whirlpool splits an input in to multiple inputs of the size needed to enter the corresponding pool. Each input the enters the pool separately. Where is the consolidation exactly?

It sends non-private change to a completely separate account and the software prevents users from combining it with coinjoined outputs.

Absolutely nonsense speculation. Zero anonymity? You are suggesting that no one interested in coinjoining and privacy is running their own node?

Except when they are linked to each other, as I've shown you evidence of three times previously and you've ignored each time: https://bitcointalk.org/index.php?topic=5286821.msg61947309#msg61947309

Except you have absolutely no idea what the liquidity of the rest of the round will be, and are entirely dependent on other users' inputs, meaning you don't need to be a "whale" at all in order to receive absolutely zero privacy from a Wasabi coinjoin.

Titanium is probably the gold standard (pun intended) metal to use. It has a slightly higher yield strength than stainless steel, has a slightly higher melting point, is slightly less reactive, is slightly less conductive, and so on, but it is also significantly more expensive. These extra benefits are almost certainly meaningless - both will survive any kind of house fire or other household accidents or events equally well (provided they are of sufficient thickness), and it would take things like exposure to a blast furnace or some industrial strength acid before you noticed a difference.

If you have some titanium lying around then go ahead and use it, but there is no point coughing up the extra money when stainless steel will work just as well for all realistic eventualities.

It depends what metal you use.

The general advice if going for a metal back up is to use stainless steel, since this gives a good balance between hardness, fire proof, corrosion proof, as well as cost. In general, stainless steel is a very poor conductor of electricity and poorly magnetic when compared to most other metals, and can often go undetected by metal detectors, especially if it is very small in size. If you are very concerned about such an attack, then just use two or more paper back ups in different geographical locations. This is generally better than a single metal back up anyway.

I have to say though, if you have a thief in your house using a metal detector to find your metal back up, then your op-sec has spectacularly failed and everything you have is probably at risk by that point.

Or just use a coinjoin implementation which is not actively coordinating with blockchain analysis, is not anti-privacy, and is not pro-censorship.

JoinMarket remains the best but also the hardest for the average user to use. So for them they can either download Samourai on mobile or Sparrow on desktop and use Whirlpool.

Hmm, decisions! I'm still tempted by the Orange Pi, but perhaps I'll see if I can pick up a second hand laptop on the cheap first (or even better, see if a friend has one they aren't using they could lend me for a while). I'll get it all set up and running everything I want, and see how it handles it and what the power usage is, and then decide if I want to keep that set up long term or if I want to commit to purchasing an Orange Pi.

Given that I'm using a laptop and not a SBC at the moment, I'll probably just use Debian or Ubuntu since I'm familiar with them and I know I can get everything I want running on them without issue. I'll maybe experiment with Umbrel in the future.

You need to change "internal" to true, and you also need to change the derivation path after the xpub from /0/* to /1/*
I have given you the commands to import in my post above. Just copy them and follow my instructions.

This is not the way to do it. You should import "sh(wpkh([00000000/49'/0'/0'/xpub..../1/*))"

To get the correct checksum, either use getdescriptorinfo first, or just copy the correct checksum from when it tells you your incorrect checksum doesn't match the expected checksum.

Neither of them.

The fingerprints that jlopp site gives you are the fingerprint of that specific xpub and the fingerprint of its parent. So in this case you are getting the fingerprint of the key at m/49'/0'/0', and the fingerprint of its parent at m/49'/0'.
In the bitcoin core descriptor, the fingerprint is that of the key at m. Since we don't know it, I simply substituted "00000000". This will make no difference to importing the descriptor.

Note that there is no such thing as a YPUB. There is either a ypub, which is P2WPKH-P2SH, or there is a Ypub, which is P2WSH-P2SH.

First of all, double check that you have a ypub and not a Ypub. The two are different things. The rest of what I say below will assume you have a ypub (which you should have if you are using a standard nested segwit path at m/49'/0'/0', as you say).

First, you need to convert that ypub to an xpub. The easiest way of doing that will be to paste it in to this site: https://jlopp.github.io/xpub-converter/. Select the top option from the drop down box (xpub), and hit convert.

Then, run the following command, changing the xpub for the one you have just generated from the above site:


It should hopefully return the following:


Now, run the following command, again changing the xpub to your own one, and also changing the "xxxxxxxx" to the 8 character checksum you just produced above. (Yours will be different from my example). You can also change the timestamp to a more appropriate time - this is the Unix time from which Core will start rescanning the blockchain looking for transactions. If you know when the first transaction to this wallet is, you can change it to a little before that time. If you aren't sure, leave it at 0, but it will take a while to perform a full scan.


You'll also want to repeat the process with the following command, which will add change addresses:

As PowerGlove points out, of all the open source wallets out there, only the minority are actually reproducible from the code provided. Take a look at https://walletscrutiny.com/ for example, and see that the majority of open source wallets are either unreproducible or throw errors and do not compile at all.

Yeah, that's mainly why I was looking at Orange Pi, which has 16 GB and 32 GB models.

What do you mean by "an Umbrel"? Umbrel is software which can run on any device. I've not used it before but on reading about it seems like it would be perfect for my use case.

This is very useful, thank you. As I suspected, a Raspberry Pi would struggle to handle the additional non-bitcoin stuff I'm looking to run on it as well. What OS are you using on your Pi?

Not a bad idea at all. I'll look in to it a bit more.

True, but I figured an Orange Pi 5 with 16 GB (or even 32 GB) would be capable of running what I've listed above. But maybe I will go down the micro PC route...

So this likely means that your first node actively reorganized, while you second node simply observed the reorganization.

valid-fork on your first node means that this node downloaded and validated the now stale block. Presumably it did this and followed the stale chain for a short time until it became aware of the main chain and reorganized.

valid-headers on the other hand means that this node validated the headers and downloaded the block, but by the time it downloaded the block it was already aware of a better chain and so never bothered to fully validate the rest of the block.

Correct.

There was a block found by Foundry USA at this height with the following hash: 0000000000000000000388f42000fa901c01f2bfae36042bbae133ee430e6485
This block now no longer exists.

The competing (and winning) block was found by ViaBTC with hash: 000000000000000000014bdfbf46969d9b1f290ad21f27f263e14881ef595627

I suspect very few people (if any at all) will be downloading the binaries and then decompiling them to check they match the published code. If someone is able to do all this, then the likelihood is they will just download and check the code and compile the binary themselves. It would also be entirely possible for the developer to hide some code which does nothing for several weeks or months before it activates, so as to fool the community in to thinking the software is clean and maximize how many people will download it.

It is also possible to obfuscate the code so that if someone does decompile the binary it is near impossible to interpret.

Part of the network will accept Block A, and part of the network will accept Block B. The part of the network which accepts Block A will see the coinbase transaction which sends the block reward (6.25 BTC subsidy + fees) to Miner A. The part of the network which accepts Block B will see the coinbase transaction which sends the block reward to Miner B. Both Miner A and Miner B will, according to different parts of the network, have received the block reward for their blocks at the same height.

Once either Block A+1 or Block B+1 is found, then the entire network will switch to the winning chain. The block which is not built upon will be discarded, and so the coinbase transaction which rewarded that miner will no longer exist.

This is sort of correct, but the terminology is poor. First, it is not necessarily the longer chain, but the chain with the most work. These are usually the same thing, but not necessarily so. Also, nodes can't choose a "block that has the most proof of work". Two blocks mined at the same height as in this scenario both have the same amount of work. The chain split will be resolved when a new block is found on top of one of those two competing blocks. Only at that point will one chain have more work (in the form of one additional block) than the other chain and therefore be the main chain which all nodes will converge on.

As I explained above, orphan block is the wrong term here, but lots of people use it by mistake. But yes. Once one of the blocks is built on top of, then the competing block is discarded and becomes a stale block. Any transactions which were in this discarded block but were also in the mined block will just stay as confirmed. Any transactions which were in this discarded block but were not also in the mined block will return to being unconfirmed.

There will be a chain split. Both miners will temporarily get the full reward for their individual block. Some of the network will accept Block A, while some of the network will accept Block B, both at the same height. Whichever block is built on top of first by another block will be kept, and the block which is not built on top of will be discarded. This is known as a stale block, although you will sometimes see it (incorrectly) referred to as an orphaned block.

Let's say the next block found is Block A+1. The part of the network which initially accepted Block A will continue on as if nothing happened. The part of the network which initially accepted Block B will now discard Block B and swap to the other chain, since Block A and Block A+1 represent a chain with more work.

As above. Both miners will temporarily get the full reward, but when the split is resolved and one block is discarded, then that miner will lose their reward. Block rewards are not spendable for 100 blocks, so there is no concern here about the block reward being spent in the interim.

Yes, hundreds of times. The most recent such split I am aware of was when two blocks were mined at height 783,830, which was just a few days ago.

Again, it isn't. If you build the binary yourself from the publicly viewable code, then even if you don't read the code yourself you have some additional protection from having the eyes of the community on the code.

I would assume that if someone's PGP key is compromised, then their entire system is probably compromised and so stealing their login for GitHub would be trivial.

Pi 4 or Pi 4 Model B? Are you running a variety of things at once on it? Given I want to simplify everything on to one device, I'm looking at running all the bitcoin apps I mentioned as well as potentially streaming media to multiple devices simultaneously. Can your Raspberry Pi handle all that?

I'd be happy to use something like that rather than a SBC, but a quick search seems the power draw on such devices will be anywhere between 5-10x more than a SBC. As I say, I'm looking for something with as little power draw as possible (for potential off grid use) while still being able to handle everything I've listed above, so I'd probably only buy a more power hungry device like that if it was absolutely necessary.

Good thinking. I already run RAID on my main storage, and I have some spare drives I could use to RAID everything except the blockchain itself.

I wouldn't plan on ever doing this. I really just want something I can set up and forget about.

Yeah, it seems an Orange Pi 5 at idle will consume <2W. If I was to use a laptop, I'd probably just disconnect the screen and any other hardware I don't need to reduce the power draw, though.

With the death of some old hardware I was using to run one of my nodes plus a few other bits and pieces, I've decided I'd quite like to simplify my always-on home hardware down to a single device.

With that in mind, I'm looking for both hardware and software recommendations for a standalone device capable of running the usual Bitcoin and Lightning nodes, but in addition to that, an Electrum server, an instance of mempool.space, a coinjoin server (be that JoinMarket or Samourai Dojo), and Bisq. I'd also like to potentially use this device to run a variety of non-bitcoin software, such as Pi-hole, personalized cloud storage, potentially a home media server, that sort of thing. Having looked in to it a bit, it seems that Umbrel might be the most straightforward way to do all this, and can run everything I've listed above except Bisq (although an app appears to be in the works).

My first question is whether anyone who has experience with this kind of thing would disagree about using Umbrel and would suggest just running something like Debian (or any other Linux distro)?

My second question is whether anyone could suggest some hardware which would be most appropriate for this. My main considerations are low power usage and being powerful enough to run everything I've listed above. I had originally looked at a Raspberry Pi 4, but I have some concerns about whether it could handle everything listed. At the moment I'm sort of considering the Orange Pi 5. I don't actually need it to be a single board computer at all - I'm just looking for energy efficiency with good enough hardware.