Hi

I think it is a problem that you can never really trust that the chain will not be massively invalidated, and replaced by a longer one.

This is an issue for all but the largest instances of bitcoin. A global widespread bitcoin system wouldn't have this issue, but anyone else would.

If a small country, say Luxembourg, started a bitcoin instance for  themselves, they would never know if the German or French government would be hiding a longer chain,
just in case.

If a large bank wanted to disturb the current bitcoin system, they could just spend more CPU power than the current system, start from scratch and generate a completely new chain. They could intervene at any point including the beginning. All work so far would be invalidated. 

If a village wanted a small local payment system, they would constantly be in danger of attacks. The mafia could execute a lot of double spending, and then suddenly arrive with a long chain that invalidated all their payments, even though the merchants thought they had acquired the coins.

Anyone, bar the largest most high powered instances of bitcoin, will have this constant threat hanging over them.

The issue appears with network splits as well. After rejoining, one part completely ruins the other part, especially for coins that were present on both sides of the split to start with.

I think, there should be some guarantee that the chain will not be invalidated further back in time than a day, a month, or 100 blocks or whatever.

This problem is related to the problem of how many blocks you want to see before accept a payment (double spending problem). Satoshi has a calculation of this in the
pdf file. However, you need to know the CPU power of the visible honest part relative to the other part (p and q). The problem is that you never know how large the dishonest, or invisible, part is, because it can be hidden as long it wants to. Or it can be formed in the future. You never know.

What about this proposal? A node checkpoints blocks that are older than some threshold. The threshold could be a difficulty weighted block count, say a 100 blocks of 8 zero
bits. If a node receives a block chain that requires changing something that is older than its checkpoint, it refuses the chain. Each node would have its own checkpoint. But the honest nodes would be close. Their deviation would be small compared to the size of the threshold (100 blocks).

What would happen when two nodes disagree further back in time than the threshold of one of them. They should be considered forked currencies. One currency became two.
So the village, or Luxembourg, could ignore a hidden outside world, except for the very last part of the block chain.

The small village could use a very low threshold. The latency within the village is milliseconds. The could have block generation every 10 seconds. They could have a threshold of 5 blocks for instance. There is no valid reason, for a node, to stay hidden for that long in the village. If a computer loses its connection, it will just download the chain when it get online again; if it will tries to push a long block chain down the throat of the rest of the village, it has effectively created a new currency for itself.

Hi

I started a thread about the lack of fast local double spending verification a
week ago.  I was away for a week, and couldn't follow up on the thread. During
this week, I became even more positive about bitcoin. Contrary to what I said
last week,  I think that bitcoin could be a stand alone system; no issuer based
systems are needed to coexist with bitcoin. Bitcoin could be the real thing!
Kudos to all that have participated in it.  However, fast verification of the
absence of double spending is still important. I think, I have a solution that
more or less achieves it.

I should stress, that the underlying bitcoin architecture is completely
unchanged. My solution is living on top of bitcoin, so to speak.

Key to fast double spending verifications is to give coins a "location". A coin
can be local to such and such server in New York, for instance.  A New York
coin can be spent anywhere. It is valid anywhere etc. It is just that you can
expect faster double spending verification in NY.  Coins don't have to have a
location.

My proposed solution is to incorporate an extra field in outgoing transactions
designating a double spending verification server.  A coin's double spending
verification server is the one of the last outgoing transaction, of course.

The participants of the network are

1. Double spending verification servers. They do not exist in the current
system. The operation of a specific server is to receive a transaction for a
coin belonging to them, put it in a data store, and reply whether there is an
earlier transaction with the same coin.  In the case of no earlier transaction
just reply "ok", in the case of an earlier transaction reply "Double spending
attempt. The first transaction with this coin is so and so ..... ". The double
spending verification servers could be identified by a public key. This public
key might be the field stored in the coin. Some other database relates public
keys to ip addresses, dns or physical locations. The reply from the verifier
could be signed to prove the absence of interception.

2. The payer. The payer can choose a double spending verification server for
the outgoing transaction. Usually, one would choose the local one, or one that
is thought to be local for the payee. But anything goes, including choosing
nothing.

3. The payee. The payee will look at the double spending verification server of
the ingoing transaction, and send a request to this server.  If the reply is
"ok", the payee can trust the payment. If not, the payment is rejected. The
block chain is still the final judge, of course.  The super paranoid payee can
just wait for block incorporation, and is not forced to deal with the double
spending verifiers at all.

4. The bitcoin nodes. They will contact the double spending verifiers about
each transaction. If there is a double spending attempt, they will work on the
transaction suggested by the double spending verification server. This point is
crucial. The bitcoin nodes don't care how to resolve a double spending attempt,
so they just follow the advice of the corresponding double spending verifier.
This point is also what makes it possible for the payee to accept a payment as
soon as the double spending verifier has accepted it; the payee will know that
most honest nodes will favor this transaction.

So, a visit to a vending machine in would go as follows. The vending machine
would suggest some double spending verifiers that it trusts and publish the
latency for each of them. The wallet would choose the coin with the lowest
latency according to these figures, and pay with it. The vending machine would
contact the verifier and presumably get an ok, and release the product. It is
possible to prepare a wallet for a visit by making an exchange to oneself and
choose a new verifier. So on the plane to Australia, you transfer coins to
yourself and change the verifiers. When you arrive at the vending machine in
Australia, you will get millisecond response. But even, if the verifier is in
the US, the latency is still low. Much lower than block incorporation.

What if a verifier cheats? This will only happen a few times. You can publish
that you got an ok from a verifier, and then later the transaction was rejected
by the bitcoin network. It is even possible to use signatures to prove that the
verifier cheated if necessary. There will probably be quite few
verifiers compared to bitcoin nodes.

A group of people that wants to make some ultra fast local trading can then
meet close to a verifier, or run a verifier themselves, exchange their coins to
become local to this verifier, and start their high frequency trading. They can
all trust the absence of double spending without waiting for global
verification or block incorporation. 

Again, the bitcoin block chain is the final judge. This is just a voluntary
system on top.

Please, tell me if anything was unclear or I am missing something.

Hi bitcoin users

I found bitcoin yesterday, and I am really impressed by the idea of avoiding issuers/banks in a digital cash system.

However, I have one objection that I would like your view on.

That is the latency, or delay in a local transaction. Let us say that a payer and payee are located in the same city for example. I will claim, that they want a payment to go through
with a delay not much slower than the latency of network connections. With an issuer and using local coins (a prefix, say, can be used to localize a server of the issuer), the transaction should be done and verified in 100 microseconds or less. With a global p2p network, it is necessary to have all nodes receive the transaction, do some calculations and send results back.
It is not feasible,  with the speed of light as an upper limit, to do this faster than a second. As I understand it you actually use something like 10 minutes for one block, or even more for several block verifications. This means that verification of the absence of double spending is 10,000 or even tens of millions times too slow. This would get even worse in interplanetary trade of course.

The ideal payment system should be decentralized but also local, i.e., the verification of a local transaction must not have to wait for a light signal to travel to the other end of the "universe" and come back again.

Locality, in the sense describe here, is crucial, I will claim.

Sincerely,

Morten Krogh.