Because YoBit is an outright scam. They don't need to worry about bank runs or anything like that, because they are quite happy to just shut down withdrawals and out right steal the coins of their users. Not to mention that the majority of shitcoins you can trade on YoBit don't actually have a blockchain at all and are created by YoBit only to separate idiots from their bitcoin. It doesn't matter if someone wants to withdraw 10 trillion MadeUpYoBitCoinNumber14, since YoBit can just create that out of thin air whenever they need.

The most surprising thing here is how they manage to continue to attract a steady stream of newbies and idiots to keep them running, even during a bear market. Although their outgoings will be very minimal since they don't need to pay any support staff or indeed process any withdrawals.

Ok. This is where things unfortunately are going to get rather complicated. Looking in to it a bit more, it appears that Coinbase don't just use the WIFs they give as normal WIFs like any other wallet does to generate a single private key. Instead, they use the WIFs to generate a seed to then generate a master private key. This is a very weird way of doing things and I'm not aware of any other wallet or service which does this.

You have two option. The first is more secure but much more complicated. It will involve your airgapped computer, installing Linux, installing various Python tools, using those tools to decrypt your BIP38 encrypted key, and then following the instructions here (with a little modification) to generate your two xprvs, before using those two xprvs and your other xpub to recreate your vault in a wallet such as Electrum.

The second option is far easier, but not as secure. There is a fork of Coinbase's vault tool here (https://github.com/dlajarretie/multisig-tool) which replaces the now defunct BitPay API with BlockCypher's API which is still working just fine. However, I've never used this myself so cannot vouch for it. I've skimmed the code and it looks fine, but you will still be importing all your private keys on to an online computer with internet access, which is always a risk.

One of our most loved trolls is back from his 2 year hiatus with this amazing piece of information.

Type 2 diabetes is caused by having a fat bandana.

Now that would be dangerous. You accidentally sign a transaction to the wrong address, or with a sub 1 sat/vbyte fee, or with a locktime of block 1,000,000, or something else, and then the device bricks itself. Wave goodbye to your coins. Or you could accidentally send more coins to the collectible in the future, mixing it up for a similar one which is not bricked.

There needs to be some obvious way of telling whether the device is sealed or unsealed, much like an OpenDime does, but the device still needs to function regardless.

That's correct. The hardware wallets are simply storing the seed phrases and private keys, and interacting with the wallet software you are using. Should a hardware wallet manufacturer accidentally break the way they interact with your software, then you can simply take the seed phrase back up and import it somewhere else which is still working as intended.

The biggest potential issue here (outside of importing seed phrases in to pieces of software and therefore risking exposing them) would be knowing which derivation path your hardware wallets have used for your multi-sig wallet.

It was in reference to a device like an OpenDime, which has to somehow be "unsealed" in order to sign a transaction. In the case of the OpenDime, you push an object through a small hole on the board, which unseats a chip on the other side and allows the private key to be accessed.

So prior to being unsealed, the device would be set up to allow people to sign arbitrary messages from it, proving that the necessary private key is indeed on the device, but it would have to be unsealed in order to sign a transaction. And once it has been unsealed, then at that point it cannot be sold to another person, since as you say a transaction could have been signed at any point, even if the coins are still present on the device.

I would consider it to offer more protection than most hardware wallets, if done properly.

Most hardware wallets are not truly airgapped and require to be connected to an internet enabled device to function. There have been a number of vulnerabilities discovered against various hardware wallets which could result in loss of coins. There is also the privacy aspect of them making it completely obvious that you are holding bitcoin, having to hand over personal details to the manufacturer, and often having to use the manufacturer's software. The significant benefit to hardware wallets are they are in general very easy to use, whereas correctly setting up and using an airgapped device without making a critical mistake is much more difficult.

I don't store these electronically. Such back ups I do on paper.

Well, there have been plenty of smaller exchanges which have gone bankrupt or exit scammed over the last few months and years as well, they just don't make the news nearly as much as when an exchange like FTX does it. But every exchange out there, regardless of size or regulations, is just one bank run away from declaring insolvency and taking all deposits with them. And as we've seen repeatedly over the last few months, when that happens regular uses are unlikely to get back a single satoshi of their money.

Difficult to say. A collectible producer obviously couldn't just take another company's tried and tested product and use it to start producing collectibles without risking running in to legal trouble. But if they instead had something specifically designed for them, then again it pushes the cost up and introduces a new device which has never been examined or tested by independent members of the community. I'm not sure the best solution to this which is both secure but also cheap.

Absolutely. I'm not really the target market for such things, and I only have one or two such things that I picked up in person at various meets and merchants, but I would only ever self fund such a device.

Great. I think this should be relative straightforward then, although since I've never used Coinbase vaults myself I can't confirm for certain.

Your key which starts with "L" and is 52 characters long is a compressed private key in the wallet import format (WIF).

Your encrypted shared seed which begins with 6P is an encrypted private key which uses the BIP38 standard. All BIP38 encrypted keys start with 6P. When you decrypt this with your password, it should (hopefully) provide you with a second key which mirrors your other one - starting with "L" and 52 characters long.

The combination of these two private keys alongside the third Coinbase public key should be enough to recover your wallet. We might hit a stumbling block regarding individual addresses or derivation paths, but we can cross that bridge when we get to it.

Next question: What format is the Coinbase public key in? Does it start with something like "xpub" or does it start with "02", "03", or "04"?

For the next steps, you are going to need to start importing these keys in to a wallet or other software. Doing this on a computer with internet access brings risk of your keys being compromised. Do you have a spare computer or laptop which you can disconnect and do the next steps offline?

I don't think so. A time locked P2SH address is just as much an address as any other address. The address in which those coins will end up - 3FahwpsL2B2yFauJXVt8vCyQnF5imdknf7 - cannot be spent from until block 800,000. It is a timelocked address.

If you took the raw public key and derived the P2PKH address associated with that raw public key, then no, you would not see my transaction to the P2SH address using that public key as above. But the same could be said if you took the raw public key from any nested segwit address, for example, and used it to generate a P2PKH address instead.

Yes, they are two different things.

The nLockTime field is a part of every transaction, regardless of what outputs are being spent or what addresses those outputs are on. It is the last 4 bytes of the of the transaction data. It specifies either a block height or a Unix time, before which the transaction will not be relayed and will not be mined. If you don't change it manually, then the majority of wallets set it to either 0, or to the most recent block (which helps to prevent fee sniping). However, if all inputs in a transaction have their nSequence set to max (0xffffffff), then nLockTime is ignored. Note that this is all transaction specific. So in this case, as you said above, if you have a currently unspendable timelocked transaction, but also have the private key(s), you can just make a new transaction which is not timelocked.

OP_CHECKLOCKTIMEVERIFY, however, is part of the locking script you are sending coins to. Just as we might send coins to a more familiar script such as OP_DUP OP_HASH160 pubkeyhash OP_EQUALVERIFY OP_CHECKSIG and any coins sent to such a script can only be unlocked by providing the correct public key and a valid signature, any coins sent to a locking script containing OP_CHECKLOCKTIMEVERIFY can only be spent once the specified height/time has been reached.

The funds are sent to a P2SH output, which in this case contains a P2PK locking script with the additional time lock as I explained above. The address for the above script is:

This is different to what is being offered by Coinb.in as quoted by Plaguedeath. It utilizes the OP_CHECKLOCKTIMEVERIFY OP code in the redeem script, rather than the nLockTime field in the transaction data itself.

Let's take the following public key as an example, which is generated from the private key 0000....0001:

Let's also say we don't want any coins on this address to be spendable until block 800,000.

So we head to https://coinb.in/#newTimeLocked and paste in our public key, select "blockheight", enter 800000, and hit "Submit". We then get shown a P2SH address which has the following redeem script:

Let's break that down:

03 - push 3 bytes to the stack
00350c - little endian encoding of the number 800,000
b1 - OP_CHECKLOCKTIMEVERIFY
75 - OP_DROP
21 - push 33 bytes to the stack

The next 33 bytes are the public key we pasted in as above, followed by 0xac, which is OP_CHECKSIG.

So this script essentially checks if we have reached the necessary block (or Unix time) specified. If we haven't, it terminates in an error. If we have reached the necessary height/time, 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.

For non bitcoin secrets such as PGP keys or other highly sensitive data, I generally store them on a permanently airgapped computer which uses full disk encryption and never leaves my house, or some encrypted removable storage which is only ever mounted on an airgapped computer.
For bitcoin private keys, seed phrases, passphrases, etc., I store some of them in the manner above, and some in a variety of other methods such as hardware wallets and paper wallets.
I use a password manager for online account log ins, but I don't use it to store anything related to my bitcoin wallets.

If the gift is one which will be kept private, then sure, go ahead. But if, as you say above, you want it to be a gift she displays and shows to people to "show off" that she has bitcoin, then I do not see the point in putting a QR code of the seed phrase on it. Any visitors who scan the QR code and don't know the passphrase will just see an empty wallet. Surely it makes more sense to put on a QR code of the address which holds the bitcoin? That way visitors can see the address and see that she owns bitcoin, while at the same time you aren't losing the majority of security by giving out the seed phrase to anyone and everyone.

I would also give her separate written copies of the seed phrase and the passphrase in order to protect against loss or forgetfulness.

It's not enough to figure out which address is mine, though. On the last payment there are 12 addresses which received the maximum payout.

If you don't want to reinvent the wheel, then I would stick to using a standardized method such as BIP39 passphrases. Using a custom algorithm or set up will make brute forcing harder, but it will also vastly increase the chance of you not being able to recover your coins in the future. Or if your mom or girlfriend are trying to recover the coins in your absence, then it will be almost impossible for them if you have done something completely non-standard.

To put the number ETFbitcoin has given in context, if someone could brute force 10 million possibilities per second, you are still looking at 21 years of non-stop computing to exhaust the search space of 8 random ASCII characters. Using btcrecover as a benchmark, then most home hardware would struggle to try over 10,000 possibilities per second given the 2048 rounds of hashing required. Someone would need to rent a lot of computing to crack this in a reasonable amount of time, which obviously no one is going to do for $100.

It wouldn't be public information without a spreadsheet.

Yes, a determined adversary could certainly mimic DarkStar_'s job for several months and start to figure out who is who, but there is a big difference between that and a spreadsheet linking names and addresses. Just like someone could follow you for two weeks to learn your daily routine and when the best time would be to break in to your house, but there is a big difference between that and sticking a note on your door saying "I'm going to be at work for the next 12 hours".

And of course once people start changing their addresses, then the whole process becomes more difficult and less accurate.

As I mentioned above, I can see the argument for a public spreadsheet in short lived campaigns, those which have a high turn over of users, or those with untrusted managers. But in a stable campaign such as ChipMixer, which adds or removes users only a couple of times a year and is managed by a highly trusted manager, then I see no benefit. Whereas the benefit to privacy of not having one is significant.

That address is invalid. It uses the string "0E9E3B4C" for a checksum, when the checksum should actually be "8EC77C31". When the checksum is replaced with this correct string, then the address encodes as follows: 13zouJCVmMQBmTcd8K4Y5BP36gEFS41q3n. That valid address is empty and unused, however.

Again, I'm not sure what you are trying to achieve here. Either crack your brain wallet or don't. Wasting time on non-sensitive and public information such as address or transaction data is going to get you nowhere.