Looking for people to store some of the forum's money

[wtfvanity]

There are of course plenty of people that are both invested in the success of Bitcoin as well as those that simply believe in what Bitcoin stands for that will do this for free. Theymos has a list of willing candidates and their terms. Is anyone suggesting that with such a list, that Theymos is not a smart enough person to review the offers and pick someone that would hold them for free, have public accountability of the coins, and is well known both with their avatar and in real life over someone who wants to charge a fee and wants to play SD with the forums money? Come on. If you think he would choose the latter, maybe you should start your own Bitcoin forum because if you don't trust him with that you should absolutely have a suspicion that he is reading your private messages and reporting your IP address to three letter government agencies for being a threat.

I see lots of things for 'free' but bitcoin managing isn't one of them. There are risks even in FREE, and taking provisions for those risks are NOT FREE. So who shall pay?  I already donated so I've shown my support. Now, you want free?

I'm not really looking for this, he posted. I didn't request. I provided an option, he might not like it. So, don't take it.

TBH, it's a headache of responsibility that I normally wouldn't care to hold for a length of time. I assume, he has the same headache and is trying to spread the pain. I offered my aspirin but FREE would be a migraine.

I'm not saying that he wouldn't pick you or someone that is charging either. If he has 10 options and wants to choose 3, and 2 of them he highly likes and are free and 100% reserves, he may pick those depending on the level of trust. If he wants a third one and that person is charging a reasonable fee for taking the risks involved, because you are right, there are risks, if that charge still gives a 100% reserve and the member is well trusted, then a fee is reasonable and he'll choose it. I am absolutely not arguing that free is better than paid. There is much more to the argument than that. The people that are willing to do it at not cost are aware of what it will cost them and are offering their service as a donation to the community, again because they trust in it.

However, from a contract stand point, some payment, even if nominal, may be needed. Depending on how much money is being distributed a hundred bucks to consult with an attorney and email with their paralegal may be worth it.

[1715326987]

1715326987

[1715326987]

1715326987

[1715326987]

1715326987

[DeathAndTaxes]

Before this goes way off topic I, earlier I said either an offline key splitting system OR multi-sig would be fine.  I change my opinion to only multi-sig.  There are offline n of m methods to split any secret (including a private key) an example would be Shamir Secret Sharing.  However this wouldn't be ideal in a scenario like this as we would lose accountability.  If the funds were suddenly spent .... whodunit?  There is no way to know for sure.

With n of m multisig and "m" private keys if the funds are moved without authorization it is instantly possible to prove it was the "n" and clear the "m-n".  If I was a partial keyholder I know I won't misuse the funds but I would want the ability to prove my good name and multi-sig gives us that.

The other thing is that the contract should be PGP signed, it shoudl specific the exact terms under which keyholders can authenticate a request to release funds (should be verifiable and provide non-repudiation).  An example would be that release requests are PGP signed.  This ensures keyholders responding to an authenticated request are held blameless.  If theymos wants to get super secure the contract could specify two (or more trustees) which each need to pgp sign a request to transfer funds.

Custodians only respond to an authenticated (by PGP signature) request by y of x trustees.  n of the m custodians need to sign the multi-sig transaction.  This makes custodians merely "guards" and trustees responsible for proper usage.  When custodians gets proper message they act.  If they don't then they don't.  The process can be made more secure by requiring trustees to make a public request and custodians required to wait a certain amount of time (to allow challenge in the event of compromise).

If the entire process is made public it can become a resource to the community for "best practices" if something similar needs to be done in the future.

[sublime5447]

Let the people who donated the coins hold their excess donations, you have a list of the transactions just send them back the coins when you need them ask for them. Nice and f@#$ simple no need to scam on it, no need to pay fees, no need for complicated key systems, no risk of theft,no trust issues, no people begging to hold the coins.  My suggestion is the only one that makes sense.   I will not donate to the fund if these funds are given to insiders.     

[wtfvanity]

Let the people who donated the coins hold their excess donations, you have a list of the transactions just send them back the coins when you need them ask for them. Nice and f@#$ simple no need to scam on it, no need to pay fees, no need for complicated key systems, no risk of theft,no trust issues, no people begging to hold the coins.  My suggestion is the only one that makes sense.   I will not donate to the fund if these funds are given to insiders.     

I'm sure a lot of the funds are raised from ads. Those are not necessarily donations and wouldn't be returned to the advertiser.

[pyra-proxy]

Why not just directly invest a portion of the funds in legitimate 3rd party investments directly.  This has a double advantage in that the investments can be made public such that you are not trusting someone to hold the funds on reserve etc. just that the investments themselves are not a scam but allows all to see where the forum money is sitting when they donate and secondly the returns on investment can help secure a consistant future income to sustain forum operation over the long term future.

Obviously you would need to secure investment across a wide range of investments and varying levels of liquidity in order to mitigate risks.

[Matthew N. Wright]

After some thought I've come to the conclusion that the idea of a forum admin asking the forum users for help in storing the forum donated money to random users on the forum is a bit ridiculous. The forum funds may not have been donated/paid with the specific objective of creating new forum software (which shouldn't require more than a free open source forum software and a few thousand to a few trust developers, not $100k), but the forum's money should be handled by the forum. It's none of our business. Just as the forum should have a tech support / administrator, it should have a banker.

In short, instead of asking the public to hold your private funds, hire someone to join your team and take responsibility for it.

[TECSHARE]

I'm willing to hold it, with 100% reserve in cold storage, free of charge (I am hoping I would get improved reputation and more trust out of this). I've been around for quite a while, held that amount for Bitcoin100 with no problems, and like to think I'm fairly trusted. I would store it in my Armory cold storage wallet (offline signature transactions, so zero chance of hacks), and would prefer to make the address public so that others can see there's nothing funny happening with the money, as well as that any requests to send it back are verifiable. I would also prefer to have an address that a paper backup in a sealed envelope can be automatically sent to should anything happen to me.

P.S. I also have a few thousand BTC in my personal accounts, so I've "dealt with far more BTC at one time than what I'll be holding for the forum."

This should be a requirement for all partial key holders, otherwise the disappearance of one party could make a grouping of funds inaccessible. Is is possible to perhaps make some kind of "time lock" storage which will automatically release the funds back to a designated central account unless the trusted key holders reset the time period of the lock on a say monthly, or annual basis?

In this way the only circumstance in which the funds could be held up is by willful defiance of the partial key holder. Is there a way to divide the keys so that say 5 out of 6 partial key holders must cooperate rather than all 6 to reduce the chances of a rogue person holding up forum funds?

"Send Bitcoins Into The Future!"
https://bitcointalk.org/index.php?topic=128581.0

Rather than a 2 of 3 scheme, maybe a 5 of 10 scheme. Hand out 20 keys to well known members (with 10 real, 10 fakes). Don't announce who holds any keys. This prevents collusion, as if forum members start asking around if they hold a key, alarm bells may go off and report back to theymos.

If something were to happen to theymos, everyone can turn in their keys to whatever authority is present at the time.

Also this^  
Making diversion keys is probably a good idea. In this way any attempt to steal the funds might be discovered early and thwarted before actual funds are stolen. Additionally a 2 of 3 scheme can help prevent loss because of a user disappearance for whatever reason.

[tacotime]

I would:

Encrypt the BTC wallet/keypairs containing X BTC with scrypt using keccak and chacha20, N=8096, r=1, p=1 using a 1024-bit keyfile.

Divide the keyfiles such that they are distributed in 256-bit slices between 4 trusted members of the forum and each full key corresponds to a wallet containing 1000 BTC.

Post the encrypted wallet files publicly and redundantly, along with the addresses of the coins.

Have us be signatories to a contract that requires our personal identification through several means, including passport photocopy, professional reference, and driver's license photocopy.  Also require next of kin and any relevant contact information.

Now if you have 5000 BTC, you've scattered it among 20 people who all have portions of keys but have no idea which key fragment belongs with which other key fragments and in what order.  Ownership is decentralized but is regulated by you, who knows which individuals have which portions of the key pairs.  The odds of any four individuals colluding and having the correct key fragments to access their funds are very low.  Collusion of further numbers of persons increases the likelihood of solving any given key, with the collusion of all 20 resulting in all keys being solved and the money being able to be spent.

This is a special form of Shamir's Secret Sharing in which collusion of any 4 members is the minimum required to possibly spend coins in any single wallet, and in which the probability of being able to spend this money (and the amount of money) increases with every additional person who colludes.  This is a truly decentralized solution that democratically decides the quantity of money should be spendable and how it is spent.

[Luceo]

I would:

Encrypt the BTC wallet/keypairs containing X BTC with scrypt using keccak and chacha20, N=8096, r=1, p=1 using a 1024-bit keyfile.

Divide the keyfiles such that they are distributed in 256-bit slices between 4 trusted members of the forum and each full key corresponds to a wallet containing 1000 BTC.

Post the encrypted wallet files publicly and redundantly, along with the addresses of the coins.

Have us be signatories to a contract that requires our personal identification through several means, including passport photocopy, professional reference, and driver's license photocopy.  Also require next of kin and any relevant contact information.

Now if you have 5000 BTC, you've scattered it among 20 people who all have portions of keys but have no idea which key fragment belongs with which other key fragments and in what order.  Ownership is decentralized but is regulated by you, who knows which individuals have which portions of the key pairs.  The odds of any four individuals colluding and having the correct key fragments to access their funds are very low.  Collusion of further numbers of persons increases the likelihood of solving any given key, with the collusion of all 20 resulting in all keys being solved and the money being able to be spent.

This is a special form of Shamir's Secret Sharing in which collusion of any 4 members is the minimum required to possibly spend coins in any single wallet, and in which the probability of being able to spend this money (and the amount of money) increases with every additional person who colludes.  This is a truly decentralized solution that democratically decides the quantity of money should be spendable and how it is spent.

This is actually a pretty smart idea.

[tacotime]

This is actually a pretty smart idea.

Thanks.  It's a bit of a breakthrough now that I think about it, as I've been trying to figure out how to decentralize/anonymize a corporate structure for some time.  This would be a good method for determining the spending of allocated resources by a board or a collection of employees at some level in the hierarchy.  After decisions are voted on, the keys could be combined and the wallets solved would be used to fund whatever was being discussed by giving these funds to the employees who voted for them; following that, the original central issuer could reallocate the funds in the remaining wallets, create new random keys, and redistribute these new keys to board members.  This can all easily be software automated.  Control of the money can be completely transferred to the board by deletion of the keys at the central issuer position.

Incoming money could be directed to the addresses of the central issuer and added as time goes on to each address.

Now, imagine that we did this on levels so that each level each leaf is also a central issuer with democratic nodes below.  The overall structure is still centralized with a root, but the issuing authorities are easily hidden from lower levels and the movement of currency is anonymous.

A possible problem would be at the handshake level, where you exchange key fragments; everyone voting "yes" would need to share keys equally at the same time amongst other "yes" voting members and then equal distribution to all members or sending the funds to where you want them to go would have to be coordinated in some way that would be locked in after voting ended.  You would need some kind of escrow node to hold key fragments and distribution data.

[Meni Rosenfeld]

This is a truly decentralized solution that democratically decides the quantity of money should be spendable and how it is spent.

No, it's not.

If I understood you, this begins with the assumption that theymos generates all the keys. If in some way his procedure is compromised, all funds can be stolen regardless of how well everyone else did. If theymos chooses to embezzle (or to just force a dictatorship), he could keep a copy of the keys and steal the funds whenever he wants.

If we do assume the issuer is benevolent, we don't need the complex cryptography - everyone can just tell the issuer what they want and he will do the right thing.


Also: With the method as described, huge risk of loss. If each person has 1% chance of loss, the average loss with "normal" storage is 1%. With your method average loss is 4%.

[tacotime]

No, it's not.

If I understood you, this begins with the assumption that theymos generates all the keys. If in some way his procedure is compromised, all funds can be stolen regardless of how well everyone else did. If theymos chooses to embezzle (or to just force a dictatorship), he could keep a copy of the keys and steal the funds whenever he wants.

If we do assume the issuer is a benevolent, we don't need the complex cryptography - everyone can just tell the leader what they want and he will do the right thing.

If theymos deletes the keys himself, then it is decentralized and ability to spend will be based upon fractional collusion.

[tacotime]

Also: With the method as described, huge risk of loss. If each person has 1% chance of loss, the average loss with "normal" storage is 1%. With your method average loss is 4%.

Loss can be mitigated by reducing the fragmentation of a key; for instance, halving the number of coins in each wallet and fragmenting the key to 2 fragments.

The nice thing is that you need a minimum collusion number of 4 in order to even possibly be able to spend any of the coins as I had implemented.  I guess it's a tradeoff.

It's also guaranteed that with 100% of the currency will be spendable upon the agreement of all key fragment holders, too.

[BTCGOLD]

Why does the forum need a lot of money?

Just spend it for some new servers or somethin else.

[JoelKatz]

Why does the forum need a lot of money?

It doesn't at the moment.

Just spend it for some new servers or somethin else.

Then what do you do in the future when you actually need something?

[Meni Rosenfeld]

No, it's not.

If I understood you, this begins with the assumption that theymos generates all the keys. If in some way his procedure is compromised, all funds can be stolen regardless of how well everyone else did. If theymos chooses to embezzle (or to just force a dictatorship), he could keep a copy of the keys and steal the funds whenever he wants.

If we do assume the issuer is a benevolent, we don't need the complex cryptography - everyone can just tell the leader what they want and he will do the right thing.

If theymos deletes the keys himself, then it is decentralized and ability to spend will be based upon fractional collusion.

If we need to rely on theymos to delete the keys (and that the keys weren't somehow compromised during his generation process), then it's not decentralized.

Issuer risk can be greatly reduced if you use multisig (each party bringing their own key) instead of secret sharing. The issuer's role can then be reduced to compiling the list of keys without each member knowing which key is whose.

Also: With the method as described, huge risk of loss. If each person has 1% chance of loss, the average loss with "normal" storage is 1%. With your method average loss is 4%.

Loss can be mitigated by reducing the fragmentation of a key; for instance, halving the number of coins in each wallet and fragmenting the key to 2 fragments.

The nice thing is that you need a minimum collusion number of 4 in order to even possibly be able to spend any of the coins as I had implemented.  I guess it's a tradeoff.

It's also guaranteed that with 100% of the currency will be spendable upon the agreement of all key fragment holders, too.

You can greatly reduce loss risk, without reducing the collusion factor, by having 4 groups of 4-of-5 rather than 5 groups of 4-of-4, etc.

Also: Your method as described has a lot of variance. (7-way collusion gives access to X coins on average, but on practice it can deviate significantly from average). You can reduce variance by having more wallets, with overlap in custodians (e.g., each member is part of 10 different 4-of-5 groups, total of 40 wallets).

With combinations of wallets of different group sizes, you can control the correspondence between number of colluders and number of coins that can be spent.

Anyway this is getting completely orthogonal to the original purpose of securing funds.

[tacotime]

Anyway this is getting completely orthogonal to the original purpose of securing funds.

Yeah, sorry, was a neat idea and I ran off with it.  There's probably a lot of math that could go into it.  Multisig with this method would probably work better, yeah.

[BTCGOLD]

This Forum should create a user voting and donate 10,000$ to the winner of the voting.

Options should be something like

red cross
unicef
greenpeace
etc.



But  the winner will ONLY get the coins if he provides a bitcoin adress.

That would be a nice promotion for bitcoins.

What do you think folks?

[Rassah]

Not sure if there's a point to overcomplicating this thing with multi-sig, multiple people owning split keys, etc. You get a bit more security for a lot more headache, versus just having very few very trusted people hold the keys and send only the amounts you request.
Consider that if you have an n-of-m multisig address with $10,000 in it, you might only have the option to send the entire $10,000 at a time, and then store the unused portion in another m-of-n setup, going through all the requirements again.

[JoelKatz]

This is a real problem that deserves a real solution. How about specifying the parameters of a useful solution and offering a reasonable bounty for an open source solution to this problem. Then you could use that solution to store the funds securely, plus the project will have contributed a secure way to store funds to the community.