undefined | Better HN

0 pointsdanbruc8y ago0 comments

I think you have to be more precise when making claims of this sort; in this case "establishing a global clock" is not very precisely defined.

I meant this in the straight forward sense and what GPS essentially provides, a means to globally agree on the current time with a reasonable high resolution.

Suppose we have an oracle that implements this protocol: it publishes a new public key every hour, and at any time someone can present it a blob of data which it will sign with the private key corresponding to the current hour's public key. Furthermore, you can query it for the set of all blobs it has signed with a given public key.

You don't state it explicitly but from »[...] the set of all blobs it has signed with a given public key [...]« I assume more than one blob can be signed with any key pair and I would then also assume every user can get an arbitrary number of blobs signed with each key pair, right? Or did you imagine a limit per user or key pair?

It is obvious that one can implement a distributed ledger with the only security assumption (for each user) being "I trust this oracle" and "I can determine the current time".

This is, at least to me, not obvious and I tend somewhat towards thinking is it not possible or at least not easy. If my interpretation from above is correct and there is no limit on the number of blobs that can be signed with each key pair then it seems to be at least non-obvious how one could reimplement Bitcoin on top of the oracle. Everyone could just fork and create arbitrary long chains of blocks because there is no proof of work slowing the participants down which I turn means that the longest chain is not necessarily the one that the majority considers valid.

Only if the oracle had a limited capacity and all participants flooded the oracle with request as fast as possible one could hope that the majority would be able to create the longest chain assuming the oracle processes all requests fairly. Maybe there is a way [substantially different from Bitcoin] to build a distributed ledger on top of this oracle but, as already said, it is at least to me not so obvious that I could quickly figure out how to do so.

0 comments

2 comments · 1 top-level

zodiac8y ago· 1 in thread

Yes, a user can sign multiple blobs. One construction is this: we agree on some genesis state (no block rewards are issued in this protocol). Call a transaction pre-valid if the transaction is signed by the oracle. A transaction is valid iff it is pre-valid, it is a valid state transaction (valid signature, enough balance etc) and if the originating account made no other pre-valid transactions during the same hour. Then you get finality after 1 hour (every user can agree on the set of valid transactions, and an account holder can finalize a valid transaction after waiting at most 1 hr), and no account can make more than one transaction per hour.

You can modify the rules of the protocol to be slightly more complicated to relax the "no more than 1 tx/account/hr" rule optimistically.

danbrucOP8y ago

I see. Actually you can get rid of the one hour interval and the signing. And you can also implement everything or at least many things on top of it. The oracle just records all incoming requests in order. Then, if you want to know the current state of the system, you just request all the requests ever made and apply them in order starting from some initial state. And of course ignoring all invalid requests.

Having such a trusted anchor of truth about all the requests ever made and their order is a pretty powerful primitive. At first look there is really only one problem beyond this that needs attention, making sure that not everyone can change everything, i.e. there will certainly be parts of the system state that should not be alterable be everyone, for example transferring money from your account to someone else.

But that seems reasonably easy to solve just the way it is done with Bitcoin and many other system. When you initially create an object that requires authorization ,you associate one or more public keys with it and requests to alter this object are only valid if the request passes a publicly verifiable challenge, for example being signed with an associated private key.

But this system seems not really interesting, it simply places the burden of serializing all request and guaranteeing their immutability in a trusted system and burdens all participants with the computational load to determine the current state of the system. At the expense of keeping the entire state of the system around, participants could just apply the set of new requests to their copy of the system state to lower their computational load and not have to request and process all requests every time they need the current state. This also lowers the network load.

But if we are already trusting the oracle to not mess with the requests received, it does not require much additional trust to let the oracle maintain the current state by applying all requests as they are received. Then participants could simply ask for the current state or parts of it and would not have to deal with all the requests or the entire system state. At which point we have an ordinary client server application with a database.

Initially we only had to trust that the oracle does not reorder request, delete requests, or insert new unsigned requests. If we do not compute the current state ourselves and just request it from the oracle, the oracle could additionally invent new signed requests without having the private key, for example it could just report changed account balances without there being any signed transaction that authorized that transfer. As long as the oracle still provides the set of all transactions, we could at least double check that.