Yeah, it has that feel on purpose, because it's fast.  No eye candy to gum up the bandwidth or tax the webserver.  But it has changed somewhat since 1998, as I was once a regular reader of the site, before Slashdot.

EDIT:  They even use frames now!  Oh, the humanity!

I'm interested, but is this a simple shell account, or a virtual server?  Is the tech stats provided the total of the server shared among shell accounts (how many accounts do you plan on?) or is this the tech stats of a virtual server's quotas?

I ask, because I would consider 5 BTC per month for a simple shell account excessive, since I can get that for free many places.  But I would consider a virtual server, or a shell account with admin authorities to install programs (i.e. a small game server, for example) inside of a sandbox (which is basicly what a virtual server actually is) to be a bargin.

I wouldn't put a game server in Finland, as the ping times would suck, but that is an example.

Only a little.  If the rule is generally known, and the reason for it, I think that those like the bitcoin faucet could adjust.  I'm talking about limiting based upon the coins movement, if that's possible, not a three block ban upon a particular address.  The new client has 100 addresses, correct?  If bitcoin faucet has more than BTC .05 in each address, and simply rotates the addresses as the requests come it, then it can service 100 requests in half an hour without delay, and more with delays.  I'm not saying that transactions can't be created, just that generators will not put them into blocks until the transaction that they depend upon is three blocks deep without a fee.  With a fee, they can do whatever they want; and the generators probably wouldn't honor a 3 block delay upon a fee paying transaction anyway.  This leaves the possibility of free transactions an open possibility, while inhibiting spamming.  If there is a technical reason that this rule cannot work, I wouldn't know about that.

EDIT:  Markets that are trying to service withdraw requests would know how many requests have been sent in the previous 30 minutes, and could choose to warn the requester that such requests may be delayed by this rule, or they can choose to pay a fee out of it.

Perhaps in addition to the age priority rule recently implimented, there should be a minimum age rule without a transaction fee.  Said another way, perhaps a generation rule that says that a free transaction must be 3 blocks deep before it can be transfered again for free.  This will still allow real users to immediately spend new funds if they have to, while still permitting real users to reshuffle funds to suit their needs without an overhead cost.  I think that this would significantly inhibit the type of spamming attack that is currently underway.

The 'max 8 decimal places' will have to stay for a long while, since that is a byproduct of how the bitcoin value is stored.  It's a very long (binary?) integer (64 bit, I think) and has no decimal point.  The clients simply display the values with a decimal point in the middle of the base 10 translation of the  integer, as there are 8 decimal places to each side of the display.  Changing that might prove to be a breaking change, and may not be an easy one.  I don't know how difficult it would be to switch to an 128 bit integer, but since I don't think that there is any OS that yet process 128 bit natively I imagine that might have to come first.

Well, part of it is simply an arbitrary design decision.  But much of it is based upon assumptions about how the network would act in a future with a huge user base.  Much like the 10 minute target block interval is much longer than is currently neccessary, but in the future the number of nodes and number of transactions in transit would burden a network that tried to move at a much shorter interval.  In the same way, the target adjustment was chosen, in part, to prevent the network from getting out of wack due to an overly-precise time definition across the network.  If the interval is too short, there is the possibility that parts of the network could end up with a slightly different calculation of the target; resulting in parts of the network that can't produce a block acceptable to the rest of the network for some period of time.  This wouldn't be catastrophic, and might actually happen to some degree anyway, but shortening the target to, say, once every 24 hours would magnify this effect.  Also, shortening the interval would also negate the max. difficulty change rule; which limits changes in difficulty to a factor of four.  This rule exists to prevent a network attack intended to drive up the difficulty level to great heights before removing the excessive generation power and forcing the network into an unacceptablely long block interval for an extended period of time.  It limits extreme changes in difficulty, which could otherwise be manipulated into forcing normal users into paying transaction fees higher than would be reasonable, or simply annoy the network users in an effort to undermine faith in the currency system.

I don't really know as much about programming or encryption as most of these guys, but I do know the Economics of a monetary system, and this one is very well thought out.

Yes, the transaction fees and block reward are the 'seen' incentives for generation, but you are overlooking the 'unseen' incentives.  If you were one of the very early generators of the system, and in another 2 years when the block reward steps down to 25 bitcoin each, how would you respond to the concern that difficulty (and therefore blockchain resistance to a brute force attack) would drop?  If you had 10K coins (not unrealistic for some) and the market value were, say $5 apiece, would you sell all that you had knowing that the market value may crash and you might not get half of the net worth out of them, or would you buy and/or run a generator of your own even at a loss?  If you have 50 bitcoins at $5 apiece, you probably wouldn't run a generator (unless you were one of these guys that has to heat their high latitude apartment with electric anyway, and therefore the cost of running a CPU/GPU at full tilt is negligible) but if you had a $50K net worth in Bitcoins you would have a strong personal incentive to protect that net worth.  In a future with a successful Bitcoin, most generation would likely be performed at a net loss by persons or institutions with the most interest in Bitcoins security.  After all, you might not think twice about $50 in your wallet on the nightstand with that one-night-stand, but what would you do if you had $10K in cash?  Would you deposit that into a savings account at a bank with a $50K safe?  If you do, you are contributing to the cost of that safe, even though your share may be so small as to ignore; but the bank still invests into it's own security at it's own loss.

Someone has been spamming the network with transactions to oneself.  Whoever it is needs to use the test network to play games, that is what it is for.

I'm also a ham, and a former military radio operator, and know that the reasons for the limitation on output power are not arbitrary.  In the case of WiFi in particular, the only reason that such devices are in that band is because it's unlicensed; it's unlicensed because it's the same band as microwave ovens, microwave ovens use it because it's the resonant frequency of water, which is why it can heat up food at all.  It is an extremely bad idea to uncap the output power of devices that use this band, as if any frequencies can harm human life, it's this one.  Also, Wifi is range limted because it's a particularly wide spectrum technology and because of it's frequency choice.  It was never designed to cover great distances, and the fact that it can be done at all is due to the talent of the geeks to do it and not the nature of the technology.

And even if Wifi was uncapped, it is unlikely that mobile users could turn up the watts anyway, as they are battery limited and just turning on the wifi radio eats the battery.


It's not trivial at all, but mostly because the functions of a wifi device are encoded into the hardware because that's much cheaper in volume than a software defined radio.  SDR devices that can act like a standard (or moded) wifi device within that band do exist, but they are too expensive to use as a base node for any kind of mesh network.


Anything is possible with enough money, but if that kind of money were available, tens of kilometers of multiwire, direct burial phone cable (buried or laid directly upon the wilderness dirt) to connect these villages, and a computer  in each village with a few standard modems and a wifi card would be much cheaper and easier to maintain in the long run.  Hell, even a null modem might work.  To this day, that is exactly what the USMC does to connect commanders of base camps using huge rolls of POTS cabling with quick connectors and extra tough armored jackets.  (they do have extra wires connected to special devices that can detect tampering, and even tell where in the cable a cut is.)  In fact, the best place to get the stuff to do what you are talking about is military surplus, since this kind of stuff tends to not sell very high as there is very little value in it outside of military or aid missions.


That might work, but you would need at least two, otherwise all you have done is move the monopoly power from some faraway company to the one guy in the village who owns the cellphone.

SMS transfer costs are oppressive, and I can certainly understand wanting to use Bitcoin for that reason alone, but Bitcoin also requires it's own infrastructure.  Eventually, however, some group similar to the OLPC movement could develop a cheap device capable of managing a lightweight Bitcoin client and a Jabber client using some future wireless standard, without the need for all the other stuff on a cell phone that adds costs.

Hmmm, I'm a bit of a hardware geek, I wonder how cheaply I could make such a device?

And if his avatar photo is accurate, Gavin is pretty enough for television, whereas most of us likely have a face for radio.

Do you think you can get this up and running before Black Friday?  I do most of my Christmas shopping online, and books are a big thing in my family.

I disagree, there are many things that a payment of less than a nickel should be possible, such as per-email or per SMS usage of bandwidth.  I don't know that we would ever have a per-email charge system anywhere, but the main reason that we never have had such a thing is that the economies of scale combined with the inefficencies of fiat-credit exchanges make usage tolls on bandwidth prohibitively expensive.  Just think about the differences between the all-data cell packages and the per SMS or per-KB cell packages of today and yesteryear.  One doesn't have to be a particularly heavy messaging user to quickly justify the fixed monthly cost of unlimited data & texting.

No, the bitcoin stamp concept was related to the Dash7 Jabber client.  In which case, either the owner of the cellphone that provided the Dash7-to-Wifi gateway would earn some percentage of the stamp's bitcoins, or Dash7 intermediaries who were part of the Dash7 mesh required to reach (open hotspot|recepient's cellphone directly) would share the stamp in some fashion.   I don't know if it's possible to script such a division without knowing the addresses of the ad-hoc mesh in advance, but it would function much like a wireless mesh version of Unix-to-Unix-copy-protocol, but rapidly.  Text messaging via the current cell phone pay services would be faster and more reliable, but this would work even in places that wireless infrastructure doesn't exist for the phone itself as well as an emergency communications method for an entire city when the lights go out.  However, Jabber has presence information as part of the message protocol, and a Dash7 version would likely  require announcing your GPS location to the world in the clear, in order to establish a vector that a message would have to travel to reach it's intended recepient.  Fortunately, there is nothing that says that a Dash7 network ID has to have any connection to the user's real ID, and would be pseudo-anonymous in the same fashion that Bitcoin is, except that sniffers would know where the user was in real time.  Message bodies would likely be encrypted end-to-end, and Dash7 supports device-to-device encryption, so maybe there is still a way to establish a message vector without announcing your precise position in the clear, but your general position would be impossible to conceal.


As for the Bitcoin transactions themselves, there would be no need to establish a mesh, as the transaction would be broadcast in the clear to every Dash7 device that could hear it.  It would be in the self interest of business establishments that accept bitcoins via smartphones to have a passive Dash7|Internet gateway device somewhere on the property to forward any bitcoin transactions that it sees to the Bitcoin network, since it is highly likely that the vast majority are transactions that directly benefit the establishment anyway, and any free riders within range wouldn't justify the cost of filtering.  Even if they didn't, any bitcoin client that heard the transaction would forward it to it's peers upon the next opprotunity provided it's queue of stored transactions wasn't already full.

Maybe so.  But if ZS was even close, we will know with fair certainty when the Mayan long calender runs out in Dec of 2012.

Don't you mean 12 planets, counting the Sun as one?  I believe that you are referring to Memoirs of an Extraterrestrial God and The 12th Planet by Zecharia Sitchin .  It was a fine story, but a terrible theory.  The entire thing is dependent upon massaging the myths of ancient history into a coherent whole.  I will admit that it's possible that it's accurate, but I would say that the Pentateuch is more likely to be historicly accurate than the wild speculations of a half-mad scholar of long dead languages.

The system is difficult to wrap one's head around anyway, but I think that you are right about the hidden nature of transaction fees.

Dash7 on smartphone and bitcoin could pay for "priority mail stamps" for Jabber text message forwarding.  Without mesh forwarding, Dash7 networking can hit 2 clicks on a milliwatt transceiver, and would make for one awesome "Citizen's Band" version of p2p instant mobile messaging.  Dash7 could also handle broadcasting the transactions of smartphone based lightweight clients without the need for direct Internet access.  Anyone within 2 clicks of the sender would immediatly see the new transaction, presumedly including the receiver if it is a IRL transaction.  Sooner or later, someone will encounter an open hotspot, and the transaction will make it into the blockchain.

Yeah, the propagation of transactions is pretty zippy right now, because there are not nearly the number of nodes to spread a transaction to as the system is intended to support.  As Bitcoin becomes more popular, the lag time for transactions will increase.

I use bitcoin on a thumbdrive, but have not yet found a way to import or export a transaction via a file.  I'm sure that it's possible to do so, and will be done for email if nothing else, but as far as I know there is no way to sneakernet just a transaction.  But it is possible to sneakernet the entire Bitcoin client on a thumbdrive, which is exactly what I do because of a restrictive firewall.

Once a proper lightweight Android client is completed, and with a cell phone that has NFC/Dash7 networking, regular access to the Internet will become as optional as regular access to a normal computer.  Of course, that assumes that you have a smartphone.