That's not how it works. If you are not using your own node, then it connects to a third party server and queries it for transaction history of your addresses and wallets. The third party returns the necessary data, but you therefore have zero privacy from that third party.

If you want to use it in a privacy preserving way with your own node or Electrum server, then you will absolutely need your node to download and sync the full blockchain first.

Take a look at this post of mine from November last year: https://bitcointalk.org/index.php?topic=5419710.msg61253386#msg61253386

In that post, I link to various statements from Celsius and Voyager saying the same thing - that all accusations were FUD - that they made in the days before their collapse. I made that post in response to SBF saying that all accusations against FTX were FUD, warning people not to listen to him and to withdraw all their coins. I was obviously proven right with FTX declaring bankruptcy just a few days later.

It is a recurring pattern with centralized exchanges. Things start to look uneasy, the CEO dismisses everything as FUD and promises fUnDs ArE sAfU, and then not long afterwards they freeze all withdrawals.

No exchange is immune to same thing happening to them and no exchange is too big to fail. Get all your coins in to your own wallets before it is too late.

It is hypocritical and dishonest at best, and dangerous at worst. If no one is allowed to build on your code or use your code for anything, then you are going to have far fewer people looking at it, examining it, testing it, using it. As you say, few people can actually interrogate the code themselves, and most users rely on independent developers or power users examining the code of open source projects on their behalf. If you aren't actually allowed to do anything with the code, then there is far less incentive to spend your time going through it.

Prove it.

I'm not trying to be facetious here - can anyone actually prove this? The answer is no. Remember their whole "proof of reserves" nonsense a few months ago which actually proved nothing at all? All but forgotten now. No mention of the liabilities their reserves were supposedly backing up, no mention of the fact that millions of dollars of crypto were transferred in to their accounts the day before their "not-an-audit", no mention of their uncollateralized "stable" coins. All you have is Binance's word that their scam coins are actually collateralized with bitcoin, and given that Binance have a long history of openly lying to users, investors, regulators, and the government, their word is worth less than nothing.

Because it is completely centralized. Binance own and control the chain. Transaction confirmation can be instant in the same way I can update the entry in a spreadsheet stored on my computer instantly. There is no risk to Binance of double spending because Binance are in complete control at all times and can simply seize coins from any address they want.

It is a centralized, printed-out-of-thin-air, scam.

If you use Taproot then you can make multi-sig transactions without any increase in fees.

For the vast majority of altcoins, you are exponentially more likely to lose your money due to them being useless, scams, rugpulls, Ponzis, completely centralized, and so on. If you are concerned enough with the safety of your money to be thinking about hardware wallets or cold storage, you should be concerned enough to swap all your shitcoins back to bitcoin.

The only caveat with combining multi-sig and an airgapped machine is that you can completely negate the safety that airgapping brings. If, for example, I set up a 2-of-3 between phone, daily computer, and airgapped computer, the airgapped computer adds absolutely nothing since the compromise of two hot wallets (phone and daily computer) is sufficient to steal my coins.

You need to ensure you cannot reach your threshold number of keys without at least one airgapped wallet. Your 2-of-2 example works. Another example with some redundancy would be a 2-of-3 between daily computer, airgapped computer, and the third seed phrase only on paper as an emergency back up.

Here are the basics:

pooya87 and I discussed this on a previous thread here: https://bitcointalk.org/index.php?topic=5438676.msg61745337#msg61745337

The summary is that Electrum makes everything lowercase, removes all accents/diacritics, and removes all duplicate white spaces.

Correct. The process for generating Electrum seed phrases is quite different to that for BIP39 seed phrases, and requires repeatedly incrementing the entropy to reach one which gives the necessary version number on hashing. It would require significant chunks of new code to be able to generate Electrum seed phrases. As you say though, the changes required to input Electrum seed phrases are very minimal.

If you want to make the changes yourself, follow these instructions: https://bitcointalk.org/index.php?topic=5450398.msg62166549#msg62166549

Yes, but it took them literally years after segwit was enabled to actually start supporting it.

Not according to https://www.binance.com/en/fee/cryptoFee. Ignoring their scam chains, the withdrawal fee for "Bitcoin" is 10,000 sats, while the withdrawal fee for "BTC(SegWit)" is 50,000 sats. As if paying 10,000 sats for a withdrawal which costs Binance 100 sats wasn't bad enough, for some reason they charge 5x more for a cheaper segwit withdrawal. Fees this high are to prevent people from withdrawing coins and therefore let Binance continue to run their fractional reserve scam. And of course as BHC points out, if you do actually withdraw your coins then >99% of the withdrawal fee goes straight in to Binance's pocket.

If you believe what Ledger say. I certainly don't.

Aside from the hacking, they have a very anti-privacy and pro-surveillance stance and actively fund blockchain analysis. So no, very much not credible.

If you really want to use a hardware wallet, the only one I would even consider right now is Passport. The best solution is to set up your own cold storage using Electrum, Linux, and a permanently airgapped device.

Well, that's not entirely true. While I haven't actively used a legacy address for years, I still have some coins on legacy addresses in the form of old paper wallets or old encrypted cold storage wallets. There is no point moving those coins to a new segwit address just for the sake of it, when they remain perfectly safe and secure where they are.

When I finally come round to spending from those wallets, then I'll obviously direct any change to a segwit address, but in the meantime the coins can stay where they are. I'm sure there are plenty of people in similar situations with coins on old legacy wallets.

The range is from 0 to 0xFFFFFFFF, with the cut off point being 500,000,000.

Anything under 500,000,000 is interpreted as a block height. At 10 minutes per block, block 500,000,000 will arrive somewhere around the year 11,514.
Anything greater or equal than 500,000,000 is interpreted as Unix time. 500,000,000 is 00:53:20 on November 5th, 1985. The maximum nLockTime of 4,294,967,295 (0xFFFFFFFF) is 06:28:15 on February 7th, 2106.

Here's the relevant part of the code: https://github.com/bitcoin/bitcoin/blob/bc4f6b13feb29146b7e10e86f93dc7f6fb6937f2/src/script/script.h#L41-L49

That's not the case with timelocked transactions. If I create and sign a transaction sending you some money which is timelocked for a year, I can invalidate it at any time by spending one of the inputs in a different transaction. Even if I share the timelocked transaction with you, there is nothing you can do to stop me invalidating it since if you try to broadcast it before the timelock it will simply be rejected. The network will know nothing about it and so will happily accept any competing transaction regardless of fee rate, RBF, etc.

What OS are you using?

Enter the following command in terminal:

What does it output?

I have no need to use coinb.in - I use an airgapped Electrum wallet for importing such raw private keys.

In addition to nc50lc's reply, note that the difficulty will change not just based on the length of the prefix, but also on which characters you put in that prefix.

When considering legacy address for example, because addresses are encoding base16 data in to base58, the length can be variable. Because the length can be variable, you will have one range for some prefixes, while you will have two ranges for other prefixes. What I mean by this is that for some prefixes you will have both 33 character and 34 character addresses which start with this prefix, whereas for other prefixes you will only have 33 character addresses which start with this prefix. (I am deliberately ignoring the edge case of shorter addresses than this which start with repeated 1s. These are even harder to generate.)

The pivotal address is this one: 1QLbz7JHiBTspS962RLKV8GndWFw. If the desired vanity address starts with a string which comes earlier in the base58 alphabet, it will have two ranges, and therefore be easier to find. If the string comes later in the base58 alphabet, there will be only one range and therefore it will be more difficult to find.

To answer your main question about the speed up between legacy v segwit, it is predominantly down to the size of the alphabet as nc50lc has pointed out. Legacy addresses have a 58 character alphabet; segwit addresses have a 32 character alphabet. Ignoring the other complex factors we have just discussed, 6³² is around 171 billion billion times smaller than 6⁵⁸.

Not if it was generated properly, as ETFbitcoin has pointed out above.

A private key is just a random number between 1 and (almost) 2²⁵⁶. I pick a random number in that range, and it gives me a random looking address. You have a 1 in 2²⁵⁶ chance (i.e. completely impossible) to guess my private key.

Now, let's say I want a vanity address. I take the same private key I just generated above, and I add one to it. I check the address it generates. It doesn't give me my desired vanity address. So I add one again, and check the new address. Still not a match. So I do it again. And again. And again. Adding one each time and checking the new address. Vanity generator software will do this millions of times a second. Eventually we find an address which matches.*

What does an attacker know when they see a vanity address? They know that I started a random private key, and I added an unknown number of 1s until I reached a new private key. So an unknown plus another unknown to reach a third unknown. This obviously tells them nothing useful about my private key, and so provides no additional attack surface over any other private key.

*This is a simplified explanation which does not touch on symmetry and endomorphism, but the premise is the same.

Even so, they still exist. I still have a bunch of paper wallets which use single private keys which are many years old. I'm not going to move the coins from their perfectly safe location if I don't need to, so I still need software which supports importing raw private keys. I also need more than a simple sweep function since I usually want to direct the coins form such paper wallets to more than one location, which may or may not be addresses I control.

The only way around it at the moment would be for every transaction in the chain of timelocked transactions to include an output to an address controlled by the recipient who could use that output to perform a CPFP to speed up the timelocked transactions. You can't use RBF or adding additional inputs via a specific SIGHASH since doing so changes your TXID and therefore invalidates the rest of the chain. But by doing this all you are really doing is moving the requirement to make a transaction from yourself to the recipient, who is unlikely to be best pleased about having to do this every week for every customer paying them regularly.

The biggest issue here (aside from not being able to access your money if you need it) is if a private key is leaked or compromised, you cannot move the funds to safety. You simply have to wait until the timelock expires and hope that your transaction beats the transaction belonging to the attacker. It also involves backing up and passing on both your private key and your redeem script, which is obviously more complex and more prone to error than a seed phrase.

Because now they can charge you $10 a month for the privilege of having your coins made vulnerable to seizure or theft from third parties!

You can specify the nLockTime in Unix time rather than block height, which is an easier calculation and avoids issues with compounding variability in the average block time over a period of weeks or months.

Forgive me if I've misunderstood, but if you need your wallet to recreate the transaction chain on a weekly basis to get the most appropriate fee, then why do you need timelocks at all? Why not just have your wallet create a single transaction each week with an appropriate fee?

It is still very much maintained. The developer explains the more recent lack of updates here:


If you find something that needs updated, want to suggest a new listing or delisting, etc., then instructions on how to do so are here: https://codeberg.org/pluja/kycnot.me