Fairness was not the goal, a mechanism for a peer to peer network to agree on an authoritative record of transactions was the goal...creating blocks and extending the block chain is how transactions are recorded and agreed upon by all users of bitcoin.  And if you don't provide any incentive to mine, no one will and the system will not be adequately protected from attack.

I like this concept, but you still have to have some notion of what an ideal difficulty would be (which should be something that is adequate for protecting the network against attack).  Without that, you wouldn't know at what scale to vary the fee against the difficulty.  That ideal difficulty would also change over time as computers become more powerful (so, block number might also need to be a part of the function).  It would be really nice if someone could figure out how to model the vulnerability of the network based on some kind of observable statistics or patterns.  If you could solve that, it could be an input into the fee structure.

I guess I'm not explaining it well.  Forget for a moment that you have to find any special hash at the block level (whatever hash the block has when constructed, the network will accept).  But, imagine the network does require the hash of each transaction to satisfy an imposed difficulty.  In that scenario, a miner has to find a hash the network will accept for every individual transaction.  It would then never be cost free to add additional transactions and the free rider problem would be eliminated.

*note: this is oversimplified to the point where it wouldn't work as described here, but in my earlier posts I describe the additional details that would make it work...also note, since you are adding a nonce to each transaction, the system would need to add this nonce to the structure of a transaction since clients would need the nonce to verify the hash of each transaction has an appropriate difficulty.

This would eliminate the free rider problem, but as I mentioned earlier, I'm still not sure the difficulty still wouldn't trend lower due to competition.  The more I think about this, the more I start to believe it will require changes to clients to require certain minimum fees that are substantial enough to create the incentive needed to sustain a certain difficulty (whatever difficulty is judged sufficient enough to protect the network as a whole).  If the min fee structure was based on some model and adjusted every 2016 blocks (with the change in difficulty), that would be the best scenario.

Now, if there is a sufficient volume of transactions, miners will start to place their own cap on the number of transactions they'll put into a block (regardless of artificial limits), and that might rectify the problem, but that is dependent on sufficiently high volumes of transactions (and ever increasing volumes due to Moore's law).

Each transaction has to have a hash computed...so each additional transaction would add to the total amount of hashing required (since there is a minimum difficulty associated with every transaction).  The minimum for the whole block just means that up to a certain number of transactions, there is no additional cost.

Nice video...glad to see the update.  It's an interesting dynamic in that when the price of bitcoins is rising at a fast enough clip, it's better to just buy bitcoin...and when the price levels out, the difficulty will likely catch up very fast and erode profits.  I viewed it the same way you did, a lower risk way of obtaining bitcoins.


Heh...well, I think there are already a half dozen or so fully operational competitors to mtgox.  I think the key at this point is to expand the usage of bitcoin enough to where buying locally for cash is viable.  At that point, every electronic means of getting money into any exchange could be shutdown, but you could take a wad of cash out of the atm and find someone locally to buy from.

Gavin said something really interesting in his twist interview: bitcoin is "pure money" ...I can't think of a better way of describing bitcoin.  But people like the one cited by the OP clearly demonstrate that most people do not understand what money is.

I just watched a portion of the interview again...genjix, you referred to mtgox.com as an "illegitimate exchange" ...I don't think mtgox.com is illegitimate at all.  I am a customer of mtgox and have not had any problems (and indeed I think MagicalTux is working extremely hard to make the exchange even better).  The only thing that might be illegitimate is a government that would try and shut down such an exchange.  Also, I do not believe mtgox.com is in any violation of US laws, so I'm not sure where you would conclude that it is illegitimate in any regard.  If you can point to some law that mtgox is in violation of, I'm willing to be corrected (btw, there are plenty of other exchanges trading in various other goods and digital currencies).  I'm sure it was probably an off the cuff statement that you didn't give much thought to, but words have meaning and in a setting like that, it could be very damaging.

I like love the usability aspect (only needing to enter a passphrase when sending bitcoins)...it makes perfect sense.  As for the concerns over the adding key attack...it might be of some concern to a merchant, but I think for a normal user, it's fine.  It's important to think about these users separately as their needs will no doubt be quite different...more advanced security features that might unnecessarily impair the usability for the average user could be an optional configuration that is off by default.

(note, I have not given much thought about possible holes in this scheme, but on a quick read it seems like a good use of asymmetric cryptography to create a simple, but more secure user experience)

I get the fact that the transaction limit will eventually create competition for space in a block and that might help.  But the 2000 limit seems to place an arbitrary limit on transaction scalability.  One issue here is that the cost of mining (securely recording transactions) is associated with the block rather than the individual transactions.  This creates a free rider problem (or at the very least, a very heavily subsidized rider problem).  What if the hashing was done for each transaction in a block and the network enforced a minimum total block difficulty and a minimum transaction difficulty.  The total block difficulty wold be calculated based on the combined difficulty of the transaction hashes.  The minimum block difficulty ensures blocks still only get created once every 10 minutes.  The minimum transaction difficultly would be some ratio to the block difficulty (if it were 1/2000, it would mean that there is no incremental transaction cost until you exceed 2000 transactions...at 1/100 it would 101st transaction that would start to add incremental cost. 

Miners would rank the transactions based on the fee and always include the highest paying among them.  For the 101st (assuming a 1/100 difficulty ratio), the miner would have to weigh the additional hashing cost (which effectively slows down the miner or pool's generation rate) against the fee associated with the additional transaction.  At some level of fee, it would consider the cost to exceed the fee and not include the transaction.  Lower fee transactions would tend to get processed by the network during off peak hours.

There could also be an allowance for really old transactions to be included without meeting the minimum hashing requirement...and maybe a few other special rules to prevent spammy looking transactions.

Note, I'm still not sure whether this creates a situation where difficulty wouldn't start falling to dangerous levels...this would just deal with the free rider problem.  In the absence of a concern over the integrity of the network and without generation fees, the optimal difficulty level with the lowest costs per transaction would be 1.  Mining would trend toward the most efficient miners or the subsidized miners and drive out the miners with higher costs.  And eventually the power would be devoted to good connectivity and the power needed to handle the transaction volume rather than hashing.  Until of course people realize just how vulnerable the network is due to an attack.

Somehow, I think there should be a model of how vulnerable the network is at any given moment and for the network to factor that into difficulty adjustments and perhaps minimum transaction fees (where nodes don't propagate unless those mins are satisfied).  But I'm not sure how you'd do that algorithmically without someone actively trying to attack the network (where the network could somehow detect attacks and adjust transaction fee requirements higher to create the incentive to bring more mining power to bear).

Maybe, the problem of optimizing mining activity for integrity can't be solved algorithmically...perhaps insurance is the key.  Insurers could sell bitcoin systemic failure insurance to people for some premium (settled in, I dunno, gold or some other currency).  A portion of this premium would finance mining operations by injecting very high fee transactions into the network (with the objective of making mining profitable enough to sustain a certain difficulty level they deem sufficient to mitigate the risk of a powerful miner attack).  Businesses operating secure wallet operations might offer such insurance with their service.  Dunno...just some random thoughts.

I have two points to add:

1.  You need to think about pricing and exchange separately.  Bitcoin or any commodity may indeed be too volatile to serve as a good pricing mechanism (or general unit of account).  Instead, I could see some kind of cost of living index being used for pricing, accounting and contracts.  The points that they made about elastic money are true, however I don't see what value it has over using some price index...and centralized control over money supply will always attract corruption and manipulation.  Bitcoin might not be good for pricing, but could be excellent for exchange.  I imagine the MIT billion prices project might play a big role in pricing in the future.

2.  Gold's major flaw is that it is physical and inconvenient to store and handle.  That led to the introduction of warehouse receipts and fractional reserves.  Paper became a substitute for physical gold and that enabled all sorts of fraud and manipulation that continues even today.  With bitcoin however, there is no reason to substitue contracts for the real thing (except perhaps for momentary conveniences like trading on mtgox).  I think for this reason, bitcoin will be far less vulnerable to such manipulation (especially with information that shows the diminishing returns if one were to accumulate too large of a position in bitcoins...for instance 100,000 btc isn't really worth $500,000 if one were to sell it all in a short period of time...so, someone trying to obtain a substantial percentage of bitcoins to corner the market isn't really accomplishing much...especially since, unlike most commodities, the demand side of bitcoin is elastic).

Good show...I would just suggest a bit less emphasis on potential legal issues bitcoin could face and focus more on the technology, how it works, what gives it value, etc.  Explain what bitcoin is and the good that will come from it rather than give the audience every possible reason under the sun to fear it or fear using it.

I'm actually using OSX at the moment.  I think this is something specific to bitcoin.  The following code appears later in util.js:

   var encodeBase58 = exports.encodeBase58 = ccmodule.base58_encode;

This is why I say that it looks like it might be the base58 code from the C++ client wrapped up to be used from bitcoinjs.  But, when I grab node-bitcoin-p2p, there is no subdirectory called build-cc (as referenced in the require() call in util.js).

EDIT:  Ok, I figured it out...the missing thing I needed to do (from the node-bitcoin-p2p directory):

   $ node-waf configure && node-waf build

The following website on writing native modules gave me the clues I needed to figure it out:
https://www.cloudkick.com/blog/2010/aug/23/writing-nodejs-native-extensions/

I don't think this step is in the README.

I'm not sure what conclusion you can really draw from luke-jr only accepting transactions with fees.  When there are no longer any generation rewards for a block, miners would all clearly benefit if they all only allow transactions with a certain minimum fee, however for any individual miner, they would have an incentive to accept any transaction so long as there is some fee...no matter how small that fee is.  This will drive transaction fees down to the point where miners start shutting down and the network becomes more vulnerable to a powerful miner.  Despite there being a strong collective reason for miners to charge some minimum fee and despite the clear benefit to all users to pay a fee to ensure a sufficiently robust network of miners, I think there is a real risk that miners will want to scoop up all transactions paying anything and for users to pay the bare minimum fee (a satoshi I guess).  This is the tragedy of commons argument people make.

Thanks, that worked great...but now I'm stuck on "var ccmodule = require('../build-cc/default/native');"  From the looks of it, it is some kind of repackaging of the bitcoin base58 code for nodejs.

Could you provide a list of the pre-req modules and where to obtain them?  I tried running p2p and it's looking for the "buffertools" module.  I looked at the node.js modules website and did a bit of googling...got quite a few hits but not sure which is the right one.

This is really fantastic and I'm glad you chose to use JavaScript on the server.  It's great when you have only one language to deal with on both the client and the server.  Nice work!

Also, I like the architecture of keeping all private keys on the client and performing all transaction signing there.  I think this is the right way to do hosted wallets.

Here are a couple pics of my rigs.  There are 3 4U machines in the rack (1 up high and 2 down below the printer).  I've taken the covers off the lower two to show a close up of those rigs.  The upper rig has a 6990 (about to have a second 6990) and the lower two machines are both dual 5970 rigs.

I am glad to see this thread.  In light of the market action in silver, this is very timely.  I don't agree with the blog post that bitcoin would completely collapse when an irrational exuberance imploded...bitcoins would find a level of support, but perhaps not before merchants decided to completely abandon it as a pricing mechanism.  But what this highlights is the inherent volatility of commodities...and bitcoin is very much like a commodity.  Commodities are volatile not because of their limited supply, but because of the irrational behavior of humans.  I could go on about why this is the case, but I think the best way to understand how commodities and irrational behavior can lead to extreme volatility is to study examples...considering the recent collapse in the silver market (and, yes, I know market manipulation is in play there), I think the history of the Hunt brothers and silver provides good insight into such irrational behavior.

I think this is why many studied (but honest) economists have reservations about using commodities as a basis for a currency.  If you have a benevolent central bank, if someone were to try and corner the market for a currency, the central bank can simply buy up assets (with newly printed currency) to maintain the price stability of the currency...when that someone later realizes the folly they're engaged in and begins to divest dollars, the central bank can sell assets and soak up the excess currency to again maintain price stability.  But of course, this requires a central authority.  The challenge is how to achieve similar stability without a central authority.

So, if you accept the fact that commodities and human nature tend to lead to wild volatility, and you understand that wild volatility is an impediment to the adoption of something as a pricing mechanism (note: I don't necessarily think bitcoin needs to provide a pricing mechanism to have value and relevance), then the question is: what can be done to mitigate such irrational behavior that leads to extremely volatility (with the goal being to create something that actually is useful for pricing)?

One idea I had was rather simple: come up with a mathematical model that shows people the value of their bitcoins in terms of bitcoins, but adjusting for the percentage of bitcoins they hold.  Someone holding 100 bitcoins probably does have ~$350 worth of savings.  But someone holding 100,000 bitcoins has nowhere near the purchasing power that the current exchange rate would imply (not in any sufficiently short timeline).  I'm sure a lot of people here understand that fact, but clearly (see Hunt brothers) this fact might be lost on some less educated people with more dollars than sense.  If you had a mathematical model that gave people a more accurate sense of real purchasing power, then they would very readily see the diminishing returns you get from hoarding ever larger sums of bitcoins.  This might mitigate the risk that some wealthy, but irrationally exuberant, individual would enter the market and try to dominate bitcoin holdings (causing a rapid rise in value followed by an inevitable collapse).

The second idea I had was that you simply give up any notion of using bitcoins for pricing.  Instead, use some inflation index to price things and just settle in bitcoins (or any other currency).  Something like http://www.pricestats.com/ might be useful for this purpose.  Loans and other contracts could also utilize some inflation index for its terms rather that any currency.  Under this scenario, the market will have harsh lesson to teach anyone trying to corner the market in bitcoins, but merchants will be unaffected by the volatility.

Reuben,

Did you consider the first amendement implications should the government try to restrict bitcoin?  When you spend bitcoins, you are quite literally doing nothing more than announcing your intention to do such to the world.  It is really quite a beutiful thing when you think about it.

- Stephen

You do not even need autologin as some have suggested.  I run ubuntu with headless, rack mounted servers (5970s and 6990s).  It's not the server edition, but as long as you have X installed, I imagine the server edition would work.  I have a script that simply uses sudo and xhost to open up permissions for all local users to access display :0...then the script sets DISPLAY=:0 and starts the miner...I use "screen" so that I can disconnect/reconnect to periodically check in on the miner to make sure it's still running at peak hash rates.  I do not need to set it to autologin.