01:13:09	rodarmor:	rodarmor has left #bitcoin-wizards
11:57:44	wallet42:	wallet42 is now known as Guest41031
11:57:44	wallet421:	wallet421 is now known as wallet42
12:13:42	wallet421:	wallet421 is now known as wallet42
12:31:04	[\\\\]:	[\\\\] is now known as [\\\]
12:33:12	wallet42:	wallet42 is now known as Guest75754
12:33:12	wallet421:	wallet421 is now known as wallet42
12:37:08	wallet421:	wallet421 is now known as wallet42
12:51:49	wallet421:	wallet421 is now known as wallet42
13:40:04	wallet421:	wallet421 is now known as wallet42
14:30:18	erights_:	erights_ is now known as markm
14:53:58	wallet421:	wallet421 is now known as wallet42
15:29:55	erights:	Viewing sidechains as a platform/language/machine/os for general purpose computation, e.g., to support open ended smart contracts, what is the latest discussion of the security properties that this platform should have?
15:31:32	erights:	I am new to this channel. What is the best way to get oriented in the chat archives?
15:40:14	erights:	I'd like to start with the premise that it should be a simple ocap platform, such as W7 http://mumble.net/~jar/pubs/secureos/ , E http://erights.org , SES http://research.google.com/pubs/pub40673.html , or tamed pict http://www2.fiit.stuba.sk/~kosik/tamed-pict.html
15:40:47	erights:	However, none of these were defined with the constraints and tradeoffs of living on a blockchain or sidechain in mind.
15:42:47	erights:	Given that we wish to support composably secure general purpose replicated computation on a side chain, what additional constraints does that impose? Where are such issues discussed?
15:54:55	zooko:	erights: I'm interested in the topic. I don't know answers to your specific questions:
15:55:14	zooko:	How to use the #bitcoin-wizards logs, what forums are good for discussing these ideas,
15:55:31	zooko:	or what constraints apply to the combination of composably-secure languages plus sidechains.
15:55:51	zooko:	That last thing, in fact, I'm not really sure I understand what you mean by "on a side chain".
16:36:36	erights:	I refer to the sidechain ideas as discussed at http://letstalkbitcoin.com/e99-sidechain-innovation/ , http://www.ofnumbers.com/2014/04/09/paraphrased-notes-from-back-and-hill-interview/ , http://bitcoinmagazine.com/12349/side-chains-challenges-potential/ .
16:37:27	erights:	As I understand it, the basic idea of using side chains as a computational platform is:
16:39:53	erights:	the platform is a replicated deterministic computation, in the actors sense that all non-determinism has been reduced to arrival order non-determinism. The chain provides an agreed order of messages. Given an agreed initial state and sequence of messages, all replicas should compute the same result state and outgoing messages.
16:42:15	erights:	Ideally, one could imagine using the main blockchain for this purpose. However, that would require convincing the miners to take on a vastly more complex verification burden than they would (and should) be willing to: to verify that this computation on this state and messages does in fact result in these outgoing messages -- in order to admit them
16:42:15	erights:	into the agreed order log.
16:43:16	erights:	The sidechain idea is to separate risks, so that a sidechain can elect to take on this more complex verification burden, but with two way pegging and merged mining tieing it back into the main chain.
16:44:01	erights:	First thoughts on possible tradeoffs that are different from the forces shaping most of the platforms I list above:
16:46:43	erights:	Defense against denial of service attacks, in particular, resource exhaustion attacks, are crucial. This suggests reifying rights to the needed (suitably abstracted) computational resources, such as space and time, so that general purpose computation can only make use of resources it has "paid for".
16:47:41	erights:	Relevant ideas there are the KeyKOS family of operating systems, the early agorics work, and Matej Kosic's work on a memory-constrained variant of Tamed Pict (I forget the name).
16:49:57	erights:	It is important to have an atomic unit of operation that is itself guaranteed to take finite resources, including a termination guarantee, so that resource exhaustion leaves computation cleanly between units of operation, not within one.
16:51:15	zooko:	*nod*
16:51:43	erights:	In KeyKOS, the unit of operation is the user-mode instruction or the system call. A fault within either one leaves computation suspended in a state where the unit of operation can be restarted rather than needing it to be resumed in the middle.
16:52:03	zooko:	* zooko nods
16:52:41	zooko:	I like the way you describe isolating arrival-order-indeterminism from other stuff, and using a blockchain to disambiguate arrival-order-indeterminism.
16:54:34	erights:	Thanks. Relevant ideas on reified right to resources are the KeyKOS family of operating systems, the early agorics work, and Matej Kosic's work on a memory-constrained variant of Tamed Pict (I forget the name).
16:56:05	erights:	Even with side chains of much lower latency than the main chain, the latency between sending a message and delivering it will be vastly longer than the assumptions the systems above were designed for.
16:56:39	erights:	This suggests that communicating event loops with promise pipelining will be even more beneficial.
16:57:09	erights:	However, this kind of asynchronous message sending is hard to reconcile with strict accounting for memory usage.
16:57:15	zooko:	I'm a fan of that tradition.
16:57:22	zooko:	I mean the ocap literature.
16:58:34	erights:	KeyKOS does have strict accounting of mem usage, but by using a rendezvous messaging model, rather than a buffered async send one, and so would be awful to use over a high latency messaging channel.
16:59:16	sl01:	erights: have you looked at how ethereum is doing it?
16:59:28	erights:	I think I now need to understand that Pict derivative by Matej that I hadn't paid enough attention to before. Have you even looked at that? Do you remember what it is called?
16:59:58	gmaxwell:	erights: I'm sort of in and out right now— but a random question for you— do you know if any of the capabilities operating systems have created a solution for revocation of authentication?
17:00:14	erights:	sl01: I have not. What is the best first thing to read on this topic?
17:00:31	sl01:	good question, lemme look 1s
17:01:27	erights:	gmaxwell: I understand revocation of permission and authority, and I understand authentication. But what do you mean by "revocation of authentication"?
17:01:34	sl01:	maybe Ursium can find something quicker
17:03:41	gmaxwell:	erights: So say I give you access to some interface by handing you a capability, and then you can delegate that access by passing along the capability. Now how can the leaf be revoked without revoking the parent or other leafs?
17:04:12	zooko:	That's a well-studied problem in ocaps