Since the security is in the hardware device, I'm sure there will be a limit on the value of each transaction. Also, expect every coin to keep a full history of the bank account it was originally created from, the devices it traveled to in the meantime, and the bank account it was later deposited to.

This means that unlike Bitcoin, if you ever funded your MintChip from you bank account, all your operations on that device will become trackable by the central bank. It's not clear as of yet if one will be able to purchase MintChips anonymously, or there would be some kind of forced "activation" where the devices is tied to your bank account, thus obliterating any trace of privacy. I'll put my money on the later.

They are flexing their monopoly after intercharge (debit transaction) fee limits were proposed in US and elsewhere.
http://en.wikipedia.org/wiki/Interchange_fee

Too sad Bitcoin is not up to the task of killing these fucking parasites.

I'm not sure I've got this part right:

If I need to go to example.com before I can find Alice's key, doesn't that imply that a hacked or malicious example.com could redirect me to a different signature of "alice@example.com", thus circumventing the protection ?The point of Alice publishing a plain hash was that any user, knowing only her friendly address, can obtain her public key from the blockchain, thus killing any man in the middle lurking at example.com

BTW, There seem to be at least two similar but-incompatible schemes for doing what I proposed in the first post. Here I was thinking I am being original :

• https://en.bitcoin.it/wiki/BIP_0015
• http://ecdsa.org/bitcoin_URIs.html

Judging by discussion in the mailing list, BIP15 was deferred because it lacked a clear way to authenticate the relay (alias) server. HTTPS is not enough.
The electrum proposal tries to do some authentication, using an undefined "trusted authority". Not very useful.
If we can define a good way to publish Alice's  pubkey into the blockchain and use it further to authenticate and encrypt the exchange, we are making progress towards a working protocol. Coin destruction and spamming should be kept to a minimum or zero.

I do not believe so, since the scheme is used only for sharing a public key, not resolving it to a bitcoin address. The squatter still needs to control the example.com domain to have functional addresses. So the squatting issue is implicitly solved by relying on the DNS system.

Presumably, the user accounts of a certain desirable provider could be squatted, i.e someone would publish keys for a@gmail.com, b@gmail.com etc. That would not be a way to reserve them (you still need collaboration from @gmail.com), but it would be a way to deny them from regular users, thus creating a DoS against gmail.com relay server and spamming the chain.

Maybe this can be averted by designing a smarter way to select the correct public key when multiple initial transactions are detected to the same email hash. If the initial transaction must be of at least 0.05 BTC, then it becomes very expensive for the attacker to do this DoS; but who knows how much a coin will be worth tomorrow ? Maybe registering an address for 0.05BTC will be too expensive even for normal users

Hey, I've just got an idea: the sender and the recipient already have an unforgeable channel at their disposal: the blockchain. Why not use this channel to establish a trusted public key, thus widely reducing the middle man's (relay server) maneuvering capabilities ?

It could go something like this:
- Alice wants the friendly name alice@example.com, and the owners of example.com allow her to register it
- Alice hashes the friendly name with RIPEMD160, and constructs a globally unique, unspendable bitcoin address: base58(ripemd160("alice@example.com") +checksum),
- The address is unspendable since it's not a hash of public key; only Alice and friends know this, and it cannot be detected
- Alice creates a ECDSA keypair, and uses it to sign a transfer of a few bitcents to the unspendable address
- Alice has just published ownership of the "alice@example.com" friendly name, with none of the Bitcoin participants seeing anything other than a regular Bitcoin transaction
- Bob wants to send Alice some coins; he repeats the ripmend160 hashing and gets to the unspendable address
- Bob scans his blockchain for spends to this address; it's expected the blockchain is properly indexed for such scans to be cheap
- He finds the single unspent transaction made by Alice, thus obtains her public key
- He contacts the relay server @example.com, and uses the Alice's ECDSA public key to cut the middle man out of the loop:
   - The transaction metadata is passed to the relay server as a binary blob, encrypted for Alices's private key using ECIES
   - Each address previously uploaded by Alice to the relay server is signed, so Bob can have full confidence Alice gets the money

Using this scheme, Alice maintains good privacy (she publishes a hashed version of her address), and does not have to trust the relay server with her money or personal data. (In the naive scheme presented in the first post, a malicious or hacker @example.com server could have seized all of Alice's funds, and logged all payment details)

What happens if Mallory finds Alice's friendly address, and broadcasts her own transaction to base58(ripemd160("alice@example.com") +checksum), with her own public key ? Bob should accept only the first valid transaction, and ignore later ones. This has the disadvantage that if Alice looses her initial keypair, "alice@example.com" is unusable for eternity. A more complex scheme could be devised where updates, revokes and reuse can be enabled.

What about address colisions ? RIPEMD160 80 bits of collision resistance should offer sufficient protection against accidental collisions; for deliberate collisions, we are exactly in the previous situations and the protocol should prevent it.

And precisely because there is no hard limit on the total money supply, just a side effect of the subsidy function, changing this particular aspect of the algorithm is sacrilegious for the cult of Bitcoin. Sure, we could use this curve, we could use Pieter Wuille's curve, or any other heretic curve with fix supply equal to 21m.

But what guarantees do the faithful have that it will stop here ? If miners are free to disobey the laws of the great Satoshi as they see fit, what stops them from using the same consensus mechanism and set a fixed 50 BTC block reward ? It's certainly in their interest. Or maybe, gasp ! an increasing reward ! Blasphemy !  Cursed demon of Hiperinflation, you dare show your face HERE ? Begone with your heathen BIP !

Indeed, it seems to be something they are just rolling out:
http://www.suntimes.com/business/10940501-420/paypal-entering-brick-and-mortar-through-home-depot.html

They are using the credit card reader with a custom PayPal card, or the same keyboard with phone number + PayPal pin. They are also offering free 7 day credit.

Anyway, I think the principle of what I said still stands. Bitcoin's network effect is too faint to enable retailers to recoup the rollout costs. At this point, talking about fees is superfluous. Maybe when it get's PayPal sized, then it would start to make some sense.

As much as I dislike being cunicula's sockpuppet, bitcoin retail purchases are dead in the water.

Think about PayPal. They have hundreds of millions of individual accounts. They are accepted by hundreds of thousands of online retailers. Yet, do you know of any restaurant where you are able to pay with your PayPal balance using a custom PayPal checkout solution ? That's because even for PayPal the network effects are too faint to compete with the credit card oligopoly.

Instead, PayPal issues it's own credit card, so you are able to pay using your PayPal balance while using the de facto payment standard - credit cards. Bitcon's network effect is thousands of time fainter than PayPal's, it can barely compete with it online. Retail purchases in bitcoin are pure fantasy, IMHO.

And there's your answer: if it's slightly inflationary it will overtake Bitcoin, otherwise it will fail

@kjj: Bitcoin is strongly deflationary in real terms, unrelated to any one fiat currency.

Gresham's law refers to government enforced exchange rates and does not apply. This is about deflationary expectations on a free floating market.
The rational agent will not run out of cash if he has a webstore where people buy iPads with cash, and he gets a commission in cash. He will never get a a bitcoin revenue because people will not buy his inventory with bitcoins. Cash circulates, bitcoins do not.

@etotheipi

The subject has been beaten to death for a century by various economic schools, and the general consensus of most economists, supported by empirical data, is that deflationary expectations destroy trade, reduce economic activity and makes everybody a bit poorer, save for those who hold the most money.

A rational agent holding Bitcoins will understand their risky nature so it's likely he will diversify to control risk - not dump all his savings into Bitcoin. He might hold one third of his money in a mutual fund, one third in cash and one third in Bitcoins. Of these assets, Bitcoins is the most risky, but it also has the largest potential upside.

Ok, if this rational agent is faced with a buying decision regarding a new iPad, what currency is he likely to use, Bitcoin or cash ? Two basic scenarios:
 - as long as bitcoins are rising, it's irrational to spend them; it's like killing your best cow - it's much more profitable to ride the bull market
 - if bitcoins have stagnated since the user has added them to his portofolio, it's irrational to spend them since he took all the risk but has none of the expected upside

Faced with this decision the rational agent will chose to pay with cash. He will treat Bitcoin as a long term investment, and only spend them if:
 - he wants to balance his portfolio after a bitcoin rally and mark his profits
 - he wants to liquidate his bitcoin portfolio for whatever reason

Both these events are rare, so the velocity of bitcoins will be extremely low, and will mostly be related to cash <-> bitcoin exchanges. Thus Bitcoin's potential as a trade facilitator will not be fulfilled. On the other hand, an slightly inflationary cryptocurrency which has similar risks but no potential upside will be spend by it's owners like there's no tomorrow. Nobody will treat it as an investment since it's guaranteed to loose some value in a year or two - the hot potato game. The much higher velocity means higher GDP and strong merchant revenue in this alternate cryptocurrency.

As a matter of fact, deflationary expectations kill trade in electronics too. When a company announces a revolutionary product just around the corner, customers cease buying it's current inventory and hold out for the latest and greatest. Sometimes the revenue hit is so strong that the company folds before the revolutionary next version has a chance to become reality, as was the case for the Osbourne Computer Corporation. The phenomenon is called The Osborne effect, has been observed since in many cases, and is a textbook case study in technology marketing.

That being said, this sort of thing does not usually happen for electronics, although customers know and expect constant advances and lower prices. That's because the electronic device provides an utility to it's buyer since day one, which might very well be above the present value of money for that person. If I want to make pictures in my vacation, I will buy a digital camera today; although I might get it 20% cheaper a year later, I would have no pictures from my vacation and that loss is not compensated by the 20% cheaper camera. In the long run we're all dead.

Since a speculative asset like Bitcoin derives no utility for it's owner, this - often repeated - analogy is flawed.

Bitcoin isn't really working because deflation destroys trade. There, I've said it.

Bitcoin's spread is a self-defeating prophecy: bitcoins are valuable only in as much as they can be widely used as an exchange medium, yet all those who acquire or have them treat them as a long term investment, preventing their very spread which would enable bitcoins to fulfill their promise. Therefore the promise is a lie.

The early adopter crowd has already priced-in the chance that they will sometime be a widely used for exchange; so in order for Bitcoin to achieve it's potential as an exchange medium, an implausibly massive transfer of wealth must occur from the millions of people that would use it to the hundreds of people that currently hold the bulk of the monetary mass.

A similar thought pattern let me to make the Friendly address proposal. The address server is always online and records any transaction requests along with their metadata ("payment message"). This info has no place in the blockchain. An interesting twist would be to make the address server responsible for broadcasting the transaction.



Quite the contrary, it greatly reduces the information available in the block chain. If a business uses a single address for all customer payments, it's very easy for a competitor to see things like monthly revenue, expenditures and available cash. That's very sensitive data. If each customer payment has it's own address, and multiple customer payments are aggregated only when a purchase must be made, extracting similar data as in the previous case becomes impossible.

There is already some centralization, online wallets could offer this option to their users, ex. alice^mtgox.com. If I have a MtGox account I would probably welcome the option.
Also, more and more people will connect using lightweight clients, which requires a good deal of trust in the server they are using. So it's a good opportunity to piggyback the friendly address sync when connecting to the lightweight server, with minimal security implications for the users since they already trust that server.

What's to stop the largest pool to vote itself and share the extra 20% generations with it's miners ? If the pool owns 20% of the market, then by voting itself the payout would double, and the profit would skyrocket since the extra half revenue does not require any hardware. That's surely in the collective interest of the pool's stakeholders (miners); if they desire to give the money away to promote the currency they can freely decide to do so when they hold the money.

It's my opinion that exposing a SHA256 hash to the general public is bad usability. People would much rather publish a friendly address in a format that can easily be dictated over the phone, written down or memorized, similar to the way PayPal/Skrill/Neteller work, where an email address is the identity of the account holder. They would also like to include private payment details with each transaction, such as invoice numbers, and have the option of easily providing a refund when they desire.

Additionally, publishing a single base58 hash reduces privacy because it can help trace related payments to that address. A political candidate might not want to disclose the total amount of donations received. As a donor, I wouldn't want my friend and business partners to find out that some of the money they sent me ended up in a well known collection box. Since ECDSA keys are cheap, maximum privacy is achieved when each real world transaction has it's own unique address, and they are not aggregated in a master key, but rather spent individually by the recipient.

Combining the two requirements, I am proposing a distributed online protocol that resolves friendly names to base58 hashes, ensuring at the same time that each transaction has it's own unique address. The protocol works using a trusted 3rd party that acts as an always-on relay point on behalf of the user, similar to an email server. The payload (money / private keys) is not under the server's control, only the public address list and their mapping to a friendly address. Privacy focused individuals who don't want to disclose even the transaction list to a 3rd party can host their own relay server.

A conceptual workflow would go something like this:

• Alice creates a large number of private keys and stores them offline, keeping only the public corresponding public addresses; for space concerns the private keys could be generated based on a single seed that is easy to store
• Alice creates an account on the relay server, establishes an authentication token, and assigns herself a friendly address: alice@example.com
• Using her authentication token, Alice's client periodically contacts the relay server and queries for recent activity related to her account ("activity" will be defined bellow); if the base58 address pool is depleted, for example on first connect, the client uploads fresh keys generated in step 1
• Alice publishes her friendly address to friends, family, business partners, Bob and Mallory
• When Bob desires to make a payment to Alice, he enters Alice's friendly address in his client, the amount to send, some description and any other application-specific data
• Bob's client scans it's wallet and discovers it can match Bob's entered amount exactly by spending three private keys it owns
• Bob's client parses the address into a server and user part, contacts the relay server via DNS/HTTP and POSTs a request for a transaction. For example the post address and data could go something like this:

• The relay server extracts three of Alice's base58 hashes from the pool of available hashes, records them in the database of used hashes along with the information posted by Bob, and returns the addresses to Bob's client
  
• Bob's client makes transactions as usual to the addresses it obtained, and publishes them in the blockchain
• On the next refresh, Alice's client will contact the server and find what addresses where used, and the associated payer meta information; if the transactions exists in the blockchain, then Alice will be able to see a user friendly entry in her incoming log, that maps all 3 sends to a single entry and shows the associated payer addr and meta information, just like a regular e-wallet

For maximum compatibility and easy deployment, the server works on top of DNS and HTTP, but it could be also deployed over Namecoin/Tor. It's also coin agnostic and could be implemented for any other currency besides Bitcoin. If Bob does not want to disclose his IP address to Alice's relay server, he can resolve her friendly name via Tor. It's also optional for Bob to disclose or not his own friendly address under the "payer" POST field.

The system has the advantage that Mallory cannot find anything by queering the relay server. She will obtain a unique and random string that is never used in the blockchain and reveals no information about Alice. The only way to find out more is to send money to Alice and trance them further. But if Alice employs the same protocol when spending the money received from Mallory, then Mallory cannot find anything about Alice's other partners.

The protocol offers the convenience of systems such as PayPal without spamming the blockchain with metadata (payment details); metadata is kept private, known only by the Bob, Alice and the server, and it can also be encrypted to exclude the server. It allows easy refund if the payer chose to disclose a return address; without the payer's friendly address, refunds to a base58 addresses are a bad ideea since there is no guarantee the sender has kept the corresponding private key.

I'm not necessarily keen to have friendly addresses formatted like an email especially since this address would not have email capabilities; The friendly address syntax is yet to be defined and there are a myriad alternatives: alice$example.com, alice^example.com, btc:example.com~alice etc. I've also skimmed over the low level details for server communication since it's too early to lay down the implementation details. Also, DoS by emptying the pool of available hashes should be prevented.


Later edit, April 03, 2012:
The naive scheme presented above is very vulnerable to a man-in-the middle attack. Alice must trust the relay server, the DNS system, and the SSL provider of example.com; they could conspire to hand out fake keys that are not owned by Alice, seize all of Alice's funds, and log all payment details.

But the sender and the recipient already have an unforgeable channel at their disposal: the blockchain. Why not use this channel to establish a trusted public key, thus widely reducing the middle man's (relay server) maneuvering capabilities ?

It could go something like this:
- Alice wants the friendly name alice@example.com, and the owners of example.com allow her to register it
- Alice hashes the friendly name with RIPEMD160, and constructs a globally unique, unspendable bitcoin address: base58(ripemd160("alice@example.com") +checksum),
- The address is unspendable since it's not a hash of a public key; only Alice and friends know this, and it cannot be detected
- Alice creates a ECDSA keypair, and uses it to sign a transfer of a few bitcents to the unspendable address
- Alice has just published ownership of the "alice@example.com" friendly name, with none of the Bitcoin participants seeing anything other than a regular Bitcoin transaction
- Bob wants to send Alice some coins; he repeats the ripmend160 hashing and gets to the unspendable address
- Bob scans his blockchain for spends to this address; it's expected the blockchain is properly indexed for such scans to be cheap
- He finds the single unspent transaction made by Alice, thus obtains her public key
- He contacts the relay server @example.com, and uses the Alice's ECDSA public key to cut the middle man out of the loop:
   - The transaction metadata is passed to the relay server as a binary blob, encrypted for Alices's private key using ECIES
   - Each address previously uploaded by Alice to the relay server is signed, so Bob can have full confidence Alice gets the money

Using this scheme, Alice maintains good privacy (she publishes a hashed version of her address), and does not have to trust the relay server with her money or personal data.

What happens if Mallory finds Alice's friendly address, and broadcasts her own transaction to base58(ripemd160("alice@example.com") +checksum), with her own public key ? Bob should accept only the first valid transaction, and ignore later ones. This has the disadvantage that if Alice looses her initial keypair, "alice@example.com" is unusable for eternity. A more complex scheme could be devised where updates, revokes and reuse can be enabled.

What about address colisions ? RIPEMD160 80 bits of collision resistance should offer sufficient protection against accidental collisions; for deliberate collisions, we are exactly in the previous situations and the protocol should prevent it.

There seem to be at least two similar but-incompatible schemes for doing what I proposed above as the "naive approach". Here I was thinking I am being original :

• https://en.bitcoin.it/wiki/BIP_0015
• http://ecdsa.org/bitcoin_URIs.html

Judging by discussion in the mailing list, BIP15 was deferred because it lacked a clear way to authenticate the relay (alias) server. HTTPS is not enough.
The electrum proposal tries to do some authentication, using an undefined "trusted authority". Not very useful.
If we can define a good way to publish Alice's  pubkey into the blockchain and use it further to authenticate and encrypt the exchange, we are making progress towards a working protocol. Coin destruction and spamming should be kept to a minimum or zero.

Fat chance for the government to create such a system. The whole point of Bitcoin and friends is to circumvent government restrictions in a distributed fashion; if a friendly government exists, it is overkill to use such complex systems.

While some centralization is needed for ecologic minting, we don't need to go "full retard" and put the system into govt. hands. We simply need a trusted authority that can vouch a certain public key corresponds to a real life charity. The trusted authority will not have money creation privileges or any other control over the system. When the charity list is published and time has come to print some money, the charities receive the cash in a proportion democratically chosen by the holders of the currency; voting is done by proof of stake, a setting in your client that embeds your charity choice for all transactions you create.

The charity validation authority is needed since otherwise people will designate their own wallet as a charity and earn interest simply for holding money.

Your commitment for proof of stake evangelism might be interfering with your ability to understand my position. What I'm saying is that neither Bitcoin nor POScoin solve the distribution problem - the major source of inefficiency for e-coins. Unless you solve the distribution issue without wasting resources, it doesn't really matter how byzantine consensus is achieved.

I am a fan of POS also, and in fact I've toyed with the idea even before I've seen it in one of the original proof of stake threads. It's probably the most straightforward way to implement a Bitcoin like system without Nakamoto POW chains (albeit with bandwidth scaling problems in a pure POS system). However when I'm talking about Bitcoin inefficiency I'm referring to the wasteful nature of minting coin by burning electricity in a non-reversible process. An altcoin based on POS will be equally wasteful if it also does minting by way of burning electricity.


5% is implausibly high. Even allowing for competing payment processors attacking the network directly, they will likely won't be willing to spend more than the profit margin enabled by the new customers. How did you produce that number ?

Quite the contrary, distribution is key. Ignoring distribution, the proof-of-work chains are an elegant solution to a hard CompSci problem, and relatively efficient when funded be fees only. The required security of the network is proportional to the largest payment it can process, not total volume. The Bitcoin mining hardware existing as of today is sufficient to guard against multi-million dollar fraud. Thus a Visa sized Bitcoin network can protect multi-million dollar transactions with abysmal fees.

On the other hand, if you go for a POW distribution, you can either:
- create a limited initial monetary base like in Bitcoin and expect massive deflation, perverse incentives for the early adopters, and periodic bubbles; as a person of "Keynesian spirit" which has a Krugman avatar, you should probably see the problem here
- create a macroeconomically sound monetary expansion for the lifetime of the system, case in which the resources wasted for POW become a significant size of the economy, i.e a "vast resource consuming monster"