Hey LOL, killerstorm has asked me to look into the issue with the balance being different in ChromaWallet and on blockchain. Can you provide me with the mainnet.wallet file? You can PM me a convenient way for me to get it.

I went through this whole thing. Paypal and eBay are supposedly two different entities. Paypal's CEO has been trying to reform their image as a seller-unfriendly service who closes accounts for no reason.

I'd say the best vector of getting things changed is flooding his twitter account asking why he's doing this. If there's a sustained outcry, I'm sure something will get done. My impression is that it's some mid-level guy that instituted the policy.

Here's his twitter account:

https://twitter.com/davidmarcus

#afraidofbitcoin?

Exactly. So is there an upper limit for the $/BTC exchange rate at which you would take the bet? Something like "$6000 equivalent in BTC up to $/BTC rate of $X"? Also, if you can codify what the changes in the terms would be if the $/BTC rate did go higher, that would give me a better sense of when I would want to trigger such a bet.

Interesting Bet. gmaxwell, are you willing to change the bet to be X BTC to be equivalent to the current price of the miner ($5999)? 8 BTC is currently around $6700, so the odds skew as BTC price goes up.

I'm not interested at 8 BTC, but if the $6000 equivalent goes to 5 BTC and the difficulty stays roughly the same, I might be willing to take that bet, for example.

Luke-Jr, I've put you on my ignore list. I literally don't see anything you write. Please just leave and stop crapping my thread.

If you want to discuss things mano-a-mano, PM me.

Luke-Jr, I can't see what you wrote, but please respect my wishes and stay away.

My impression is that Luke-Jr isn't really interested in a new tech, more convenient though it may be.

zinv is the modulo inverse of z.

That is, z * zinv = 1 (identity element)

I believe you do this to get the actual modulo inverse

zinv = z ^ (p-2) mod p

You can find information on this here: http://en.wikipedia.org/wiki/Modular_multiplicative_inverse

I am using ECIES, I think. I would need a more experienced cryptographer to examine the code to make sure, but it's fairly straightforward. The shared secret gets exchanged securely using the same discrete logarithm problem. The shared secret then is plugged into a key derivation function which is used to make a cipher and an hmac for evaluating the checksum. The cipher then is used for encrypting and decrypting the message. And the checksum is checked to make sure the message arrived un-modified. That's how ECIES works, I think. That's at least what I tried to implement.

So are you saying gmaxwell's main objection doesn't apply? That by having a shared secret with symmetric encryption inside, the attacks don't reveal anything about the private key?

It is very much along those lines, yes.


Can you elaborate on this? The shared secret is rP where r is a random nonce in the prime field F/p and P is the public key point. This is never transmitted, rG is. I'm not sure I understand how this compromises the secret key?


The private key is not used in the creation of the shared secret since the person encrypting has only the public key and computes the shared secret through a nonce.

No, the shared secret used for encryption is not the same as the private key used to sign the bitcoin address.

I may not have understood gmaxwell correctly, but I thought this was still a potential vulnerability as the private key is still used for decryption?

This might be true, but I still don't understand how useful such an attack would be. If the attack relies on sweeping the checksum, then having an impractically large checksum (2^128?) simply stops the attack.


This is the more valid objection. There's the possibility of a vulnerability yet undiscovered. Obviously, RSA has had this vulnerability so it makes sense that caution is being taken with ECC.

That said, a good, deliberately slow key derivation function should be able to make the attack very expensive. 50000 rounds of sha512, for example (to make it future-proof, we could make the rounds of sha512 necessary some fraction of the network difficulty and provide a timestamp of when it occurred). Would something like that make this more viable?

Also, you mention that it's good practice to avoid it where possible. does that mean there are cases where it isn't avoidable and this does take place?


Honestly, I'm finding your comments far more helpful than his. He could be a genius for all I know, but I'm not interested in pedantic arguments about what "account" means.


Sadly, I agree with you. Of course I have some share in that responsibility. Unfortunately, other than that first comment, I don't see anything of value in their other comments and I don't see much likelihood in there being any from them at this point. Life is too short to deal rudeness like that unless absolutely necessary.

Obviously, people are free to not evaluate the system. I think given the potential of the whole thing, I would be pretty disappointed if the only technical commentary I got was from you.

That said, thank you for your thoughts so far.

Andytoshi and luke-jr. Please leave this thread. I'm currently ignoring both of you and as far as I can tell you have nothing of substance to your remarks beyond Luke's first.

In the example you gave, wouldn't that be an attack vector that is available without any encryption? For example, using the challenge-verify mechanism that Luke-Jr showed above, you can use an unsigned transaction as the challenge and the user would sign it and send the signature to the malicious attacker. At what step does the attacker need the encrypt/decrypt part?

Awesome! Thanks for trying this!

Thanks for the support. Thanks to the pointless exchange with Luke-Jr, I discovered what the "ignore" button is for!

Have you had a chance to look at the message I sent you?

Interesting, I didn't know they don't have a blockchain. Isn't there some large block of data that stores the encrypted messages there in some way, though?

I guess what I'm asking is, my project seems about as secure as bitmessage, just from what we're both doing with the secp256k1 curve. So if coinmessage is not considered secure, can bitmessage? If not, what am I missing?

A user that just got out of newbie jail calling me anything is quite rich. One may suspect this could be Luke-Jr sock puppet.

Of course an address identifies an account. That's what the whole blockchain is, a list of accounts and who owns what.

If you're just going to troll, I'd rather you not do this on this thread.

Let's not get pedantic. An address is something that can be used to identify an account, which could be used as an identity. That's how social security numbers, driver's licenses and the like work.