In your initial post RHorning you raised a number of interesting issues and I did not give them an adequate response in my immediate reply.
You think that people should be rewarded for participating in the network by providing network bandwidth for example. This is a perfectly reasonable position and I agree with you. Unfortunately there's no way that I can think of to implement this in the current Bitcoin system without being scammed or having some other negative consequences. If you were to think of a way to implement it and specify it in some detail then I'm sure the proposal would be examined in considerable detail.
It's hard to imagine how network participation would be rewarded because Bitcoin is not good at micropayments. Every payment is sent to each client and gets recorded in the block chain on each client's hard disk. The number of fee free payments per block is relatively low. Let's say you can get 50k of transaction data in a block before you have to pay. Let's say the minimum size of a transaction is 100 bytes (it's actually more) so that's 500 transactions in about 10 minutes or less than one transaction per second and everyone's hard disk fills up at 2.628G bytes per year. Even if one lets the micropayments accumulate on account and you settle it relatively infrequently, it's still going to be a significant proportion of transactions.
The second problem is that any reward that creates coins from thin air has to be mutually agreeable and verifiable. It would be hard to verify that all this network participation was not just falsified to get the money.
The third issue is satoshi's de-facto control over all aspects of Bitcoin. I don't have an opinion about whether this is good or bad, it just is and has to be taken into account. In another thread, gavinandresen opined that it's way too early to start asking for commitments to adhere to a particular interface or functionality. Upon reflection I believe he is right. If you look at the amount of generally useful code written to further the project, essentially all of it has been written and tested by satoshi. Note that I'm not counting GPU miners as useful! Thanks to him, we all have a nice reference implementation of Bitcoin that we can examine and play with and a wonderful forum to share our thoughts. If he discontinued development for whatever reason the project would rapidly grind to a halt. People disagree on what exactly Bitcoin is and how much would have to change before it wasn't Bitcoin anymore. The real answer is that Bitcoin is whatever satoshi implements for the forseeable future. At the moment and for the forseeable future there are a lot of features of the current system that need to be discovered and addressed before an improved system can be designed intelligently. If the current scheme were substantially changed then a lot of the momentum would be lost and it would take quite a while for the new system to reach even the current low level of maturity.
Getting onto another topic that I initially tried to raise, I've been trying to think about even perhaps how you could "earn" bitcoins for network bandwidth, as a way to encourage participation in the network. A few basic ground rules I'd like to put into this discussion however.
- This is something that would have to be put on top of the existing rules. In other words, if this were to be done it would have to be completely compatible with the existing network rules, and more importantly it would have to be something that could work with earlier versions of the network client so it would have to be forward compatible with the current version of the client.
- Axiomatically, based upon the the premise of the previous requirement, the actual "mining" of Bitcoins themselves would have to be from the generation of the hashes themselves and the creation of new blocks. This isn't something that would be a way to create new bitcoins, but merely a way to pay for the service itself
- Charging for bandwidth would have to be something that is voluntary, in part because not everybody would agree to this at least in the beginning. It limits the options perhaps on what you can do, but it also forces you to think of different opportunities as a result.
- The advantages for moving in direction would have to be beneficial to the network as a whole and likely be adopted by Satochi even in the reference application, aka the main Bitcoin client.
My idea that I've considered is essentially where some system could be set up where data sent from one peer to another has some kind of payment arrangement based upon bandwidth delivered. A trust metric of some sort would have to be worked out here and perhaps even a "leap of faith" of some sort too, but I'm suggesting something sort of like the following:
Alice connects to Bob, where Bob claims to have blocks in the network chain that Alice doesn't have
Alice has some experience with Bob, or Bob has established some sort of trust with Charlie, who Alice trusts. Note, this is something that still could be worked out, but at some level there is some modest level of trust. Not hard trust, but that things may work out. Blacklisting and Whitelisting is possible here. Bob can similarly establish trust with Alice on the same premise or rules.
Bob lists the price for the blocks (yes, a microtransaction) with payment address, Alice agrees to pay that price or reject the fee. If the fee is rejected, nothing happens. Alice sends the coins, possibly to a trusted escrow.
Bob transmits new blocks in the chain.
Alice receives blocks, scans blocks as valid, and releases escrow (if in place).
If everything works out, trust metric is strengthened, or if things don't work out, trust metric is weakened and "reported" to the network as a troll or bad relationship.
In this case Bob could be altruistic and transmit the blocks for no fee at all (aka the current system), be greedy charging a high fee for the blocks (likely to be rejected) or charge a competitive fee (and get lots and lots of Bitcoins from "customers"... well, perhaps some at least). The advantage somebody gets from "buying" blocks in this system is that they can perhaps get blocks from high speed connections or at least get them from users who are willing to open up their connections. In the long run, you would be more "connected" if you are paying for blocks as opposed to those who aren't. You might even "win" in terms of tie breakers between who creates (mines) the next block by paying for the connections to the core miners on the network. For those with high bandwidth, they have an incentive to offer more network connections and become a network "core" that is distributing blocks to other users. The more connections they have, it gives them many more opportunities to earn Bitcoins.
Now to problems I see in this scheme:
This really does make the network a whole lot more complex, and substantially increases the number of transactions in the network. If nearly every node in the network is going to be receiving at least a couple transactions, it pushes the bandwidth requirements up and out of sight. There are a few ways this might be taken care of including perhaps setting up "accounts" with other Bitcoin users where you agree to ship so much bandwidth off of a single payment transaction. In other words, you could send 0.01 BTC to a "friend" or at least a trusted member of the network, and the "charges" would be deducted between the two users until it is time to send another 0.01 BTC for another batch, which might be enough for a few hours, days, or even weeks of block transferes. Some kind of credit between clients would happen in this fashion and thus minimize the transactions for a specific block being transferred. The presumption here is if coins are transferred between users, that there would also be incentives in place to connect to each other and continue the relationship.
There is the potential of scaming going on here, where false blocks could be transmitted. This would be an attack by Bob on the network, claiming that he has lots of blocks, and thus extracting payment from lots of users, and then fails to deliver. This kind of attack would be identified quickly where the actual data would be shown to be bogus using the existing rules. "Proof of work" would be shown as not really being proof, or being duplicates of previous blocks. Verification could also happen (with bandwidth being paid for from other clients), but again Bob would be shown to be untrustworthy. "News" of this lack of trust with Bob could spread through the network quickly where Bob could even be effectively kicked from the network and possibly even have payment rejected as a transaction before it gets into the next block.
Alice could attack too, spreading false rumors of lack of trust in an attempt to damage Bob's reputation. On the other hand, depending on how the trust metric system is set up, Charlie and others could show they they trust Bob and possibly start to reject Alice as a false rumor. As a result, Alice would be kicked off the network instead.
If Alice and Bob are starting out with no trust relationship at all (one or both of them are new to the network) a "leap of faith" could happen where a few freebee blocks could be sent by Bob or some minor amount of Bitcoins could be sent by Alice to start the trust metric. Perhaps both, but it would be an establishment relationship. Some users may not want to get into a leap of faith, which is an individual choice.
Still, there are wheels in wheels here where undoubtedly there will be somebody who will figure out how to turn this into a scam. The whole thing works only if a super-majority is "honest". My experience is that that more than likely would be the case. A couple of bad users would be weeded out quickly, but it isn't a guarantee. I'm also not completely certain that this sort of system would work.
I also see that potentially with these webs of relationships that perhaps you might even get isolated Bitcoin networks due to trust relationships creating an "island" network. That may or may not be a problem depending on how it is set up, but it would be important to know if you are on the "main" network in some fashion. Certainly blocks created on the isolated island would not be recognized by the rest of the network.
Perhaps this is making something overly complicated, but it would be a way to "pay" for something that at the moment is a free good, namely network bandwidth. It would provide another way for even new users to Bitcoins to make a little bit of money on the side simply for running the software, as people who stay connected to the network would over time earn more Bitcoins than those who connect for a brief while and then disconnect frequently.
As a separate note, the issue of microtransactions is something I thought was an overall goal of Bitcoins. If microtransactions aren't working out very well, perhaps that too is something that needs revisiting.