Which is meaningless and provides zero protection.

Which means that all future owners of the coin still have to trust the manufacturer and the original owner.

But it has the same problem as above. It works for the first owner of the collectible, but all future owners have to have complete trust that the two split key parties won't collude to steal the coin.

That's a neat solution. Until of course someone finds a vulnerability and tricks it in to signing a transaction when it isn't supposed to.

True, but it also gives a false sense of security. The creator of some split key collectible could quite easily generate both parts himself, and then pose as a third party seller who says they generated half the split key. Any downstream seller then falsely believes it needs collusion between two parties to steal their coins, when in reality they are at just as much risk as they are now.

That wouldn't be such a bad thing.

Well, not entirely, since whichever servers you connect to via Tails will still be able to link all the addresses in that wallet together. You can break the link between different wallets (provided you change circuits) and the link between your wallets and your IP address, but not between different addresses in the same wallet.

Correct me if I'm wrong, but this link was made purely on the blockchain history of the payment addresses. Making such a link would still have been possible without the spreadsheet simply by pulling the payment addresses from the weekly payment transaction. The investigator might not have known the exact users linked to those addresses, but could easily just pass the blockchain evidence to DarkStar_ who could then respond accordingly.

I see no reason for there to be a public record linking usernames to addresses.

I have no idea about the specifics of Bcash, but addresses which start with "2" are generally P2SH addresses on testnet, not mainnet, so any coins locked behind them are testnet coins which are essentially worthless.

The hex you have pasted has parts of it which look like a valid transaction hex, but it is both incomplete and contains invalid characters (such as "@" and "l"), so it cannot be fully decoded. Even so, as I've said before transaction data does not allow you to calculate the private keys.

I am of the opinion that all exchanges are equally risky. We all have absolutely no idea what is going on behind the scenes at any exchange until it is too late and they are filing their bankruptcy documents showing just how negative their balance books are and just how much in debt they are. Go back a year and everyone though Celsius, Voyager, FTX were some of the most well regulated and least risky exchanges. And look at where we are now.

If the authorities do enforce some kind of sanctions on Binance, they will be put in place without warning and will be enforced before anyone has a chance to react. Waiting to hear news of such sanctions before you withdraw your coins leaves you at risk. Withdraw now.

Everything you have copied is simply data from block 100.

The "hash" field is the hash of block 100. The "merkleroot" field and "txid" fields are the TXID of the coinbase transaction from that block. (They are the same since that block only contains a single transaction). The middle section which follows are the details of that single coinbase transaction, which is all publicly viewable by looking up that transaction (https://mempool.space/tx/2d05f0c9c3e1c226e63b5fac240137687544cf631cd616fd34fd188fc9020866) and clicking the "Details" tab. The end section regarding "nonce", "bits", etc., is again data from block 100, which is again all publicly viewable by looking up the block (https://mempool.space/block/000000007bc154e0fa7ea32218a72fe2c1bb9f86cf8c9ebf9a715ed27fdb229a) and clicking on the "Details" tab.

Nothing you have copied provides any clue or insight whatsoever in to the private key needed to spend those coins.

You should just assume that the Terms of Use of any centralized exchange allows that exchange to share and sell all your data with anyone they like, hand over your coins to anyone they like, and provides you with absolutely no guarantee whatsoever that you will ever get back a single satoshi of your deposits. Because pretty much all of them do exactly that, but just obfuscated in enough legal speak that most people wouldn't realize it even if they bothered to read the terms.

I've been encouraging people to read Terms of Use of various exchanges for years. Here's a post I made two years ago, warning people about the Terms of Use of both BlockFi and Celsius: https://bitcointalk.org/index.php?topic=5315224.msg56289293#msg56289293. If people had actually read those terms, then maybe they would have been spared from losing everything when both exchanges went bankrupt from lending out users' deposits in exactly the way they said they would. Every time an exchange or platform goes bankrupt there are a flood of users complaining about how that platform was running a fractional reserve system, or was lending out their money, or was making risky trades/investments/gambles, etc., when all the time the Terms of Use said that the platform would do exactly those things. The users just didn't read it.

I've just replied to your post in the other thread regarding Javascript, so I won't repeat myself here other than to say I wouldn't recommend it.

Note that Electrum seed phrases are different from BIP39 seed phrases.

Bitcoin private keys provide "only" 128 bits of security. If a 12 word seed phrase was insecure (which provides 128 bits of security for BIP39 seed phrase and 132 bits for Electrum seed phrases), then by extension every private key in existence is similarly insecure. 128 bits is more than enough. Also note that Electrum can generate 24 word seed phrases if you want it to, as Maus0728 has outlined above.

If you specifically want a BIP39 seed phrase, then you can use Sparrow wallet on an offline Linux machine.

A hardware wallet seems like a waste of time to me in this scenario, provided you are sure you don't want to send from this wallet any time soon.

I would point you towards this post from Greg Maxwell: https://bitcointalk.org/index.php?topic=5324030.msg56590276#msg56590276

Personally, I would not use a browser to generate entropy, a seed phrase, private keys, or any other valuable information, even on a permanently airgapped computer. As mentioned, Javascript implementations of these things are too weak and the attack surface is too great. When there are plenty of much more secure methods out there, such as using Core or Electrum, then I see no good reason to use a less secure method.

Aladeen!

Ok sure, but how can you verify that the factory haven't influenced the private key in some way? How can you verify the private key is even there at all? As far as I am aware, not even something like OpenDime provides a zero knowledge way of confirming there is a private key on the device which corresponds to the address it is showing you. It's possible, but again it's all additional cost.

You could certainly set it up so the coins are spendable by the manufacturer generated private key after a specific time, or before that time by some other set of keys, but then when selling that collectible on then the new owner is still left with the issues of trusting the people holding this second set of keys.

I suggest that we table that motion. Equally mysteriously, you now have no idea if I am now supporting it or rejecting it.

DarkStar_ posts the exchange rate he uses each week. (Exchange rate * how much you got paid)/6 = number of posts you were paid for. Very simple.

The complicated part isn't generating a random private key, but rather being able to prove to all future parties that it was both generated randomly and without influence, and has not been accessed or otherwise tampered with since then. Even with OpenDimes, has anyone verified that it is impossible to bypass the seal and view the private key without breaking the seal?

Surely any time lock which prevents the manufacturer from stealing the coins also prevents the users from moving the coins to safety.

Genuine question: Why are people looking at the spreadsheet? What information are they taking from it? They have no need to know other users' addresses or post counts, and they can figure out how many of their own posts have been counted based on how much they are paid.

As I said, I haven't looked at the spreadsheet in years. I don't see why it needs to exist. I can maybe see an argument for a public spreadsheet in short lived campaigns, high turn over campaigns, or campaigns with a relatively new/inexperienced/untrusted manager, but not here.

My hatred of all things Google is well known, so I welcome a move away from Google Sheets, but at the end of the day the spreadsheet is still publicly viewable online to anyone and everyone.

I don't think I've ever looked at the spreadsheet beyond the day I was accepted, and I would have no issue with there being no spreadsheet at all so that individuals could keep their addresses private if they wish.

The actual process for signing is the same. The differences come in constructing the message hash and formatting the signature. A rough summary is given below.

When you are signing a message rather than a transaction, your client will first prefix the message with the following prior to double hashing it for signing (https://github.com/bitcoin/bitcoin/blob/master/src/util/message.cpp#L25):
"\x18" is the length of that prefix string, and "\n" signals a new line. The message itself is also prefixed with the length of that message.

How the signature is displayed is also different. The signature for a signed message is 65 bytes. This is made up of a header byte, which contains information regarding the y coordinate and the r value, followed by the 32 byte r value then the 32 byte s value. The signature of a transaction, however, will be somewhere around 72 bytes, and will start with a string such as 0x4730440220 (which includes instructions needed for the software to correctly interpret the signature), have an additional 0x0220 string (or similar) before the s value, and will end with a byte signalling the sighash, usually a 0x01 byte for SIGHASH_ALL.

I stopped caring about DT a long time ago.

The whole system is a mess. There are hundreds of users on DT2 who have left between 0 and 2 ratings. There are hundreds of users on DT2 whose only rating is a positive trust left to the DT1 user who is now making them a DT2. There are more than a few DT1 users who add people to DT2 for literally any tiny trade or interaction, and so it is trivially easy to buy your way on to DT2 by finding one of these users and doing some small trade with them. It is also trivially easy to expose a few ICO scams or alt accounts and end up on DT2 within a few days, as BitcoinGirl.Club has pointed out.

This could all be fixed immediately if we required at least 2 or 3 inclusions from different DT1 users to be included on DT2. This has been talked about many times over many years, but theymos won't implement it for some reason. And so the whole concept of default trust remain a dumpster fire.

I set my trust list based on the ratings that I want to see, and I pay no attention to any knock on effects on DT. I care not at all regarding retaliatory exclusions, as if someone excludes me it does not effect my trust list and how I view the forum in the slightest. If you are excluding someone because their ratings are bad, go ahead. If you are excluding someone to "get back at them" because they excluded you, you are part of the problem with DT.

I would add that I have no idea what drama is being referred to above.

I don't think you can view the two things in isolation though. I could spend hours with airgapped systems and flipping coins and create the most secure cold storage in existence, but if I then store my seed phrase in my emails then the entire process is pointless.

If OP realizes that publicly displaying a QR code of his seed phrase is a massive security risk and instead opts to keep it secure, then sure, his system is fine. But if he does that, then he doesn't need the brain wallet part at all, and just keeping the seed phrase secure is enough. And if he does still want a human generated password as well, then I agree using a standard approach of a passphrase is better than a self created method.

Yes, in that case a DIY solution is useless. DIY would only work if you are keeping it for yourself. Similarly any multi-sig or split key method between buyer and producer runs in to the same problems when it comes to resale, in that the new owner is just trusting two people instead of one.

You could essentially use something like OpenDime's system and embed that inside a coin, but yeah, then you are paying a premium for the collectible itself. I can't see any way to do it trustlessly for both the first buyer and all future buyers without electronics in the collectible, though.