Perhaps the 40 Mhz ISM band would be ideal, after all.  It would permit smaller antennas of reasonable gain than 27 Mhz.  And if the standard mode chosen is PSK500 or PSK1000, at least 10 devices could be transmitting at the same time, and a single computer with a sound card could decode & forward all those transactions at the same time.  Also, a standard 2Kb or smaller transaction would take less than 20 seconds to burst.  Granted, less than one second is ideal, but I'm not sure how that's going to work unless we were to use higher quality radio modems (read more expensive).

Much has been discussed, including by myself, on the value of bitcoin devices that don't require constant Internet access in order to transact.  Part of this would likely include some kind of ad-hoc p2p wireless networking ability between devices, as well as the ability to monitor a set band for bitcoin related data.  I had an idea.

Wifi uses the 2.5 & 5 gigahertz ISM bands, not because they are ideal, but because they are unlicensed AND they are wide enough bands to support the channel width required for high speed data transactions.  None of the ISM bands of a lower frequency (in this case, better transmission & propogation characteristics), however there is nothing that I know of that prevents a narrowband digital part 15 device (unlicensed intentional transmission) from working in the lower frequency ISM bands.  I've personally mentioned using Dash7 sensor tech (433 Mhz ISM band) for this purpose, and this might yet happen anyway, but Dash7 radios are still vapor-gear.  However, basic radio modems on chips are not.  Their bandwidth is narrow & data throughput is slow, but they can also operate on better bands & individual transactions are neither large nor subject to problems if distorted. (due to internal checksumming)  So error correction is unnecessary.  If we were to establish a 'standard' frequency and mode for the literal broadcasting of transactions from disconnected devices, then such devices could be sold that can monitor that frequency and either store transactions that it sees to be released to the Internet latter, or simply as base stations (inside brick & mortar vendors?) which forward the transactions immediately.  The transmitting device doesn't necessarily even need to know if other devices heard it; it could simply transmit in a standard pattern.  I.E., a buyer's device could transmit immediately, repeat again 5 minutes later, and again an hour later, then perhaps once each day until it sees it's own transaction in a block (or a supporting server tells it to stop).  This would both protect against a device not being heard due to no other devices being within range of the buyer's device, as well as protect against a broadcast 'collsion'.  The seller's device could ack the transaction, permitting the buyer's device to quit, but this shouldn't be required should the seller's device not support monitoring the bitcoin channel itself, such as a standard computer client or an android client.  Of course, it's in the interest of both seller & buyer that another bitcoin device that can act as a gateway to the internet does exist.

To be clear, this frequency would be for the movement & broadcasting of transactions only.  These disconnected devices would have to get blocks by some other method, but an occasional wifi connection to promote updating the local blockchain would work fine, permitting stand alone devices to exist that could literally act as bitcoin wallets in meatspace.

As for the choices of ISM bands... (http://en.wikipedia.org/wiki/ISM_band)

The ISM band near 27 Mhz is very close to the Citizens' Band (USA) and the 11 meter ham band, so the propgation characteristics should be fair and the ISM is tiny, so it's rarely used by any other widespread tech that I know of.  So it shouldn't have to deal with much interference.  As the entire band is only 320 KHertz wide, even Dash7 wouldn't fit well using it's narrowest mode.  I'd say that a modern 'sound card' mode such as PSK31/63/125/250/500 would be ideal, but this requires both a sound processing chip (no longer a high requirement) and a tiny, single frequency (crystal controlled?) SSB transceiver (not so easy) to be within the portable device.

I don't like 40 Mhz, because the ISM band there is only 40 Khz wide, so PSK31 would be the only available mode narrow enough to fit without interfering into nearby licensed bands, which might bring the hammer down via the FCC; if only as an excuse. I don't consider PSK31 to be a fast enough mode to reliablely move a transaction, because it would take far too long to complete. (EDIT, I don't know what I was thinking here, except perhaps I was temporarily conflating Khertz with hertz; for PSK31 is only a 31 Hertz wide mode, not 31 Khertz.  A number of PSK500 channels could coexist on this band just fine.)

I don't like the 433 Mhz band, because it's already in use by many other consumer devices (garage door openers, being one) and the future might have that band packed with Dash7 devices.

I don't like bands of lower frequency than 27mhz, because even the 27 mhz band is going to require some fairly inefficient antennas to fit into handheld consumer devices, and anything of a lower freq is going to be worse.

It's a good article, but ironicly he displays his own economic biases by citing long debunked viewpoints while trying to indirectly support bitcoin with them.

I see.  Well, smooth migration was considered from the start by Satoshi, and mentioned in the white paper.  It was not expected that the algos that are secure today would remain that way forever, so there are 'stubs' in the protocol to allow future algos to be included and deprecated as required.

Your assuming that a problem will be found that breaks the current system.  I find that unlikely, considering all the algos that bitcoin uses are modular, and can be swapped out without much problem, so long as the developers & miners can agree on a future path.  Do you know what Stratum is?

I don't understand the goal.  What problem with bitcoin are you trying to correct?

Unless you have permission from your employer to do this, this is considered theft by deception around here.

Count me in for 1 satoshi, also.

If you think that you could do better, do it.

Computers are not different, just an extreme example.  Deflation is neither good nor bad unto itself, but think about the consumer.  Is it bad for the consumer if the price of a gallon of milk drops 5% a year?  Of course not!  Is it bad for the farmer?  Maybe, but his own costs are likely dropping by 5% per year also.

+1 for Candies, I received my order as expected and he went to great lengths to make certain that I was happy with what I got.

You can if your pruning algo follows the specs in the white paper.  Again, as you have already mentioned, you don't know.  You've done some research about the topics at hand, this much I can tell; however you don't completely 'grok' bitcoin.  Don't take that too personally, it took me weeks before I even understood the most obvious functions of the system.  The system works in so many interconnected ways to support itself, that I have insisted that Satoshi was either a team of professionals acting as an amateur or a truly gifted polymath just learning the art of programming.  The truth is, the system is elegant with finely tuned incentives, interactions and security tricks all in play, not some kid genius's after-school project hack.

For these reasons and others, it would be a terrible waste of effort and bandwidth form me to attempt to explain any of it to you here.  You're simply not close enough to it yet.

The devs didn't stop anything over the overflow bug.  All that they did was contact a majority share of miners, let them know that there was a problem, and asked them to cooperate.  They did.  If they had not, the devs couldn't had done much of anything to stop the overflow bug.  In hindsight, it wouldn't have amounted to much anyway.  Once those same miners had upgraded to the patched client, those same clients just started to reject blocks with an overflow transaction and backed up the blockchain as far as was required automaticly.  There were still old clients trying to submit tainted blocks for weeks because there were miners who had not been paying attention and had not upgraded.  I was here when that all went down, and wasn't mining; and I can honestly say the network didn't really skip a beat from the perspective of a casual user.


<sigh>  Again, you display your ignorance in such matters.  There are sound reasons for everything that ou sight, and foreseeable solutions to the potential problems that you noted.  These topics have been debated to no end long before you ever arrived.  The search function is your friend.


21,000,000,000,000.00
The number of BTC that will ever be produced (est) with 1 satoshi = 1 cent per decimal places, and what you get is 21Tn, or about twice the M2 money supply of the United States, only divisible down to 1 cent.


[/quote]

Okay, I see what you did there.


Again, there are sound reasons for the choices.  Do some research, please.


Not yet, but someone is going to add such funtions before they are really neeed.

Sure it is.  The idea isn't particularly useful if mining, because mining requires as little a delay as possible.  Regular clients, however, can tolerate transmission delays just fine.  It's useful for getting the blockchain to parts of the world that Internet access is sparse or prohibitively expensive.

You could, actually, if you wanted to become a donator to the site.  But tell me how you figure newbies are going to get some bitcoins to donate, if they can't post to the site first? 

Developers can't "stop the world" in any context, and tweaks can be made to the running network anyway, at least as long as users are willing to upgrade.  The network is particularly fault tolerant.


You don't know how the system works, but in the same sentence claim that Satoshi did a lot of stupid things?  Are you trolling?


Point one isn't true, but only because a decimal shift isn't how it would be done.  The values are stored in a 64 bit integer variable, but only about 54 bits are in use, so the leading bits can be taken as a 'marker' to tag values using an extended standard.

Point two is certainly true.


Where did you come up with that BS number?

Not if it's not installed.

Personally, I didn't feel like it.  But good call considering you haven't been here very long, most people don't understand this is possible.

Except those theories are B.S.  The only way to do what they imply is to have enough of the hashing power to deny all other miners the chance to broadcast a valid block, which either requires significantly more than 50% of the total hashing power of the network (which is actually over 100% if you are attacking the network, the 50% number assumes the worst case, that half of the previously honest network suddenly turns malicious) in which case you can do much more harm to the legitimacy of Bitcoin than a simple DoS attack on the blockchain; or one must be able to deny Internet access to a significant majority of your mining competitors for as long as you can (thus creating a sudden drop in the effective hashing of the network, leaving you with a cluster that is effectively half of the network anyway, but even this still requires that you be the biggest single cluster on the network).  The only known effective way to deny all miners access to the Internet, is to turn the entire thing off.  I seriously doubt that is even possible these days, for Bitcoin isn't particularly dependent upon DNS, which is the 'normal' way that is imagined about an 'internet kill switch'. 

In the long run, the most damage that either of these methods could do is to delay transaction clearing, not prevent them from occurring.  This could be a problem if the network could be backed up for days, but that is extremely unlikely.  Even Deepbit (should it turn to the dark side) couldn't do either of these things for more than an hour, assuming that the contributing miners didn't bail.

And as you pointed out, the current transaction rate wouldn't result in much backup at all.  Bitcoin would have to be several orders of magnitude more popular for that to be any risk at all, in which case bitcoin would also have several orders of magnitude more market cap value, and thus several orders of magnitude more hashing power (at least if the past three years is any guide in this matter).