That depends upon how much existing trust you have with the counterparty.  Credit card transactions of less than $50 at a gas station are regularly approved automaticly without even waiting for the credit card network to respond.  The double spend attack is quite difficult, as it requires good timing; and there are other ways besides the blockchain itself to increase your confidence.

Still, I don't know how the simplifed system can discover payments that are sent to it from afar (as opposed to in person) without downloading full blocks before triming them.  Otherwise, how does it know that Grandma sent you 50 bitcoins with your eCard on your birthday this year?

The coins are made up of transaction records, which can be any value up to the full 21 million BTC possible and down to 0.00000001 BTC.  The coins don't actually exist as a digital artifact independent of the transactions that relate to them.  When coins are spent, the client will add up different transactions to greater than the total needed, and then output those coins to two new addresses.  One would be the address that you are sending coins to, another will be a new address of your own for the change.  So transactions merge as easily as they are fragmented, and this is done my the client by default.


Blockchain forks likely occur quite often, but it isn't problem unless the fork were to persist for more than 100 blocks, which is both very unlikely to occur and very unlikely to go unnoticed.  Short forks, of one or two blocks each, likely occur about once or twice each day, and will likely occur more often as the network latency grows with the user base.

Which is why some kind of solution such as the local / archived blockchain split that I mentioned will eventually become necessary.  In order to keep the chance of collecting transaction fees a valuable enough incentive to keep someone from altering a client to produce empty blocks just for the reward.  A two year local history wouldn't be any more difficult to keep locally than what we have right now, and would cover 99+% of all transactions that miners are going to ever see, no matter how long into the future we are talking about.  In a couple decades, there might be special clients that exist for the sole purpose of archiving the blockchain, and when the rare event occurs that a transaction is referenced that is older than two years, all of the generators are going to need a copy of that block.  So the specialized archive client would then be handing out copies of that block hundreds of times from ram.

Alternatively, the pruning process could still be employed by generating clients to great effect, since transactions wouldn't be pruned from the local blockchain until they have already been spent; and if they are not there anymore when a transaction calls for them, then the generating client can assume that the transaction is invalid anyway.

New feature request...

Blockchain broken up into distinct files, by year or half-year, so that really old blocks can be archived onto less-than-local storage while still be accessible to the client.

The transactions in each block are hashed into a merkle tree, and the merkle tree root becomes part of the block header.  Each header is 80 bytes long, and in the simplified version, a "lightweight" client can verify a transaction that is being sent to it is valid by downloading the block(s) that the input transactions referenced by the transaction to be verified from another peer that is not the peer that the transaction is coming from.  This does not need to be a trusted peer because the lightweight client can then check the hashes in the merkle tree to verify that each block sent to it is correct and complete.  It could also download another copy of each block as needed from another peer, but this probably isn't necessary in the transaction values that Joe Average is likely to ever keep on his smartphone anyway.  If the user has a trusted client, say a full client running on his pc at home, and a continuous Internet connection (which he probably needs with a lightweight client anyway) then even keeping the headers locally isn't necessary, as the trusted client could verify the transactions; acting as a remote app server for the smartphone client.  The simplified client mode doesn't even require that the client download new blocks in full, until such time as it needs to verify a transaction, and can wait to download the headers in groups up to 500 in a set, so bandwidth usage is greatly reduced as well.

If I got the details wrong, hopefully Gavin will set me back on the straight & narrow path.


A generating client must have ready access to all blocks referenced as inputs into all the transactions that it is including into it's block, because it must verify that all of those transactions are valid before working upon the block.  Otherwise, if a bad transaction is included into their block, that transaction will invalidate the block and all other nodes will reject it.  Which means that said generating client just wasted a great deal of time and energy on trying to get a block.  Currently, 'ready' access means that a full local copy of the blockchain is prudent, but there is nothing stopping anyone from using some kind of network file system for their blockchain storage.  I/O delays would put such a generating node at a disadvantage.  Perhaps someday the blockchain will be split up into a series of files, (perhaps one file per year) allowing the clients to keep the last couple years locally and still have access to the archives on another machine should they need it.

A fractional reserve bank could exit at up to a 50% reserve ratio, by openly stating that all deposits, including 'on demand' accounts, are used as reserve funds for loans.  Simply loaning out what they actually have on deposit, plus what they have in 'on demand' accounts, would be an advantage over a full reserve bank that had to be able to cover all 'on demand' accounts in full.

Yes, they do.  So do I.  It's not particularly difficult to build a small faraday cage to store your ham radio in, while it's not in use.  And I learned the cheap & easy tricks to do that while in the USMC attached to a Communications Company

Now I'm really curious.

It doesn't even need to be a separate network.  A major vendor (or a vendor associaction) has a dedicated server for a client without connection limits, and has established persistent connections to as many major generators as is possible, but also has a list of regular clients that are attached to it, or even a list of 'lightweight' clients that are multihomed.  When the vendor receives a transaction from a customer in the store, before approving the sale at the POS station, the vendor's client sends out a copy of the transaction to every major generator first, and then every regular client except for *one* randomly chosen multihomed regular client.  Then the vendor's client waits to see what transaction the randomly chosen client sends him.  If the chosen client sends back his transaction, the sale is golden.  If any other transaction for those coins come across, the sale is denied.  If nothing comes across for, say ten seconds, then you are in limbo; but probably still not at great risk because the client chosen randomly could have lost it's connection, etc.  It is necessary to not send the transaction to one client because clients don't forward transactions that are invalid, and the second transaction seen in a double spend attack is invalid.  If you send that customer's transaction to the generators, those generators will regard that transaction as the valid one anyway, and will not report to you any conflicting ones.  So by keeping one connected client in the dark, you can see if that client sees your transaction from the network at large, or another one.

No need for a parallel network, no need for a generating cartel, no need even for anything special beyond the function of the modified vendor's client.  It is likely that  insurance could be developed to protect against frauds, and this special client would be the insurance company's, but dependence upon a third party wouldn't be a practical requirement.

Not by any definition of that term that I have ever heard.  Even an American gold Eagle isn't legal tender because of the gold content of the coin, but because of the face value stamped into the side of it.

Who are you talking to?  It looks like you are trying to respond to me, but I didn't even address gold as a currency.

JA37, it is a basic root premise that the state, and by state I mean any persistent political structure that a citizen doesn't explicitly opt into, is based upon violence.  Violence is both it's reason for existence (national defense being the largest part of that) as well as it's means of support.  Taxation, even by representative democracy, is the use of force or a credible threat of force to extract wealth from someone who (presumedly) honestly earned it.  In any other context, this would be theft.  So when you openly support the state, or the taxation required to support the state, you are (indirectly) supporting violence against others.  I'm not an anarchist, myself, and generally agree with you that there is a minimum degree of government required to maintain liberty, order and prosperity in any society larger than the average church business meeting, but I also understand that I do advocate the judicious & minimum use of violence to achieve those ends.  This is, at it's core, the primary function of law enforcement.  This doesn't necessarily make such support bad, but you do need to be honest with yourself and others about what your support of the state actually means.

Well, let's examine that situation.  Could a convenience store accept bitcoin in real time?  I say certainly.  You walk in to the store to buy a candy bar, if you pay cash the attendant is likely to use a cash marker as a quick check for counterfit cash, but this is only a relatively minor means of avoiding such fraud.  In a similar fashion, a POS bitcoin client can check it's (presumedly recent) copy of the blockchain against the transaction that you produce for bitcoin.  If this check says that you honestly owned those coins up to the last update, it is unlikely that you are trying to double spend.  If we are talking about something a bit pricer, such as a grocery shopping trip in the 100's-of-dollars-range or so, the POS client might also be connected to a private VPN that exists to monitor for double spends in real time, (does your credit card transaction get approved in less than three seconds?  Even if it did, would it be unreasonable for the POS system to wait three seconds, looking for a competing transaction?  Longer than three seconds, and it likley doesn't even matter if a double spend is attempted, because the odds are extremely high that this transaction would be the one to get into the blockchain anyway.) signs of network divisions, or other possible frauds.  Some store chains, such as wal-mart would be likely to do this for themselves; but smaller stores and chains could join a VPN sponsored by their association.  Anything bigger, such as buying a new car, is likely to justify the increasing certainty of one or more blockchain confirmations.  Have you ever bought a car wherein the negotiations & credit process took less than a half-hour?

My point here is that it is possible, and likely, for a vendor to have a reasonable degree of trust that a valid transaction is legit without any confirmations (depending upon the relative value of the sale) and that increasing confirmations only add to the certainty.

That on top of local network latency.

A 2.5 second round trip delay is more than enough to put a node at a disadvantage.

This is starting to feel familiar...

http://bitcointalk.org/index.php?topic=723.msg8019#msg8019

http://bitcointalk.org/index.php?topic=691.msg7283#msg7283

Credit card charges less than $50 are not normally even checked at a Point-of-sale, such as a gas station, within a reasonable distance of the card owner's home.  Bitcoin permits a great deal better verification than the credit card companies provide the gas station owners.

And if the vendor is an online shopping vendor, there is no good reason to not wait for 6 confirmations before releasing an order for shipping.

www.mtgox.com


Yes.

T.I.M.T.O.W.T.D.I

There are some serious issues with such an idea, not the least of which is network latency, which is the main reason that the target interval is ten minutes to start with.  Another is the complexity added to the protocol.  And then I can't even see how it's necessary.  Transactions are complete in milliseconds, it's the confirmations that take ten minutes, which are way faster than how this is done by just about any other online method.  Credit card transactions are, likewise, nearly instant; but it can take up to 60 days before they are final.  So I have to ask, what is the problem trying to be solved?

This sounds like an agorist wrote it.  However, there is no way to know if this author is representative of Anonymous, since they seem to reject anyone who attempts to speak for them.