You might be able to leverage this technique to gain an advantage over the network with less than 50% of total processor power under certain ideal conditions; but you will still need something very close to 50% even if your attack conditions are perfect.  It's also an attack vector that is unsustainable, as the first non-cartel block to get accepted by the network breaks any prior computational advantage and renders the cartel's prior work towards the next block based upon their delayed block worthless.  In the end, I would say that the conditions required to make this work would be nearly as difficult for any group as simply aquiring the resources to take 50% of the network.  Either way it's at a nation-state level already, and we are not a particularly large network.

Is this gateway broken for Visa prepaid debit cards?  I can't seem to get past the popup.

First, the day that comes that a reward is zero is beyond our lifetimes, and only a theoretical issue to us.  Second, the priorities system gives more priority to transactions that pay a higher fee.  So the blocksize limit, whatever it is in the future, functions as artifical scarcity as well as limit the bandwidth/storage consumption of the network.  If Bitcoin were to become as regularly used as Paypal, even a 10 meg top limit is likely to delay transactions of the smallest fee, creating a natural market price for the value of a near term transaction.  A future client can look at the most recent several blocks, and produce an average transaction fee recommendation for a user to get his transactions processed in a timely manner.  This premium on speed will likely be in constant flux.

Perhaps we should consider a "flushing block" every so often, wherein the top limit is uncapped for that single block, to allow all persistant transactions to clear.  This could be done once every retarget, permitting the network to catch up, so that even free transactions have a high end limit of two weeks of wait.

The point is that the creation of new  coins is mathmaticly similar to the mining of gold, as the mining continues, the difficulty of doing so increases until the mine is played out.  Also, there is the problem of initial distribution of a new currency, if the rate was continuous then it would take decades for the inflation rate to drop into the range of a rational currency, say 2-3% APR.  The halving system used by bitcoin will have distributed half of all the coins by 2013, 75% by 2017, and will be into an inflation rate preferable to any fiat currency on Earth today.  We wouldn't want to wait a couple decades before Bitcoin was preferable to a regular national currency issued by a government with "target inflation rate" of 2%.


The max block size is not imposed by fiat, but by agreement to a convention.  You could change that in your client right now and produce blocks just fine, but unless at least 50% of generators agree with you, whenever your client produces a block that defies this agreed convention it will be ignored by those who do.


Yes there are such market forces, at least there will be once the rate of transactions is averaging over 50KB per block.  Some fees are voluntary, but increase your priority, allowing your transaction to be processed in a timely manner.  There are numberous cases in real life wherein a delay of a couple of hours is unacceptable, and it would be worthwhile to tack on a transaction fee of .02 bitcoin in order to jump the line of freebies.  If you are tyring todonate to a cause, or just moving funds around between multiple clients of your own (working client to a savings client, for example) then you can probably wait a few hours, or a few days, for the transaction to get processed at the network's own convience.  Buying a car, however, would likely justify the fee for speed.

Other fees are not voluntary, but are required of more sophisticated transactions than the simple send X bitcoin to Y.

I think that you misunderstand the point of decentralization in the context of currency.  It's not the idea of a bank that is the problem, but the monopolies that cnetral banks have in our modern world.  Bitcoin banks will likely exist before very long, as Mybitcoin.com and Mtgox.com already offer some of the most important functions of a bank, but none of them can manipulate the system to their own advantage over any other peer, be they a user or another bank.


Those two incentives are not equivalant, transaction fees do not affect the value of all other bitcoins held by others.  Increasing the monetary base does.

Yes.  The current system cannot function without the blockchain headers, at a minimum.  That shouldn't discourage you from seeking another solution.

What alternative uses could exist that wouldn't detract from the primary function?

I agree, as do many others.  There is great risk in trying to adapt Bitcoin into some kind of multi-tool.  Simple tools that can be used in conjunction is what made Unix great, and both Linux & the Internet great by proxy.  Bitcoin should be a currency system, and leave the othe innovations to other tools.  The argument that some have made that another blockchain would take generation from Bitcoin (or vise versa) is a false one.  People will contribute to what is important to them.  Neither distributed.net, nor any other of the prior distributed work projects, makes any attempt to compensate participants.  If a p2p DNS is important, people will volunteer both clocktime and bitcoin donations to support it.

Use the search function.  Look for 'datacasting' and 'Dash7'


that is the chicken and egg problem, isn't it?  A client that uses balance sheets cannot independently verify transactions based on blocks prior to it's own initial startup, but a client that uses the full blockchain to verify transaction history doesn't need balance sheets.

Bitcoin can already work like this, just not as an absolute.  This is similar to my own 'datacasting' concept.

So a debit account, at a coffee shop?  That's not a faster solution.  It would be easier, an faster, if the retailer was willing to accept the small risk of a double spend attempt and just accept valid transactions on faith.  It would be less risky than accepting personal checks, as well as generally faster.

Just the transaction, would take only a few seconds to wrap the planet via the bitcoin network, (this would take longer in the future with many more nodes than exist today) but if there was an open hotspot in the store (perhaps with all outgoing ports blocked except bitcoin's own) and a running bitcoind locally, it would take longer for the customer to remove his finger from the 'send' button than it would take the store's client to receive & verify the transaction.  From a human perspective, this would be an instant; faster than the quickest credit card authorization.  This kind of check only verifies that the customer owned those recently, but does not check for a double spend attempt.  At the retail level for anything less than $20 in value, the risks and difficulties of a double spend would likely be high enough that there wouldn't be a reason to worry about a double spend attempt.  At any level that would require a credit check under normal circumstances, such as buying a car, would justify a couple of block verifications.

Just checking the transaction without waiting for a block would likely be a lower risk for the retailer than accepting personal checks with an ID.

the cryptographic portions of Bitcoin are somewhat modular, and can be swapped out for other/better/future versions of similar tools with majority consent of the network; no matter the reason for doing so.

hmm, I collect foriegn notes, and do not have either of those.  Are you willing to go out on a limb and risk sending those notes by international mail?

Free transactions must wait for another block.  Spamming only consumes space in the block reserved for free transactions, fee paying transactions have space (at increasing fee levels) up to 1 meg at this time.  The 1 meg limit is a hard limit, but much discussion about replacing the hard limit with a more flexible rule has already occurred on this forum.


I believe that the network can sustain a level of about 470 transactions per minute at this time, due to the hard limit.  We know that this is not enough,but these are changable rules.

correct


It is possible for a client to check that a transaction is valid independently, but it's  impossible to eliminate the risks of a double spend without waiting for comfirmations.  It's possible to reduce such risks without the blockchain, however, by scanning the transaction queue for attempted double spends for a couple seconds before approving the transaction; but the clients can't yet do this, AFAIK.

Yes it's possible, but the current client is not able to do many things yet that the protocol permits.  Part of it is that more than one address can input into a single transaction, totaling up to the amount requested, and the current client does nothing about displaying those addresses.

If you are talking about sending to a Mybitcoin.com account from another, this would be a different issue, as there would not often even be a bitcoin transaction in that case, as such internal transfers are usually handled internally by Mybitcoin's modified client servers. 

As I mentioned above, prices don't really offer information about the causes.  The above situation could happen without either inflation or deflation, although this would be corrected by actors seeking profit from arbitrige.  Prices tell you the answer, but not the question.

The excerpt that I left above is not true.  This describes the most common effect of inflation, but is not inflation.  Inflation is the the expansion of the monetary base (including credit extended) relative to the economic activity that it represents.  Deflation is the exact opposite; the reduction of the monetary base relative to the economic activity that represents.  Notice that this is a raw ratio, not a unit, and change can come from either side of the fractional.  In the case of Bitcoin, even though the absolute monetary base is expanding at a rate of ~60% as expressed as an APR; the value of bitcoin is increasing (the ratio is increasing) because the economic activity is expanding at a higher overall rate than 60% per year.  Without running any numbers, the rise in the value of bitcoin suggests that the economic activity of the Bitcoin economy is increasing at a rate closer to 500% per year or more.

The general rise in prices seen over time, is an expression of that ratio filtering across industries, but make poor indicators themselves because they are 1) late, 2) uneven across industries and 3) offer no information with regard to root causes.

That's why I wanted the client to be NFC/Dash7 aware eventually, because I think that either/both of these technologies will play a big role in the IRL use and trade of digital currencies.  Dash7 is particularly well suited towards spreading Bitcoin transactions and blocks, but even a wifi hotspot that blocked all ports except Bitcoin's would work fine for this purpose.

Yes, there is a reason that is not done in the standard clients, and running balance sheets have been proposed, but it's not neccessary in order to keep the local blockchain footprint down.  The blockchain can be 'pruned' of old transaction records that have been already referenced (spent) in "lightweight" clients such as cell phones, or even full clients once set up.  There will likely always be a complete copy of the blockchain available somewhere on the Internet, but only 'paranoid' clients need the entire thing and then only upon initial startup.  Once they have verified the entire blockchain, even the most paranoid client can prune years of records off the chain and need only keep the 80 byte long headers.


You understand it incorrectly.  Don't take this personally, as it's a very complicated system, and takes a while for even the geekiest among us to wrap their heads around.  I was here for weeks before I really understood it.

And a 'lightweight' client can verify transactions independently without the full chain, but it's more than possible to verify transactions without a local copy of the chain at all if your client is connected to the Internet at the time.  There is a number of ways that this can be done, but the current Android client functions as  a frontend to a remote bitcoind running on a server.  This bitcoind server is functioning as a "trusted node", in this case because both the server and client are owned by the same user; but it is reasonable that "trusted nodes" will be a common thing in a Bitcoin future, functioning as a type of bank and/or credit card company as a service.  The trusted nodes keep the blockchain, and verify all user transactions.


Feel free to write such a client.  If there are technical issues with such a shortcut, I'm sure that you will figure it out.


The resources of verification do not grow exponentially, or even linerily, with the size of the blockchain.


It might be both, but it's not immediately neccessary to be able to compact the blockchain for any reason; and provisions exist in the protocol to be able to prune the blockchain to significant degrees.  This system is still young, and alternative clients will start to pop up with other ways of doing things when the time is right.