How is this different than handing the starbucks cashier a 100$ bill and oops, he only saw a 10$ bill?

Yes, this scenario involves a layer of trust -- I don't deny that -- but we aren't talking about 100,000$ purchases.  If starbucks defrauded one customer, no other customer would play.  They have a lot to lose by cheating the customer.


True, I had also considered a strategy for building your order before arriving, sending payment (sure, split key or multisig could work here too) and delivering the private key for instant payment.

Would this strategy work?  Naturally, it isn't without its own flaws either.

Say you're going to starbucks for a coffee.  On your way, you "prepare" your payment (as in the same escrow strategy that gmaxwell suggested), but in a different manner:

Starbucks publishes via a standard URL (say, https://starbucks.com/pubkey) the EC point -- the public key -- to a secp256k1 private key.  The key could change all the time, daily, whatever, that's up to starbucks. Then, you generate another private key, computes the EC point, adds the EC point to starbucks's, then hash that public key to obtain a bitcoin address. You prepare your payment by sending some coins to that address and broadcast the transaction.  Neither you nor starbucks can spend the coins right now.

You may realize that this is split-key address generation, like how vanitygen bounties work.

So you arrive at starbucks, and place your order.  To make a payment, you give starbucks the private key you generated, starbucks can instantly verify that the private key was the correct one and leads to the address you sent coins to earlier and that the coins are confirmed. It's impossible for you to spend those coins because you don't have the other half of the private key.  Along with your private key, you give starbucks a "change" address, they build a transaction sending the prepared coins (minus coffee price) to your change address and they broadcast that transaction, or just give it to you to broadcast.  They don't have to wait for confirmation, they *know* you can't spend the prepared coins.

Suppose you never made it to starbucks and want your money back - you hop onto https://starbucks.com/refund, give them your private key and change address, and they send you back your coins.

I think the cons in this situation are better than the escrow/timelocked version, since you can get your coins back immediately (as long as the vendor is cooperating). The vendor has to be trusted to send you proper change, but I think that's less of a big problem since the vendor has more to lose by cheating you.

You could consider this strategy like purchasing a gift card but getting your change in currency.  You also have the option to return the giftcard completely and don't have to lock away coins using nLockTime.

Thoughts?

I'm at a measly 350MH/s

I think that's kind of the point though.  For people like you, who don't mind that their email is stored uncrypted and possibly transmitted across the net unencrypted, nobody is forcing you to switch and moreso, you'd be able to communicate with BitMail users through a transparent translation layer.

Unfortunately using Gmail puts us at the whim of systems failures, hacks, and worse.  

Since messages aren't part of the block chain, only claimed addresses, I don't see any scalability issue with the block chain.  A message claim transaction would be at most a few hundred bytes, and with 1 address per person on the planet that would be less than a TB of data.

PGP is also not very user friendly and doesn't work as a "drop in" replacement for the layman.  Bitcoin is relatively easy to use for the uninformed.  PGP is not.

Hey, I just posted an RFC on a project idea here in the newbies forum but would love to post it in the project development forum

https://bitcointalk.org/index.php?topic=147566.0

BitMail

About Me

I'm a programmer with 12+ years experience in C, C++, and Python.  I've worked on Video Games for PS3, Xbox360, PSP, and Wii.  I love Bitcoin and have been using it for a couple years now.  I signed up *just* to make this post, and unfortunately, I have to post in the Newbies forum until I'm whitelisted. Once whitelisted I'll be happy to move this thread to the Project Development forum.

Motivation

Is it even necessary to describe the issues with standard E-mail? The current system is insecure and prone to eavesdropping and unauthorized access.  We need to fix this.  And spam?  Let's get rid of it.

I'm also incredibly busy with other projects, and this one has been weighing on my mind lately, as I think it's a very important piece of software that doesn't exist yet.  I just don't think I'll have the time to work on this, so I'm hoping someone out there will take it up.

Solution

BitMail is a distributed P2P E-mail system meant to eventually replace the current system.  It'll overlay and work with the current E-mail system so early adopters will not be isolated from standard E-mail.  It'll seamlessly merge with the current E-mail system by implementing standard POP or IMAP protocols, so today's mail clients continue to function unmodified, and SMTP protocols, to transfer mail between the new, encrypted system and the old system.

Details

Allow me to preface all of this by saying up front that I don't have all the details worked out yet, and I'm not even sure this will all work in the end, but if you're curious please read on.

The very fundamental principle of this system is that it must cost something in order to send a message.  On the individual level, it mustn't be noticeable the cost, however.  Enter proof-of-work.

It works like this: You download the BitMail client and install.  At install time, it asks you if you would like to claim a new E-mail address.  Upon answering yes, you enter any string you want your address to be.  Let's call this string your "BitMail Addresss" (BMA for short). We'll consider it a pseudo-private address, as you'll be giving it away to people whom you want to have contact with.  I'm assuming an anything-goes 256 byte unicode string should be fine. Let's not place restrictions on what a BMA address looks like. The BitMail client uses this address as well as some randomness to generate a private/public key pair that are permanently bound to this BMA.  Then it listens on the network for some of the latest mined blocks (TBD later) and uses information in those blocks to start number crunching on the address you provided.  After about 2 hours (yes, it ought to require a bit of work to claim an address), the BitMail client has "solved" an address-claiming transaction and broadcasts that transaction, which does NOT include your BMA but instead a hash of your address, the public key belonging to this address (if necessary, see below), and proof of work for the (hopefully small-in-size) address-claiming transaction.  This address block is collected by the network, verified, and inserted into the official blockchain of E-mail addresses (more later on the blockchain).  

At this point, you have provided the network a claim on your address and done the work to claim it. And furthermore, you no longer need to interact with the BitMail client, as it will act as a service running on your machine.  It is invisible.  So, now you can now draft a message.  You open up Outlook and change the SMTP settings to localhost, a specific port, and some special password that the BitMail client is configured to accept.  You start a new message.  In the To: Field you have two options: 1) To enter a specially formatted BMA address that is compatible with SMTP (perhaps a URL-encoded address followed by @bitmail.bma?) or 2) a standard E-mail address.  You finish your message, attaching files if you want, and hit send.  The mail content doesn't matter: the mail headers and mail encodings will be 100% compatible with BitMail, as BitMail is only a replacement for mail delivery, not the actual E-mail content. If you enter a standard E-mail address, the BitMail client acts like a normal mail delivery agent and forwards the mail to the appropriate servers according to E-mail DNS.  The interesting part is when you're writing to a BMA.  Upon receiving the data from Outlook, the BitMail client knows that this message was intended for a BitMail recipient because of the address format.  It builds a set of message headers that the BitMail network requires. These headers includes at least a hash of the intended BMA recipient(s), a message size, hash of the message, and more and starts number crunching.  It should take a very small, unnoticeable in small amounts, but noticeable in large, amount of time to "solve" this message header.  100ms doesn't seem too ridiculous to me.  This message-solving time should remain constant regardless how fast computers become, so some work to come up with how to compute a network difficulty level is necessary.  And since solving message headers isn't a network-wide effort, special care will need to be taken when choosing for the difficulty.  (TBD: you must prove that you know the recipient's BMA and not just the hash of the BMA. I think this can be done by using knowledge about the BMA to sign the message header.)

Once a message header is solved, the BitMail client starts to handle the transfer of the message.  This is done in two parts.  The first part is upload and delivery of the message content.  The content is signed with the author's BMA's private key and encrypted with the recipient's BMA public key, which must be present in the blockchain (otherwise, the BMA wouldn't be valid, would it?).  The BitMail client will support "message content delivery" plugins, allowing for delivery of message content in any way that developers please.  I'm thinking a standard delivery plugin might be to use the new MEGA storage site API.  Another plugin could be a bittorrent-like data transfer network, where peers work together to store encrypted data chunks. After the message content is passed through the delivery system, the location and method (I'm imagining a URL scheme that the plugins understand) to retrieve that data is included in the message headers.  Only the solved message headers, which should be small in size, are then broadcasted to the entire BitMail network, being passed on as long as the header is considered valid (signed, legitimate proof of work, valid BMA recipients, etc).

All BitMail clients are accepting and forwarding message headers all the time.  Each header is examined to determine if itself is the intended recipient of that message. If it is, the message is retrieved and decrypted using the private key belonging on the BMA used in the message header.  The next time you open Outlook, the message appears in your Inbox over the standard IMAP/POP protocols.  Your every day E-mailing then continues on as if nothing really changed.

But oh man, it sure did.

About the Block Chain

More thought needs to be put into how a BitMail block chain might work.  I've considered thinking of the Block Chain not as a linear chain but more of a tree, similar in idea to merkle trees, where each newly solved block has multiple previous block hashes in it.  This would allow multiple blocks to be mind at once.  (TBD How would address claiming conflicts be settled? Earliest network time claim is more legitimate?) A client, not interested in downloading the full block chain, could download only a couple of the most recent block headers from the network and use them as inputs when solving an address-claiming transaction.  Solving for addresses must happen on the spot, so inputs must not be older than a certain amount of time.

The current message-header solving difficulty would need to be maintained in the block chain.  When sending a message, the message headers reference the block that the difficulty came from, and if that block is too old, the network rejects the message. We can't have a message header solution reference 10 year old blocks, making the solution to message headers easier to compute.  BMA hashes along with their public keys, if necessary, are stored in the block chain.  BMA solving difficulty is maintained in the blockchain as well, and also if referencing a too-old block when solving a BMA claiming transaction, the claim is rejected.

And miners? Address-claiming transactions should be solidified into the block chain/tree.  A genesis block (or a couple genesis blocks in the case of a block tree) could be seeded with no claimed addresses.  How do we incentivize miners to solve blocks?  Is a block chain strictly necessary or can this entire system exist without one?

The benefits of this system

The benefits of the system should be obvious to anyone knowledgeable of Bitcoin.

• Nobody can write you a message without first knowing your BitMail address.  Your BMA is never broadcasted publicly, only the hash of it is.  Thus, you cannot snoop the network for addresses.
• No spam, or rather, spam costs precious CPU cycles
• Entirely a crypto system. No eavesdropping. The security of messages depends entirely on the crypto algorithms.
• Distributed and peer to peer. Nobody can take it down. Nobody can demand to see your E-mails
• It overlaps with the current E-mail system, so anyone can adopt its usage without being affected or left out.
• Sender validation.  Every message must be signed with the keys belonging to a BMA existing in the block chain.
• BMA ownership is anonymous.  Nobody really knows who is capable of receiving what message. Nobody knows anything about the sender of a message, either.
• The BitMail network scales better in terms of message content size, since 3rd party storage services (Mega) or "torrent"-like transfers can be used.

Downsides?

• It would be possible to guess short BMAs.
• The reliability of the system heavily depends on a strong message content delivery system.
• Anything else?
• Can a network like this handle the amount of messages today's mail system handles? Is some sort of routing algorithm of messages required in order to reduce network bandwidth load?

More ideas and ramblings

1. Perhaps a better system would be to "mine BMA claiming coins" instead and use the coins to "purchase" addresses.  This would have the benefit that someone who doesn't want to wait those 2 hours to claim an address could just purchase one immediately.

2. Receiving regular E-mail: you can configure the BitMail client to act as a "proxy" to your standard imap/pop3 account?

3. Perhaps BMA public keys don't need to be included in the blockchain, and instead you can verify that you know a BMA by being able to generate a public key from that knowledge.  Special math that I'm not quite knowledgeable of would have to be used to make sure a private key cannot be guessed or generated from the knowledge of the BMA.  Maybe the BMA itself, or some function of the BMA, _is_ the public key.

4. Services could come along so that people who don't use BitMail can deliver mail to BMAs.  This would be a standard SMTP server that accepts standard mails, then redirects that message to the BitMail network for delivery.  Webmail services could be use a BitMail backend for delivery.

5. Perhaps some form of confirmation of receipt could be worked into the network protocol.

6. Some kind of procedural address generation from a starting BMA? This would allow you to give out multiple forms of your address to different parties.  I guess you could just claim multiple addresses, too.

7. Losing the private key associated with a BMA should not have devastating effects (like forever losing access to that address).  So perhaps, some kind of "brain wallet" equivalent can be implemented.

8. For delivery, you could use bittorrent.  A plugin could automatically generate a .torrent file and a magnet link could be used as the retrieval scheme. This would essentially allow delivery of very large messages.  Perhaps it could interact with the uTorrent API.  The delivery mechanism isn't particularly interesting, as p2p delivery and encrypted storage is essentially a solved problem.

9. The BitMail client could dynamically install new message content delivery plugins, as they become available.

10. As an alternative, instead of having miners, you could consider 'Address-claiming' transactions as the block tree itself (call it the "address-ownership tree"), since these transactions use inputs from previous blocks to generate.  If that's the case, one could opt-in to contribute to the security of the network at install time by downloading the entire address generation chain and performing sanity checks on new addresses.  Reject invalid claims.

11.

Hello everyone! I'm Sarchar.

I signed up because I wanted to put out an idea I had, not specifically related to Bitcoin but definitely inspired by it.

I'll start a new thread here in Newbies since I'm restricted on the other boards, but once my account is whitelisted I'll move the RFC on the project idea to Project Development.