satoshi has already commented on that subject.

As it stands now, a spammer can flood the network with millions of 0.01 BTC transactions to himself.

Even when this uses up all free TX slots in a block -- thereby DoS'ing honest bitcoin users -- it will continue to use memory and network resources, because the TX's will hang around in RAM on each node, waiting to get added to a block.

Tax revenue -- that is, money coming into government treasury -- is largely predicated on economic growth, rather than tax rates.

Lowering tax rates does not necessarily reduce money coming into government.  Raising tax rates does not necessarily increase money coming into government.

Life isn't that simple.  Don't listen to Democrats and Republicans that want to paint you such a simplistic picture.

+1 agreed.  All TX's have a cost, a mandatory TX fee would reflect that.

This article is now outside the paywall; the subscriber link I made is no longer needed.

URL: https://lwn.net/Articles/414452/

The point of this thread is to flesh out / discover the specifics of this approach.

"transactions relevant to the phone's balance" is, in particular, not immediately obvious, at least not without knowing ahead of time the TX hash.

For the purposes of discussion, let us assume 1 million mobile phones exist, each with a bitcoin wallet, and the ability to make payment via bitcoin.  If we naively follow the current bitcoin client design, each one of those 1 million mobile phones would connect to the bitcoin P2P network, and relay the entire world's transactions to its ~8 network peers.

Quite unscalable; unrealistic to expect a mobile phone to do that, especially in many parts of the world where data traffic is expensive and/or incredibly slow.  So what are the alternatives?  Three come to mind:

1) Connect to a bank or service that provides a web API.  Easy, non-standard. Requires trusting a third party SPOF.
2) Set up your own bitcoin, and access that remotely via JSON-RPC from mobile phone.  Moderately difficult, and not scalable.
3) Connect to the P2P network, and using a subset of the existing P2P network protocol, send and receive transactions for the wallet stored on the mobile phone.

While options #1 and #2 are the most reasonable and realistic in the short term, it seems helpful if attention is directed to option #3, which is the most decentralized, pro-privacy option.

Therefore, I propose that we seek to identify a subset of the current bitcoin P2P protocol, that may be used optimally by low power, low bandwidth devices such as mobile phones.


Suggested bitcoin specification for mobile phones, version 0.1

The following is a list of basic operations one needs to support decentralized mobile phone wallet/spend, with suggested implementations.

• Spending bitcoins -- creating and sending a new transaction -- appears easy.  Connect to one or more P2P nodes, and send a 'tx' message.  For bonus points, sample several random network locations, to make sure your TX is getting passed around the network.
• Waiting for confirmation of a recent spend -- Poll one or more P2P nodes for newly created blocks using 'getblocks' and 'getdata'.
• Receiving bitcoins -- Poll network nodes every few minutes, download all new blocks seen using 'getblocks' and 'getdata'

Creating and distributing a TX seems straightforward, but receiving bitcoins is definitely an inefficient operation.  One wonders if there is any modification to the bitcoin protocol that could improve the situation?  Perhaps a new network message 'polltx', that scans recent transactions/blocks for activity on a list of public keys (wallet addresses).

The main goal of all this is (a) avoid relaying all the world's bitcoin transactions, while (b) remaining a fully decentralized bitcoin payment solution that requires nothing more than the P2P network itself.

NVIDIA GPUs aren't as good at integer operations.

Without a GPU, particularly an ATI GPU, generating coins is pointless.  You'll waste electricity for 1-2 months before generating a single block, most likely.

URL: http://www.wired.com/epicenter/2010/11/android-wallet

Some risks decrease... others increase

Indeed.

Furthermore, all known digital media -- magnetic tape, magneto-optical, CD, DVD, hard drive, flash drive -- deteriorates over time.  While many of us old codgers have 20-year-old hard drives that still work, your "average" media can start losing data in under 10 years.

Machine-readable, printed material is far more durable than that.

True, but if ultimately they want the donations in a national currency, fees are still involved.

Receiving Liberty Reserved USD (after selling BTC, presumably) incurs a fee.  There may be further fees converting LR-USD into something that may be deposited into a bank account.

Of course, in the ideal world, the charity would use their BTC to purchase goods and services directly.  One easy example right now of a useful, legitimate BTC-based business is web hosting, which many charitable organizations require.

I keep hoping that mtgox will add LR-EUR, and BCM will add LR-EUR and PP-EUR.

I don't see how the price relates to Paypal directly at all.

There were two large factors in bitcoin price increase:

1) Fraud at all markets and buybitcoin.com, led to increase in bitcoin buying activity.

2) The price went up due to inability to withdraw from mtgox, and BCM market price followed mtgox.  Because, logically, the only market activity one could realistically engage in was depositing money, for the purposes of buying bitcoins.  Which will obviously drive up the price.

When people were once again able to withdraw from mtgox, the BTC/USD price dropped like a rock.

Note that it uses NVIDIA GPUs.

Those are decidedly suboptimal, compared to ATI GPUs, for the purposes of bitcoin mining.

Can you elaborate?

Whoops, missed the post on another forum...

Quoting from the marketing email I received...



URL: http://aws.amazon.com/ec2/hpc-applications/

Perfect for a TXT record