Satoshi, the checkpoint is not used to make a judgement of which chain is better, but just to make sure that very old coins will not be invalidated in the "open" part of the network.

The software could just declare that there is a checkpoint 1000 blocks back. This is an individual checkpoint for each node, and the checkpoints would move forward every time a new block arrives. The checkpoint could never move backwards.

If a longer chain, predating the checkpoint arrived, the node would reject it. This would effectively fork the currency, but so what. In practice, it would just exclude the hidden
part. The "honest" part would continue along. Too bad for those with a long hidden chain. But they chose to be offline for too long.


The network, I see, is one of a lot of online nodes, visible to anyone who wants to see them. This is the core of the network. They will communicate so often, that no one will get 1000 blocks ahead of others. They will transmit their results continously, not collect them in a batch of 1000 blocks.

Then there are potential offline nodes, dishonest nodes etc. If they suddenly show up with a very long chain, there is no reason not to reject them. Or I don't see that reason.

The public internet will never get fragmented, in a major way,for days. And bitcoin is not suitable for such a situation, even though you technically can make it so by erasing all blocks in all but one of the fragmented components after the rejoin. 

You have a manual checkpoint, you say, which exactly shows that checkpoints are possible.

What is a bad chain?

Could you elaborate more on why checkpoints are bad?


 

You can say that, but it would be nice to use it on a smaller scale. It is interesting to think about how to achieve this without making the system too vulnerable.
Checkpoints could be one possibility. Maybe there are others.

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.

A different system. Why?
That different system would be a fork of bitcoin with 200 extra lines of code, or so, plus some verifiers which are just hash tables communicating with a simple http protocol.

The issue is this. The current bitcoin system has some freedom in what transaction a node works on, given a double spending attempt.
Right now, as I understand it, a node works on the first transaction it sees. Only after seeing a block with another transaction, will it change its mind.

Another possibility would be to flip a coin when a node has several colliding transactions.
Another possibility would be to ask a globally predefined node.
Another possibility would be to ask whoever the node feels like asking.

It doesn't matter; bitcoin works in any case. At some point a block will be generated with one of the transactions in all cases.

I want to use that freedom. The power of the proposal is that you have the ingoing transaction supply a name of a verifier.
There is nothing to lose by asking the proposed verifier, and there is a lot to win, namely ultrafast local trade.

By having the nodes put a transaction on hold, until either a timeout or a reply from the verifier, you can even have ultrafast local trade on Mars even though
most of the network is located on Earth. The general time loss by having the timeout is trivial, since it is similar to the latency in any case. On Earth it is within 200 milliseconds extra, say, in the worst case. The time delay is only large in exactly the cases where you want it. For instance, a Mars local coin, used in a vending machine on Earth. This is exactly the situation where suspicion is warranted.     

I hope someone understands what I am saying.

Cheers.

The NY vending machine can not generate blocks on its own. It has way too little CPU power for that.  The vending machine can be as dishonest as it wants to as long as it is
CPU dwarfed by honest nodes. Actually, I wouldn't even call it dishonest. Someone paid for a candy bar. But it can not force the coin to go to itself.
The vending machine's average time to generate a block could be years. It would only have an hour or so before all honest nodes are working to incorporate the Mars vending
machine's transaction.

Gavin, not with my proposal. The earth bitcoin nodes do not collaborate with the New York vending machine. They will follow the protocol for local verifications, and hence not work on the NY spending. This system requires that the majority work according to the protocol in any case.

I did not specify how honest bitcoin nodes work exactly. Here is one possibility.

When a node sees a new transaction, T, it does the following in pseudocode.

If (ingoing T has double spending verifier) {
 send request to verifier;
 if (response == ok) {
  put T into block and try to generate a hash;
 } else if (reponse == double spending, use transaction S) {
  put S into block and try to generate a hash;                       <- this is what would happen in your example
 } else { 
  // time out, verifier is out of order. The time out should take place after a time which is larger than a round trip to the verifier.
  put T into block
 } else {
  // T has no double spending verifier
  put T into block
}

In the Mars example, the following would happen.

S is the transaction on Mars, T is the one on earth.
T and S have the same ingoing coin, which is marked with a Mars verifier.

1a. You pay the Mars vending machine with T
1b. Your cousin pays the NY vending machine with S

2a. The Mars vending machine contacts the verifier and the network with S.
2b. The NY vending contacts the verifier and the network with T.

3a. The verifier receives S and replies "ok" to the Mars vending machine.
3b. Nodes will begin to see T and S on their respective planets. The nodes will follow the pseudocode above. Only outlaws will try to get S or T into blocks. The outlaws have
too little CPU  power and hence will not have generated any blocks yet.

4. The Mars vending machine release the candy bar after seeing the "ok".

A long time will pass. Neither S nor T are in any block, since the majority of the CPU power is in the "wait for verifier response mode". Other unrelated blocks are generated.

5. The verifier's repsonse will reach Earth, and the majority of the nodes will start working on S.

6. S gets into a block and more blocks are added later.


The NY vending machine can only take the coin if it controls a lot of CPU power and can generate a block, but the whole bitcoin system is built on the assumption that the vast majority of CPU power is honest. And being honest with my proposal means following the pseudocode above.

I should have specified this pseudocode in the original post. I didn't do it, because this protocol is one of several variations of the same theme, and I didn't want to be that specific. One variation is that the nodes could start working on T as soon as they get it, but that would break down in this case unless the difficulty was increased to a time much beyond the Mars latency, i.e. many hours.

Not in my system, because the bitcoin nodes would not work on a transaction before it was accepted by the verifier or before a certain time out has passed if the verifier doesn't respond.

Also, there could be a lot of cpu power on Mars as well. So, the New York vending machine shouldn't accept a Mars coin within several hours.


On earth, yes, but not in the Mars example. Most bitcoin nodes are far away.

Gavin, your solution has high latency. I want to solve the problem of locality. You can get double spending verification at a time scale that does not grow with the total size of the network.

There are two uses of this. One is for high speed trading, i.e. millisecond latency, the other is for huge networks. The vending machine might be on Mars for that matter.

This is why locality should be built in in some way.

Your method is simply too slow for me, otherwise it works of course. On this planet, your method would preclude verifications faster than 200 milliseconds say.
The speed of light is the fundamental problem.

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.

creighto, I am only talking about verifying the absence of double spending. Of course, you can always receive a coin and just hope. That is clear.

I don't think that physical coins have this issue. Or gold. Firstly counterfeiting is really difficult, secondly "bill verifiers or gold verifiers" are local machines. If someone could
counterfeit gold or coins in a way that no local machine could detect, then it would be the same. But no one can do that.

With bitcoin in the version I have seen (not red's), you cannot build a local machine that verifies it. I don't understand what red exactly is proposing.


NewLibertyStandard, your suggestion is a bank, that the payer and the payee need an account with. I don't mind, but I don't think it is an answer to the issue of this thread.

What I see as the ideal solution has these properties.

1. You can participate by just having some software on your computer/phone.
2. The coins are stored by yourself. A coin is a string of characters, no physical gold or so is involved. Encryption keys are fine if you can generate them yourself.
3. No accounts or registrations with banks or governments are needed.
4. Payments can be totally verified including double spending checks. Tiny probabilites can be ignored. But I mean tiny, not just reasonably small.
5. If a person is traveling to a city, he (she) can prepare for the visit by exchanging coins. This exchange can be slow. After arriving to the city, the person can make fast payments
to a person residing in that city. By fast payments, I mean payments that are completely validated in a time frame that does not depend on the total size of the coin system. In other words local trade should be possible, even if the digital cash system is used all over the world (or galaxy). The preparation before arrival is important here. Of course, many coins can not be verified, fast, against double spending by the payee, but there should exist some coins that can, given the location. And the payer can prepare before arrival by getting such coins.
6. No issuer on whose honesty the system relies.   


1-5 is possible with an issuer. The coins have a tag that denotes where double spending will be verified. The issuer keeps the information about those coins on their servers in that location. In other words, the issuer's distributed hash table follows some rules for what coins are stored where. And those rules are publicly available.

1,2,3,4,6 seems to be bitcoin if I understand correctly.

Does 1-6 exist. Is that what red is saying?

FreeMoney, yes I knew about that.

Red, very interesting. So, a set of transactions in bitcoin can actually be made local. But it must be possible to control where a transaction should be validated. That must be coin
dependent because of double spending. So, if I understand, it must be possible, for any transaction, to choose which location the resulting coin should be validated in when that
coin is used next time. A random choice would not be good enough. But, are there some problems with an attacker taking over a certain location. The global system had the strength that an attacker would be outworked by the sum of all other CPUs.

Red, can you elaborate more on such a distributed version of bitcoin. Is it described anywhere?

Cheers.

Yes, it might turn out very differently. No digital cash for the masses for instance. A giant banking cartel that bribes politicians to keep the current system.

But you can make it anonymous. Why are you bringing this up?This is a point, were I thought we agreed.
When I said monitoring, I meant including identification of the payer and payee.


Yes, that is my requirement, and will be most others as well. You will see almost no companies that sell without a guarantee against double spending.



Most of those will prefer a fast issuer based system over a slow decentralized system, I will claim.
But they might prefer bitcoin over paypal.

No, my goal is not to avoid government involvement in the payment system, but to not have the government monitor every transaction. There is a difference.

The current bill/coin system works like that. The government/central bank issues the currency but they don't monitor individual cash payments.
I think that is okay.

You claim that is possible to make almost instantaneous payments with bitcoin. How? That is what I thought everybody agreed upon was not possible. You need to wait for
one or more blocks to be solved before you can trust a coin. That takes minutes. Even in the best case it is limited by propagation, with the speed of light, around the network which is slow. The only solution is to create another banking system on top of this. Bitcoin then becomes the backbone of an intebank transfer system, not what the population at large is using.
   
It is not just me that needs fast transactions. There is giant demand for fast transfers of digital cash from cell phone to cell phone, web shopping, stock trading etc. 

But, we might just have different expectations from a digital cash system.

Has anyone ever stated clearly what problem bitcoin is solving? It seems to solve the problem of payments that don't need to be fast. But who are the potential users of that beyond people who thinks it is theoretically interesting like people on this board.

Do people agree with me on this point: We still need another digital cash system, and that probably needs to be issuer based.

FreeMoney, I think it is crucial to have fast local transactions. It is needed for many businesses and person to person payments.
10 minutes or even 10 seconds is too slow. An extraterrestrial system was just an extreme example.

The most pressing problem, as I see it, is to get a digital cash system that makes it possible for people and small businesses to pay each other fast and without
registration and supervision from a big company/government.

I read the thread about vending machines. There were no real solutions except companies that would monitor for double checking in a few seconds. I agree that would be possible,
but we would lose the whole point of not having an issuer. This company needs to be trusted, it will break anonymity, and people need an account with that company.

What is wrong with the follwing "standard" system. A central bank/government issues a currency like today. It sets up servers around the world to validate transactions.
People pay each other by means of a single verification with one of the centeal bank's servers. The speed issue is solved by coins having the location of the relevant server embedded in them. In worst case, the server would need to make long round trips to other severs, but in most cases the first server would know the answer already. The cental bank could have an algorithm for distributing coins around the network to optimise latency and server load. The wallet would have an algorithm for choosing the most local coins when making a payment.
The wallet could also prepare by exchanging coins with the server. On your way to Europe, the wallet replaces "American coins" with European coins, such that payments will be fast in Europe. For the user, this is incredibly easy. It is anonymous, and it requires no agreements with any processing companies.
Also, there could be many issuers of the same currency if so desired.

Bitcoin gets rid of the issuers, but instead introduces unacceptable slowness or a lot of middlemen like credit card companies/debit accounts etc. Satoshi's solution, on the vending machine thread, with a double spending checking company is still too slow, even though faster than a block, and this company needs an omnipresence on the network almost like
an issuer.

But discarding speed, bitcoin seems extremely elegant. And of course there are uses for this kind of system. One could imagine many local bitcoin systems with an exchange between
different currencies. That would work except that an attacker can take over a small currency.

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.