Luke's previous pool (Eligius) which has been obsolete for 6 years. It's pretty disingenuous in my opinion for the Ocean mining site to say "Blocks Found: 11,633", when in reality they've found 2.

Turns out Ocean are losing a lot on fees as well: https://nitter.cz/OrangeSurfBTC/status/1736113144269869298#m

That's a loss of 0.5 BTC per block. When you have not even mined a single block in 15+ days, that's a significant amount of fees to be throwing away through your censorship policies.

Block space needs to be limited to ensure bitcoin's long term survival.

Given that the block subsidy is halving every 4 years, it will not be long before the subsidy alone is negligible and certainly not enough to support even a fraction of the current hashrate. At that point, fees have to be sufficient to take over. For fees to be sufficient, block space has to be limited and there needs to be a full mempool and a competitive fee market. If we increase block size so everything can confirm at 1 sat/vbyte, then even for a (let's say) 16 MvB block you are still only talking about fees of 0.16 BTC.

If you want everything to confirm in the next block at tiny fees, then you need some other mechanism to pay miners once the subsidy is insufficient. That means either lifting the cap of 21 million and having constant inflation, or some other mining incentive like merged mining.

Knots nodes don't even need to advertise that they are Knots nodes - this is easily hidden. Then you are back to what apogio outlined above of banning nodes which return an error message when you broadcast your transactions, although again, those nodes could stop doing that and could just silently drop your transactions.

Very few. As above, Knots only accounts for around 0.4% of all nodes.

---

On another note, things not looking so great for Ocean: https://ocean.xyz/dashboard

With the hashrate they claim to have they should be finding around one block a week, but it's been 15 days since their last block. Seems like a number of their miners are giving up on them and their total hashrate is gradually falling.

Correct. You can see the subset of words from that list used here in Electrum version 1.1: https://github.com/spesmilo/electrum/blob/3760486a6a9279ffbd852f0be43c8f7a823a9427/lib/mnemonic.py#L23

No, it didn't. The seed phrases were still 128 bits of entropy, and there was no checksum. 12 words from a list of 1626 gives 128.005 bits. 1626 is precisely the minimum number of words the wordlist would need for 12 words to give a minimum of 128 bits; 1625 words gives 127.99 bits. Once you add the 4 bit checksum as BIP39 did and you want to encode 132 bits, then your wordlist needs to expand to 2048.

Here is the new_seed function from Electrum version 1.1 which as you can see generates a random 128 bit number: https://github.com/spesmilo/electrum/blob/3760486a6a9279ffbd852f0be43c8f7a823a9427/lib/wallet.py#L338

Exactly this. You could technically have a word list with only two words, it's just that your seed phrase would end up being 132 words long.

Technically, no. Practically, pretty much yes.

BIP39 can work with any wordlist. There are multiple wordlists in different languages, and you could even create and use your own wordlist if you wanted (although you definitely shouldn't do this). But because of the way BIP39 works, if you don't know the wordlist used then you cannot verify the checksum of your seed phrase. So if you used a customized wordlist then you would not be able to verify your checksum and might not be able to recover your wallet in any other piece of software. Because of this, every BIP39 wallet uses one of the standardized wordlists, and the vast majority of BIP39 wallets stick to using the English wordlist for maximum compatibility, since you cannot move the same seed phrase between wordlists.

My hypothesis is that it is a user that really wanted to get their transaction confirmed in the next block, but they wanted to pay the minimum fee required to do so.

Every replaced transaction has the same fingerprint - same version, same locktime, same nSequence, etc., suggesting they were all made by the same wallet. Further, every receiving address on all the intermediate transactions is a fresh unused address, and none of them are repeated. If this were bots trying to steal an output, then you would expect them to try to send to the same address or have different fingerprints. And all the transactions are opted in to RBF.

The first transaction in the chain was broadcast a couple of minutes after the last block (821,597) was mined. Given this transaction is a CPFP, then the effective fee rate for this initial transaction was 602 sats/vbyte, which was just under 1 MvB from the tip of the mempool. There was then a delay of 29 minutes until the next block, and during this time the fee was continually bumped to keep the parent and child transactions just under 1 MvB from the tip of the mempool. By the time the final transaction confirmed with an effective fee rate of 642 sats/vbyte, this was just above the minimum of 632 sats/vbyte to get in to that block.

But (AFAIK) Ledger Live does not allow you to create wallets at arbitrary derivation paths, so if this is a derivation path issue then it will be far more straightforward to use Electrum.

Yes. There is nothing stopping this from happening. There would be no way to convert "old" seed phrases to "new" ones, however.

When you use the BIP39 process, you use entropy to calculate your seed phrase, then you use the actual words in the seed phrase to generate your master keys and subsequent child keys. So even if you had two different seed phrases which were generated from identical entropy, they would both generate different wallets since it is the words themselves which generate the wallet, not the underlying entropy. If you encoded the same entropy as an English and a French seed phrase, for example, then you would have two different wallets. So if you turned an "old" seed phrase in to one using the new wordlist, you would generate a completely different wallet. And so, if you did update the BIP39 wordlist, most wallets would continue to support the old wordlist as well, as otherwise old seed phrase would become unrecoverable by that software (or at least, they could not verify the checksum on old seed phrase).

I don't think there is any point in replacing the wordlist, however. It does what it needs to do probably as well as can be done. A better solution rather than changing the wordlist would be to change the entire seed phrase generation process so it does not depend on a fixed wordlist at all and specifies what script type to use (as Electrum seed phrases do), and that it also encodes a wallet birthday.

Here's what to do to narrow down the issue:

Go the Ledger Live account on your old computer which shows the address holding your ~1.5 BTC. There will be an options button or a gear symbol or something you can click on (sorry I can't be more specific, I don't use Ledger Live) and in that options menu it will tell you the derivation path of that account which is holding your coins. It will look something like this:


Link your hardware wallet to Electrum, and when you get to the script type page, select "Legacy (P2PKH)" and enter the exact same derivation path as from Ledger Live.

If that wallet is empty, go to the console tab in Electrum (View -> Show Console) and paste the following to increase the gap limit:


If that wallet is still empty, then chances are you used an additional passphrase which you will need to brute force if you don't remember it.

There is only one user I know of who has passed this test:

https://bitcointalk.org/index.php?topic=5193860.msg52894190#msg52894190
https://bitcointalk.org/index.php?topic=5466708.msg62841234#msg62841234

Just use getpeerinfo, or click on individual peers on your peer list window using the GUI. Knots nodes identify themselves as such via their User Agent/subver string.

I don't see why not. You want your node to broadcast your transactions, and other nodes to relay them. If you found a node was arbitrarily rejecting all your completely valid and completely standard transactions based on some local setting, then being connected to that node is a hindrance for the purposes of broadcasting your transactions. That node will also not relay to you other users' completely valid and completely standard transactions which you want to learn about, for the same reason. So replacing that node with another node makes logical sense.

If you found one of your peers was refusing to relay all your transactions but you didn't know why, would you not simply replace it with another peer?

No, for the following reasons:


Why would it be unfair? Even ignoring the evidence above showing Wasabi is flawed, why would it be unfair to exclude a so-called "privacy" wallet which actively funds the enemies of privacy?

Looks like it is still stuck on version 1.16.1 of Dojo, so this feature won't be there yet.

You can always do this manually using setban in Core, though.

Not a surprising move, really. If Knots are going to refuse to relay Whirlpool transactions, then Samourai are simply not going to connect to any Knots nodes with their software to ensure their transactions continue to get good propagation. There will also be people who do not run Dojo but won't want to connect to Knots nodes for the same reason.

This is unlikely to make any meaningful difference to the wider network though, given that Dojo is about 3.1% of all nodes, and Knots is about 0.4% of all nodes.

---

Low value and off topic replies will be deleted.

A 12 word seed phrase gives you 128 bits of entropy. Bitcoin private keys give you 128 bits of security. If 12 words isn't safe, then the entirety of bitcoin isn't safe. So yes, 12 words are fine.

The 4 digit PIN on your bank card gives ~13 bits of entropy. The 15-60 digit bank card itself gives ~50 bits of entropy. The password on the vast majority of online accounts gives less than 80 bits of entropy. 128 bits are more than enough.

And quantum computing does not provide any meaningful speed up when it comes to raw brute forcing of seed phrases. Quantum computing poses a risk to the ECDLP (i.e. calculating a private key from a known public key), which is why at some point bitcoin will likely fork to a quantum resistant algorithm.

You shouldn't be remembering your seed phrase at all. Write it down.

Note that a multi-sig only provides additional security when it comes to your back ups - it does not generate addresses which are more secure than 128 bits. In fact, if you use old style P2SH multi-sig instead of P2WSH segwit multi-sig, then you actually create weaker (but still entirely safe) addresses.

I would slightly modify that to say a private key will offer a maximum of 128 bits of security. There are plenty of ways to generate private keys with much less security.

And how exactly does that spyware phone home from a permanently airgapped device?

I never said anything close to that, but if you think you have any privacy while syncing your device via servers owned and operated by the hardware device manufacturer then you are mistaken.

And there is an option of not opting in to Ledger's seed phrase extraction, which we rightly mock as being meaningless.

A yes/no button or "user opt out" means nothing. The ability exists for Trezor to surveil you just the same as Ledger do.

I quoted the Trezor policy where they state they collect details about your hardware, which parts of the app you interact with, use, click on, etc., just like the claims about Ledger.