3 ms·

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

by zodiac 9y ago

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.

danbruc 9y 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.

by zodiac 9y ago

danbruc 9y 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.