multisig money

[zack]

truthcoin as I am currently making it will support multisig for every type of money.
votecoins can be held in a way so that any 2 of 3 people can use them to vote, or spend them.
Shares from markets can be owned by 20 people, such that any 13 of them can spend it or sell it.

Is this a bad thing that I should remove, or should I leave it this way?

[gwern]

It's a waste of time. What's the use-case for multi-sig on a prediction market, exactly? Truthcoin isn't intended to be a general-purpose currency, you're not going to be buying many products where you're worried you'll be ripped off. Why do you need split control of your personal shares in each market? I mean, there's some weak security arguments, but that's not enough to make it any sort of top priority. Multi-sig is the sort of luxury that should be added long after all the core functionality is up and running and debugged and refined for end-users.

[toast]

sorry to derail but
holy fucking shit are you THE gwern? Big fan here...

[psztorc]

It's him. https://bitcointalk.org/index.php?topic=475054.0

Either that or he's about to message me on bitcointalk, so that I can take this account back from some impostor.

Moreover, he is of course correct that this is not an efficient use of time. Best would be to copy Bitcoin wholesale, multisig and all, and not put any Time into removing mulitsig or removing/adding anything except that which is required for the PMs.

So it is perplexing. I hope to have attention from a even more coders after going to Bitcointalk (which is being recorded today). Then they can talk computer science to each other.

[gwern]

Code Select Expand

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

[quote author=toast link=topic=26.msg113#msg113 date=1401939828]
sorry to derail but
holy fucking shit are you THE gwern? Big fan here...
[/quote]

Yes, it's me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEAREKAAYFAlOQkO4ACgkQvpDo5Pfl1oIuqQCfWZ3qEmTRfZzHXo3y+lRLDk1u
/sMAn1/rPQfCTd2TLc0fS2axK1GvjTIu
=NfLt
-----END PGP SIGNATURE-----


[koeppelmann]

isn't multisig a risk since it allows trustless collusion for a (vote) attacker coalition?

[zack]

isn't multisig a risk since it allows trustless collusion for a (vote) attacker coalition?

This is a really good comment. Thank you so much for saving me from an awful attack.

[psztorc]

I don't see why the VoteCoins would need to support multisig.

But, to take your example, you are imaging that 70% of the Voters pool all of their votes into a big N of N transaction and then they all sign an attack-ballot (intending to attack once and then call it quits).

That seems difficult, they'd have to encrypt the ballot, which means that someone would have a decryption key, and could submit a new Ballot stealing everyone's votes. Or do they all share all the keys? What happens if one person withholds a key (?) (this huge vote will never be decrypted/readable, and those who did vote will have the winning votes).

[psztorc]

I suppose that for transacting VoteCoins it would make absolutely no difference. But the Votes themselves probably cannot support "multisig voting".

Hopefully some cryptopeople who actually know the latest-and-greatest will join the forum.

[zack]

You regularly talk about encryption keys and decryption keys.
This is not how bitcoin does it, it is not how I do it. That method is overly complex, and it is too hard to make it secure.
Bitcoin NEVER uses encryption/decryption at all.
Instead we sign data with the private key, and we verify the signature with the public key.

Hopefully some cryptopeople who actually know the latest-and-greatest will join the forum.

Is there something in particular you think I am ignorant about? Or is this just a general comment of dissatisfaction at my ability?

[psztorc]

On page 23 of the currently-published whitepaper (1.2), I have a section "Preventing Active Coordination", in which I describe why votes must be encrypted, and cannot only be signed. I also cite experts using Bitcoin ECDSA to encrypt and decrypt (search "Take "Kx" as symmetric key and it's ok." on my cited source).

zack, on this forum, you have proposed perhaps a dozen changes to Truthcoin which you feel are improvements. So far, they have all been largely nonsensical, or outright open the project up to attack. When you take up my "truthcoin time" (about one hour a day) with these questions I cannot use that time to work on other Truthcoin things.

That being said, my previous comment about latest-and-greatest was not directed at you or anyone here in particular. I was referring to those who aren't here, namely someone at the gmaxwell level who is a true expert in crypto specifically. Do you consider yourself to be at that level of expertise?

[zack]

Votes need to be "encrypted" in your implementation to stop voters from colluding, I know.
It is necessary that voters have an incentive to lie to each other about how they voted.
Usually for situations like this, encryption is not used. Instead of sharing the encrypted tx, you would share the hash of the tx.

https://github.com/zack-bitcoin/Truthcoin-POW/blob/master/txs_truthcoin.py
lines 258-270 explain how the 2 types of txs change the database.
lines 52-101 explain the conditions for those 2 types of tx to be valid.

SHA256 is very collision resistant, so it is virtually impossible to find 2 different tx which have the same hash.

Using the hash this way gives the desired behaviour, without exposing us to the risk of long-range attack.

I was first taught the limitation of long-range attacks by gmaxwell. He is a really smart guy. He was helping work out the details for the proof-of-stake system that I was designing with Vitalik Buterin. That is the same POS system that I want to rebuild truthcoin on top of.

I think that my skillset is more suited to the truthcoin project than gmaxwell's would be. Is there some particular ability of gmaxwell's that you desire?

zack, on this forum, you have proposed perhaps a dozen changes to Truthcoin which you feel are improvements. So far, they have all been largely nonsensical, or outright open the project up to attack. When you take up my "truthcoin time" (about one hour a day) with these questions I cannot use that time to work on other Truthcoin things.

Feel free to delete any distracting things I say on the forum.
Could you point out the nonsense that I have mentioned? Things I talk about are all inside of the code I wrote.
I am trusting you to correct me on the forum, so that I don't put nonsense into the codebase. Please give me specific examples of my bad ideas so that I may fix my code.

My feelings toward you are very reverential. I would have never found this project if it were not for the great explanations you gave.
These concepts are really complex, and you were first to figure them all out at once. I cannot thank you enough for this.

[zack]

isn't multisig a risk since it allows trustless collusion for a (vote) attacker coalition?

I fixed this bug in the recent update.
lines: 42-46 https://github.com/zack-bitcoin/Truthcoin-POW/blob/master/transactions.py
It is no longer possible to give votecoins to a multisig address.