Topic: Would this be useful? (Read 1836 times)

Good point.

I think you'll have to watch out for people using ewallets such as mybitcoin. The address it came FROM isn't always from the same person. Since everyone is sharing one big wallet it could be anyone.

Both.

Yeah, the wallet sucks right now. Do you need public keys, private, or both? I think Keefe was going to add a JSON-RPC method to get the public key of an address.

I'm using the bitcoin keys to encrypt and decrypt successfully.
Now my hangup is getting the keys gracefully out of bitcoin. Its incredibly difficult at the moment since I'm not writing in c/c++.
I'm using sipa's walletdump branch to get the keys through the rpc interface but I really wish the keys were kept separate so services like this were easier to implement.

Cool, thanks for the clarification.

I'm sure I've heard this misunderstanding before from other people on this forum. It looks like the source might have been this post from Satoshi https://bitcointalksearch.org/topic/m.1169.

Although Satoshi is correct in saying that ECDSA can only be used to sign, you have to be aware that ECDSA is merely a particular method of using elliptic curve key pairs to sign messages. There are a host of other cryptographic schemes you can implement if users hold such pairs. These include other signing schemes, key agreement and encryption.

It is important to note that all the common cryptographic schemes are implementable with bitcoin's keypairs.

ByteCoin

My understanding is that Bitcoin uses ECDSA, which is only able to sign, not encrypt. Is it as easy as using those keys in an EC algorithm to encrypt messages?

The message will be encrypted to the public key of the receiver. I realize that you can only get the public key after money at that address has been spent but thats ok for what I'm after.
All I meant was if the hash of the public key is good enough for transaction addressing anonymity than it should be good enough for message addressing anonymity since it tells you nothing about the identity of the receiver.
I see what you're saying about adding a speculative decrypt for every message in the stream. I'll try to get something basic out first and see what the reaction is then see if that would be useful.

It's good enough if you don't mind the message being unencrypted.

Transactions aren't encrypted so the addressee can be known purely by the hash of the key. I thought you wanted the messages encrypted to the addressee, in which case you need their public key.

ByteCoin

I'm assuming if the hash of the public key is good enough for addressing the transaction then its good enough for addressing the message.

So everyone following the message stream can see to whom messages are being sent but they can't read the messages.
You should have the option to keep the addressee private. All client software attached to the messaging stream would have to speculatively decrypt "private addressee" messages and if the decryption did not yield a valid message then the result is discarded. If the message is valid then you know you were the intended recipient and you display the message.


More generally, if an address has ever spent any coins to anyone then the public key is recorded in the block chain for all to see.

ByteCoin

I didn't mean it would be used to help people commit crimes (regardless of whether the crime is truly a crime), but that bitcoin addresses linked to a criminal party might be messaged and that could constitute a court summons.

But now that I think about it, if they had a name then it would be enforceable, or moreso anyway. With just a bitcoin address they don't really have much

Like I said, I'm interested in this project. Can't say I have any coding experience in anything other than python, but I can read most code and try and squish bugs - pm me if you need any specific help

I'm using IRC at the moment but that was just a quick and dirty. Mainly thats just to start the propagation and also because I had never written an IRC bot and wanted to try it.

Can't say about the offending key thing. I hate to say this but I love this for the academic pursuit but have no interest in helping people break the law. I really hope that wouldn't be its use. I just think its cool.
As I have the encryption scheme working right now there is no indication who sent the message. In fact, even once you decrypt it there is no indication who sent it.
Two keys are used to send: the public key of the receiver and an the private part of a one time ephemeral key generated by the sender.
The public part of the one time ephemeral key is sent with the message and decrypted with the private key of the receiver.
Its diffie hellman magic!

edit:
I guess I should clarify after re-reading my first post because it was phrased weird.
The keys in your wallet aren't used to send, only to receive.

I believe your assumption is correct, but I'm not a dev so wait for confirmation.

As for your proposal, I'm reading it as a separate, optional, db to store messages that are broadcast in potentially many ways, but at first/primarily encrypted in an IRC channel.

This seems like it would solve the problem of the block chain becoming bloated, something many fear.

So in my 5 minutes of thinking about it, this seems like it would be useful, and I'd encourage its development, as a secure messaging protocol could be a very good thing.

Something to potentially worry about - would sending a message to an "offending" key be considered an effective summons to court?

I want to share with you guys what I'm working on to get comments and gauge its usefulness/technical feasibility since I don't know all the ins and outs of the protocol.

Its looks like you can send messages in the transactions but it seems like that would seriously clog the tubes if it took of... filling the network with microtransactions just to communicate.

I have a prototype of a system that uses the keys currently in your wallet to send messages perfectly anonymously to other bitcoin users without requiring prior key registration.

The main caveat is that it uses the public key of an address... so messages can only be sent to addresses that have their public key known.
This would work great for receipts, etc, and once you have communicated with someone you can continue to use the same address.

Here's how it works, with a few in the weeds details of how I have it implemented so far.
Sending:
Enter an address. If the public key is available your message is encrypted using ec ies to the public key.
The message is then posted to an IRC channel. (I'm going to leave out a bunch of details about how the load/spamming is handled)
From here the messages can propagate through all sorts channels.

Receiving:
A separate program running on parallel to the client loads your keys into a sqlite database. The private keys are encrypted with a master key stored in the database... which in turn is encrypted with the passphrase of your choosing. This allows for fast rekeying of the db.
The database is separate from the bitcoin server so it is portable. No need for the full thing if you just want messaging on the go.

Clients interested in messaging can attach to the message stream looking for messages addressed to them.
Ones with the correct address are plucked from the stream and stored to disk. To read the message the db passphrase is entered, the private key released, and the message is read.
This would be great for sending back a confirmation or results of a transaction.
Its also assumed only those interested in perfect privacy would query for messages through a service like blockexplorer instead of attaching to a message stream.

I have a plan for load, spam, and communicating with unseen addresses which I'll have to address when I'm not high on a coding binge.

One of the things I'm not totally sure of though that I hope someone can confirm for me since I'm so new to bitcoin:
If I receive a transaction, the public key attached is always that of the sender of the transaction?
I'm making that assumption so please correct me if I'm wrong (and before I spit shine this thing)