Quote from: goldkingcoiner on Today at 12:25:04 PM

Quote from: nullius on Today at 09:40:10 AM

Quote from: goldkingcoiner on Today at 08:18:25 AM

Obviously they keep very secure wallets. They could even keep a decentralized version of the seed phrase with different, trusted individuals. So that every trustee has one word exactly and nobody knows who the trustees are except for a select few.

Dividing up a seed phrase that way is not secure. Each word of the seed that you leak exponentially decreases security. An attacker who recovers a large enough proportion of shares, but not the whole thing, will be able to bruteforce the rest of the seed. Furthermore, there is no way to provide redundancy, or to specify M/N access policies.

A popular approach to try to solve that is Shamir’s Secret Sharing. In M/N Secret Sharing, an attacker who obtains M-1 shares has no information about the seed. That has had some horribly buggy implementations, and it has been criticized generally by some experts (notably, Greg Maxwell). I do NOT recommend using it, unless you know exactly what you are doing; but I disagree with the general criticism. It needs better implementations, better standards (such as the Satoshi Labs protocol for this), and application to use cases where it makes sense—not ridiculous use cases, where it is too often misapplied. Reconstruction of the key is potentially a major problem for the use case stated in OP; therefore, it may not make sense at all here, depending on the circumstance. I note that there exists some enterprise software using SSS to secure the keys for corporate secrets; most Bitcoiners have no idea about that, and it is not a Bitcoin thing.

Multisignature, as I suggested in my prior post, accomplishes the same objective for the use case addressed in OP. With Taproot, a M/N multisig (and many other access control conditions) can be made indistinguishable on-chain from ordinary spends; this obviates any blockchain privacy and distinguishability concerns, one of my own general objections to multisig.

Yeah obviously you should use multisignature for the encryption of each word in order to keep the naked text away third party eyes.

Cringe. Conflating signatures (authentication) with encryption (confidentiality) is such a basic error that I am not sure if you may be trolling me Slashdot-style, making a ridiculous statement to attempt wasting my time with a long, detailed correction.

Unfortunately, clueless newbies who may somehow imagine that multisignature could “encrypt” (!) seed phrase words (!!) are the same clueless newbies who would attempt naïvely, linearly dividing up the words of a seed phrase—as you originally suggested, and you continue suggesting. Suffice it to say: You are unqualified to give security advice. Stop giving bad security advice.

Quote from: goldkingcoiner on Today at 12:25:04 PM

But would you then not have the same problem except that you went from storing the seed phrase words to storing the private keys to the seed phrase words? I guess you can divide up the keys and keep on adding multisig layers for extra security but it would never be 100% secure. Just more distributed. Also what I meant by "decentralized version" but was too lazy to explain.

Quoted for the lulz.

Quote from: goldkingcoiner on Today at 12:25:04 PM

However now wouldn't the problem be that the more layers you add, the greater the chance becomes that you could lose access to the wallet by losing access to a signature? So thats a problem I think most corporations/whales would rather avoid. The scary thought would be someone withholding a key to blackmail or sabotage a business from within, with their own funds.

No matter how I think about it, there's a huge flaw in security.

I added highlighting to the internal quote above, for a reason. The problem that you state is well-known and completely obvious. The solution is that “M/N” thing: Any M signatures out of a set of size N can authorize a spend. Say, a 3-of-5 signature, or a 7-of-11 signature. IIRC, some high-value escrow deals on this forum have used something like 2-of-3 or 3-of-4 multisignature with multiple high-trust escrow agents.

(2-of-3 multisignature also allows coöperative close of an escrow deal: If Alice and Bob both acknowledge that the deal is properly completed, they send the money as agreed. In case of a dispute, the escrow agent—effectually here, an arbiter—can sign together with Alice to send the money to Alice, or sign together with Bob to send the money to Bob.)

For dividing up secrets, a very different approach than multisignature, Secret Sharing also does M/N. But it has many sharp edges, footguns, and bad implementations. I disagree with gmaxwell’s categorical condemnation of Secret Sharing; but as things stand with implementations, I will not recommend it to anyone who is not a security expert with an appropriate use case. Just use multisignature instead.