>> (p.1)
    Author Topic: Proposed solution to the latency problem (vending machine problem).  (Read 10028 times)
    mkrogh (OP)
    Newbie
    *
    Offline Offline

    Activity: 17
    Merit: 0


    View Profile
    August 15, 2010, 11:42:15 AM
     #1

    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.
Page 1
Viewing Page: 1