If you are calling my idea a throwback, that's part of the point.  Using less desirable spectrum in a novel manner is more likely to get approved than to attempt the same thing in the UHF or microwave bands.  As to the issue about interference from overpowered CB's, that's part of the reason for choosing very narrow bandwidths and phase shift keying has proven itself to be a very noise resilient mode on the shortwave ham bands.  PSK is so very different than AM or SSB spatter noise that it's often distingishable even in an otherwise noisy environment.  A quarter watt is a lot for PSK31 when your groundwave only has an expected radio horizen of about 10 miles.

There are several parrallel projects that I know of, none of which addresses transaction volume rates per se, but both of which contribute to the capacity.

The first one of note is the "naked block" change to the protocol that is forthcoming.  The point of it is that, because of the p2p style of propagation of bitcoin network objects, the actual transactions don't need to be part of a published block for miners to confirm that they are correct; because miner's almost certainly already have those transactions.  So broadcasting blocks complete represents a double broadcasting of those transactions.  The "naked block" change will permit miners to publish their blocks using only the block headers and the myrkle tree, which will reduce the actual data size of the published blocks.  This will help thoughput because the block size limit doesn't need to be increased in order to fit many more actual transactions.

Another is the development of 'overlay' processing networks, which are expected to take most of the burden of small value transactions using a reduced trust model.  The big one pursuing this line of inquriy is the Electrum client via their Stratum network.  What will happen is variations on the trust model of bitcoin will be employed to permit users within a particular overlay network to send arbitrary values to one another without using the blockchain at all, or only using the blockchain to settle up values periodicly or if a value limit has been crossed.  Online wallet services use a similar trick to permit users to send another member bitcoins without creating a transaction that must be processed immediately or individually.  The wallet services function similar to Paypal in this context, keeping the accounting in house; while the overlay networks can be expected to function similar to Ripple.  The end result is the same, many transactions between users cancel one another out, reducing (but not eliminating) the necessity to create bitcoin transactions.  Another reduction that overlay networks could employ is to use send-to-many transactions to gather up the individual transactions that users produce over a time period into one huge transaction with numerous inputs and outputs, expecting that the portions of those transactions related to various senders will be properly signed by their overlay network connected nodes in a timely fashion.  The economic force that can be expected to drive the development of such overlay networks are rising transaction fees.

Still another reduction in transaction volumes, also related to the send-to-many transaction, would be large institutions that gather up numerous payments to themselves to pay out to numerous creditors at once.  Think along the lines of Wal-Mart paying all of their employees their weekly payroll in a single transaction, or an individual paying all of their monthly bills at once.  While those actual send-to-many transactions would be quite large, the 'naked block' protocol results in Wal-Mart's weekly payroll transaction having no more of a footprint inside a broadcast block than another's simple Satoshi Dice payout.

So, while the main bitcoin network isn't really designed to handle huge transaction volumes (thinkof it more like the banks' ATM network, they don't handle all transactions, but they do handle those that require great security over distances) it doesn't really need to, and it can handle more volume than is commonly expected.

Bump.

Still looking for commentary from the radio geeks.

There was plenty of printing of unbacked paper money during the great depression as well.  This is what lead to the confiscation of private gold stocks followed by the revaluation of the gold standard from $22 to $35 per ounce in 1933.  Leaving the gold standard just makes all this crap somewhat less of a fraud than pretending that we actually operated as if we were on a gold standard.

In short, we are both correct.  The deflationary events can, and have so far since 2008, outpace the rate at which the Federal Reserve bank is willing to debase the dollar despite tehir willingess to do quite a bit of it.  Keep in mind that the Federal Reserve serves the member banks, not the US government nor particular politcos.  If they debase too fast, the public will lose trust in the value of the US dollar, and then a hyperinflationary death of the currrency will bring a rapid end to their 100 year long con game.  The bankers will never do this unless forced into it by politics, because hyperinflation is always and everywhere triggered by a political event.

The trade price in US dollars would likely go down as the buying power of the dollar increased, but the actual buying power of those same bitcoins wouldn't likely be significantly effected in the same way.  Keep in mind that a major stock crash, like the one in 1929 is highly deflationary; as is the destruction of debt.  (Debts that turn bad are written off as uncollectable, or discharged in bankruptcy; both events result in the effective reduction of available liquidity, which is deflationary by defintion)

I chose a total bandwidth of 12 Khtz wide, even though the space is probably 20 KHtz wide, because 12KHtz is the common passband of generic computer soundcards.  This would permit a station using consumer grade computer gear to listen to the entire band at the same time, while still being able to distingish between individual datagrams with overlapping broadcast times.  Better soundcards can listen to wider slices of spectrum, but I'm shooting for cheap here.

Notablely, there is a 4.8 Mhtz wide gap of useful spectrum in the GRMS/FRS band, situated between the simplex channels and the paired repeater input channels.  Between 462.7250 Mhtz (channel 22) and 467.5500 Mhtz.  And the channel spacing between the GRMS center frequencies are 125 Khtz wide but the channel is only permitted a 25 Khtz FM signal; which leaves at least 50Khtz of useful spectrum between each channel.  I don't know what these gaps are there for, but I'd wager that the 4.8 Mhtz gap is already allocated for something, I just don't know what.

Wait, What?  Did something important happen?  I didn't notice.  My client says everything is fine.

Alternately, the PSK31 channels could be interlaced with the QPSK1000 channels, permitting 12 datagram channels and (with one PSK31 channel at the farthest 100 Hz on either side of each datagram channel) 24 live keyboard channels.  I doubt that a proper QPSK1000 signal is going to step on a full 2KHtz wide spectrum, but I rounded up the spaces so that they would fit well.  Interlacing would be a more efficient use of the spectrum anyway.

Thank you.  I expect that I'll be fleshing out a blockchain datacasting proposal as well in the near future, based upon Digital Radio Mondiale.  The idea being that disconnected nodes can listen for blockchain updates from any number of DRM broadcasters across the medium or shortwave bands (or even DRM+ channels in the FM band, if that ever happens) as well as broadcast both their own transactions to whomever may be listening.  The current purposal would also permit, with some modifications, an Electrum server within a 100 klick range to respond to requests.  It's extremely unlikely that the FCC would permit encrypted datagrams, but since no Bitcoin network objects require encryption as such, that should be okay.

I've been thinking about this one for some time, and I have an early proposal that I'd like to flesh out with the brainiacs to see if there are any glaring errors that I've made, before I make a formal purposal to the FCC.  No, I'm not joking.

My proposal is to carve out a tiny 'band' about 12 kilohertz wide, centered at 27.095 Mhtz.  The radio heads will notice straight away that this is in the gap between channel #11 and #12 in the old Citizens' Band in the United States.  The reason there is such a gap there at all is because there is still a licensed remote controlled device frequency there.  I'm pretty sure that no serious remote controlled devices still use this frequency, since there are newer and more useful remote control bands in the 440 Mhz range.  If you have a device that uses this channel, it likely has one of those control pads with the huge pull out antenna.  If it has a "rubber ducky" antenna, or is shorter than 2 feet long, it's probably a 440 Mhz channeled device.

I propose that Quadrature Phase Shift Keying be employed, with forward error correction.  Between 27.089 Mhz and 27.091 Mhz would be as set of live "keyboard to keyboard" channels, each using a 100 Hz wide spectrum using transmission mode of PSK31 or QPSK31.  This yields 20 distinct channels within this 2 kilohertz wide band.  Transmittion powers would be limited to 1/2 watt peak envelope power in this section.

In the remaining 10kHtz wide section, between 27.091 and 27.101 would be a set of five 'datagram' channels wherein automatic rules based transmission and encoding would be required.  Each of these channels would be 2KHtz wide, and require the use of QPSK1000.  Within these channels, node to node or node to many broadcasts would be permitted; but a basic set of crash avoidance rules, similar to packet radio, would be expected of all players.  A single packet broadcast would be limited to 20 seconds, including preamble data and payload data, followed by a short postcode to let all other nodes know that the transmission is complete.  This should be large enough of a packet size that a normal sized transaction could fit into a single packet.  Other forms of datagrams would be permitted as well.  Peak Envelope Power in this section would be limited to 2 watts.  Packets do not require a destination node address, and any node listening that hears a datagram (such as a bitcoin transaction) can act upon that datagram depending upon it's configuration.  Alternatively, packets can contain gps directional information, and nodes would be permitted to "digipete" datagrams that it sees if it lays within 15% of the great circle path between the sender's gps code and the destination node's expected GPS code and/or the repeating node is within 100 kilometers of the destination node's expected GPS code.  This service would be "bursty" by design, and network protocols that require that content-less datagrams be broadcast (for the purpose of maintaining a virtual "circut" or persistant data connection, for example) are prohibited. 

Oh, I'm sorry I missed this little tidbit.

The client knows when it's missing a block, because the headers are numbered as well as "chained".  It can tell immediately when it's missed a block.  How that can be handled, either automaticly or otherwise, would depend upon the user's situation.  Something like a Pskmail server, modded for Bitcoin, would work for the random user far from any urban area.  So would paying for a few megabytes over a sat phone.  Even a usb drive over a snailmail "sneakernet" (or, more likely for the regions discussed, a "motorcyclenet") would work great as a method to get a somewhat recent copy of the full blockchain into otherwise disconnected networks.  A single, modified client running on something like a piratebox could form the basis for bitcoin trades among patrons at a particular market.  If the client could receive a regular or on-going datacast stream of block-headers & merkle trees; it could verify that the network has accepted transactions that occured locally (since it already had those transactions) and learn about all other transactions from a regular full blockchain update via a monthly usb-drive delivery from a completely different source.  It could broadcast it's own locally discovered transactions to the rest of the network via PSKmail like shortwave connection once each day, by connecting to such a server 300 to 400 miles away (Near vertical incidental skywave, single hop) using a soundcard connected single-side band tranceiver (most common shortwave gear) pushing only 10 watts.

For an example of effective Internet access for the very patient, google the term "pskmail".  With bandwidths that are exponents of 31.25, (31.25,62.5,125,250,500 and 1000 Htz) and practial after-error-correction data rates that are very close to those numbers; the spectral efficiency of PSK on shortwave is very close to 1:1.  Which is excellent for anything that bounces off a kilometers thick refractor, normally called the ionosphere.  The range using relatively affordable equipment is uncontested at normal power levels.  Could this be used to datacast the blockchain? No.  Could this be used to broadcast locally generated transactions?  Yes.  Could this be used to broadcast requests for missed blocks?  Yes.

Considering that Android Wallet operates in an "always on" networked environment, on an android device which is usually a smartphone, there is no other way to secure the wallet from malware.  An offline android wallet is possible, but pointless, and would still be exposed anytime the user desired to spend his bitcoins anyway.  So yes, the developers should force a password.  If you're stupid enough to make it too easy; well, you can't really fix stupid, but you can fix lazy.

Some will, some won't.  That's no differnent than a rally in gold attracting newcomers who get burned on the correction.  Strangely, there are still people who don't abandon that barbaric relic.

You don't always need a missed block, but if you do, there are alternative paths to aquire missed data.  That's the advantage of a true p2p network, you're never dependent upon any particular peer for performance.  Datacasting the blockchain would reduce the bandwidth requirements of (potentially) thousands of clients within the practcial range of the datacaster.  That does not mean that it would eliminate the occasional need for a direct connection to the bitcoin network.

Most datacasting protocols (for example, Digital Radio Mondiale) includes this delayed double transmission within it's protocol automaticly.  It's called "forward error correction".  While not perfect, it does work pretty well and actually doesn't require a full doubling of bandwidth.

Well, I'm not a programmer, but I have been thinking about this one for a while.  I see a couple of problems with PoS that I have not seen addressed.  At all, not even poorly.  The big one is that PoS functionally creates "supernodes" in the major stakers willing to break their own anonimity to "forge" new blocks.  Bitcoin has no supernodes, because no node trusts another more than itself.  This is not possible with PoS, since the proof of stake itself is functionally used as evidence of trustworthiness.  The problem with this is that PoS also creates the condition that such a "supernode" can turn malicious, and cause great harm to the system.  Supporters would be quick to point out that anyone with a large stake would cause themselves great harm in doing so.  Well, yes, and that is my point.  The building of such trust in 'stakers' creates a perverse incentive for those same stakers to be compromised by a malicious third party, because the trust they have built up with the system becomes a method of causing harm to both the PoS currency system and the targeted staker in particular.  Or, alternatively, an incentive for a malicious hacker to figure out how to 'spoof' being a major staker. 

While hybrid PoW/PoS systems are not as subject to this effect as a pure PoS currency, hybrid systems still functionally promote the 'supernode' issue by creating nodes with a disproportionate ability to mine new blocks.  PoW doesn't have this problem, because no particular node can 'build' or 'develop' any special trust that lasts longer than the target interval.  Furthermore, hybrid systems are particularly complex, and may have other vectors of attack due to said complexity.  PoW is expensive from an energy perspective, as compared to PoS, but it's realtively simple and it works.

This is not true.  Transacting with bitcoin requires bi-directional communications between transacting parties, but maintaining a local copy of the blockchain most certainly does not.


This would work also, but is not required per the light client protocol.  What has been proposed is to broadcast the blocks as they are published, and ultimately to broadcast the blocks "naked" once that protocol is ready.  The reason is that, eventually, most user clients will be some flavor of light client.  Unlike a full client, that are normal today, a light client doesn't care about all of the transactions in a block, and doesn't participate in the p2p bitcoin network (other than as an edge node, listening for it's own transactions).  A light client can fucntion just fine with occasional access to a bridge node (such as an electrum node) that can provide the light client information concerning transactions it's seen with addresses that the light client manages.  All that the light client requires is the blockchain headers and the merkel trees of block that contain input transactions for all of it's own addresses.  Broadcasting the published blocks would provide an alternative method for light clients to aquire the most recent block headers & merkle trees.  A light client may or may not keep the merkle trees for the blocks that it doesn't have input transactions, but as small as they are individually, the actual transactions are the bulk of data a full node sees while connected to the p2p network, and a light client has no use for most of these transactions.  Datacasting of naked blocks (block headers and merkle trees with all transactions pruned out) to either light clients directly or to disconnected bridge nodes used as intermediaries would permit bitcoin economies to function with only slow or occasional access to the Internet.

Begging is not, nor has it ever been, a cause for banning here.