Kevin Reid
2012-06-02 01:41:46 UTC
Sending this to the list for archival/searchability. This is an discussion which occurred today on #erights <irc://chat.freenode.net/%23erights> including myself and Andrew Miller (from the Tahoe-LAFS project, I believe) on the topic of constructing an E vat out of a distributed verified data structure (the same sort of thing as Bitcoin is).
The primary problem is: how do you preserve the capability properties for sent and received messages if there is no place to put crypto secrets?
(Incidentally, #erights has been much more active (i.e. not dead) of late, due to some migration of general capability discussion from #tahoe-lafs. Join the fun!)
------------------------------------------------------------------------
[4:04pm] <amiller> ah related but not too important, one of the things that has amused me is that in #opentransactions one of the guys trying to use the opentransactions development branch
[4:04pm] <Zarutian> amiller: a bit like Nese in Deepness of the sky
[4:04pm] <amiller> is using it for this in-game currency in this massive text-based mmorpg he maintains
[4:05pm] <amiller> it's a truly epic thing, he's worked on it for over 10 years as a pencil and paper thing, he has a large following
[4:05pm] <Zarutian> amiller: ú, ya have a link to its website?
[4:05pm] <amiller> he goes off sometimes on these stories and it takes me a while to figure out if it's in the fictional universe or it's a metaphor
[4:06pm] <Zarutian> amiller: well sometimes fiction is only made to make mega metaphors and sometimes vice versa
[4:06pm] <kpreid> opentransactions is what, a framework for bitcoinish things?
[4:06pm] <amiller> ihttp://www.devtome.org/wiki/index.php?title=Galactic_Milieu
[4:07pm] <amiller> opentransactions is very peculiar
[4:07pm] <Zarutian> kpreid: iirc it is trying to implement some of Nick Szabo ideas in bitcoin-esque system afaik
[4:07pm] <amiller> first of all it includes an implementation of chaumian blinding for cash
[4:07pm] <amiller> it uses lucre, which ben laurie wrote
[4:07pm] <amiller> so it's meant to do something right off the bat that bitcoin doesnt
[4:08pm] <amiller> on the other hand, it doesn't have any distributed component, let alone a proof-of-work-based anonymous distributed component
[4:08pm] <amiller> it's based on a heritage of systems including Loom and Truledger that use digital signatures to minimize the reliance on the server that runs the thing
[4:08pm] <amiller> but it's not a complete solution, you're still very reliant on the server, for the reason that the server is able to 'counterfeit' money
[4:08pm] <amiller> basically they don't have any double-spend solution.
[4:09pm] <amiller> they're double-spend-vulnerable to the server
[4:09pm] <Zarutian> aah, I heard about those. Dismissed them out of hand due to exacly that, lack of decentralization
[4:09pm] <amiller> well, depending on whether or not bitcoin is a valid solution to distributed anonymous agreement, something like opentransactions may be the best thing
[4:09pm] <Zarutian> but as namecoin as demonstrated, it seems to be possible to transact something else but fungible coins in blockchain based systems
[4:11pm] <amiller> the basis of any system like this is a 'consensus' component
[4:11pm] <amiller> or what i called a 'notary' in my crappy tahoe-lafs post
[4:11pm] <Zarutian> amiller: consensus of the miners?
[4:11pm] <amiller> if bitcoin is possible, then you can use the proof of work lottery as the consensus component
[4:11pm] <amiller> consensus as in Byzantine consensus, but yeah
[4:12pm] <amiller> majority vote, transaction commit, w/e
[4:12pm] <amiller> if bitcoin works, then bitcoin is the first practical 'anonymous' decentralized agreement system
[4:12pm] <amiller> if it doesn't work, you can still have any of the other kinds of distributed systems
[4:12pm] <amiller> like in ben laurie's paper about bitcoin he describes that as a network of mintettes
[4:12pm] <amiller> it's just a typical distributed system, not an anonymous-public-entry one
[4:13pm] <amiller> http://www.links.org/files/decentralised-currencies.pdf
[4:13pm] <Zarutian> amiller: well, I have been musing on how to extend something like namecoin/bitcoin so one can declare new kinds of erights that can be transacted via the blockchain
[4:13pm] <amiller> so what i want to show is that because the consensus part can be factored out,
[4:13pm] <amiller> you could do anything like namecoin or erights and just swap out the agreement component
[4:14pm] <amiller> so it can run on either a cluster of mintettes, or on a blockchain/mining network
[4:15pm] <Zarutian> I thought the main idea was that everyone checked if outstanding transactions didnt conflict with the already agreed on history of transaction which is encoded in the blockchain
[4:15pm] <amiller> well the definition of 'conflict' is extensible in bitcoin
[4:15pm] <amiller> there's a little scripting language that no one knows how to use
[4:15pm] <amiller> the model that i am using for the general case of this
[4:15pm] <Zarutian> amiller: sorry, what are mintettes? mint-ettes? somethings that mint?
[4:15pm] <amiller> is that each 'transaction' has a validation function attached to it that describes its rules
[4:15pm] <amiller> and you have to query into your history database to run the validation function
[4:16pm] <amiller> Zarutian, you should look at my example https://github.com/amiller/redblackmerkle/blob/master/toycoin.py
[4:17pm] <Zarutian> amiller: well the scripting system in bitcoin is rather small and I think it was mainly to sidestep costly updates of the client software
[4:17pm] <Zarutian> (costly in "what did the devs change now? do I bother check and continue to trust them?"
[4:17pm] <Zarutian> )
[4:17pm] <amiller> well it's just nerfed
[4:17pm] <amiller> mintettes are just nodes in a typical network
[4:18pm] <amiller> in a typical distributed system, you designate your N nodes in the network
[4:18pm] <amiller> each one gets a private key, for exmple
[4:18pm] <amiller> okay let me try saying there are three orthogonal components to any system like this
[4:19pm] <Zarutian> as meredith said in that CCC talk titled "Science of insecurity" you really do not want turing completeness in your protocols or at very least very very rarely.
[4:19pm] <amiller> a) the central agreement system, is it decentralized? single server? anonymous like bitcoin? b) is it possible to validate transactions based on public history? how easily? merkle trees are useful here. c) what application layer is there? Is it just one rule like bitcoin, or is there a scripting language for Smart Contracts?
[4:19pm] <amiller> now for my analysis:
[4:20pm] <Zarutian> amiller: one rule like bitcoin? what is that rule?
[4:21pm] <amiller> 1) a) bitcoin is an anonymous decentralized consensus system, the only one of its kind; b) bitcoin right now it is possible to validate transactions, but only if you have a copy of the entire history. with the merkle tree thing i'm suggesting, you can validate any transaction with just the root hash; c) it has a scripting language, but it's disabled.
[4:21pm] <amiller> right - one rule like bitcoin - if you ignore the script, which is effectively neutered, then there is only one kind of rule for bitcoin
[4:21pm] <amiller> the sum of the inputs must match the sum of the outputs, and the signature must match the public key in each of the inputs
[4:21pm] <amiller> (that's exactly what's in my toycoin example as well)
[4:22pm] <Zarutian> well I thought the sum of the inputs must be equal or greater than the sum of the outputs
[4:22pm] <amiller> hah, yeah you're right
[4:22pm] <amiller> the difference goes to the miners
[4:22pm] <Zarutian> otherwise how would fees work
[4:23pm] <Zarutian> exactly
[4:23pm] <amiller> 2) opentransactions a) has only a single server consensus sytem for now. b) it is not possible to validate transactions, hence the double-spend problem, it's also not meant to be fully public c) it has a full smart contracts layer
[4:24pm] <amiller> opentransactions isn't going to go full merkle tree because they'd rather have some server reliance but gain privacy
[4:24pm] <amiller> it's probably possible to get both, using homomorphic encryption, but i can't think about that too directly or i start to go nuts
[4:25pm] <amiller> i'm mostly only interested in the full public case, so that's where i basically have to diverge from opentransactions
[4:25pm] <amiller> okay so let me ask you about how to extend erights to bitcoin
[4:26pm] <amiller> the goal of course is a) fully decentralized because we use bitcoin's mining kind of thing, b) public validation should be possible, i can explain how to do that with magic trees
[4:26pm] <amiller> c) the scripting language should be as expressive as E.
[4:27pm] <amiller> er let me just wind myself out trying to explain how i think it will work
[4:27pm] <amiller> una are basically just state machines
[4:27pm] <Zarutian> hmm.. this has given me idea. What about transactions being like capcerts, only you can refer to other capcerts by hash and then the input to each can be used by the capcert to select which output the referring one wants, among other things.
[4:28pm] <amiller> lets hash this out i think we'll get there quickly since we're on the same page mostly
[4:28pm] <amiller> but i'm not sure about the E part
[4:28pm] * Zarutian is catching up
[4:28pm] <amiller> E is a single state machine, isn't it?
[4:28pm] <amiller> do instructions get executed in a deterministic order
[4:28pm] <amiller> there's conceptually a single-threaded linearized timeline
[4:29pm] <kpreid> for any single vat, yes
[4:29pm] <amiller> different vats are under no obligation to share a linearizable timeline then
[4:29pm] <Zarutian> as I recall E has vats and those are each singly threaded event-loops that handle messages from outside
[4:29pm] <kpreid> amiller: correct
[4:29pm] <Zarutian> (the stuff that arrives via the far refs)
[4:30pm] <amiller> okay so i have no idea how to think about the multiple vat case.
[4:30pm] <amiller> but i really enjoy thinking about a decentralized implementation of a single vat
[4:30pm] <amiller> each vat stores some state and contains rules for state transitions
[4:30pm] <amiller> and the point of the distributed network is to reach an agreement on a sequential execution of transitions
[4:31pm] <amiller> it's important to look at the worst-case complexity of applying one of these transitions
[4:31pm] <Zarutian> amiller: where would the linerization of the timeline happen? in the blockchain of some bitcoin-esqu protocol or at a vat or more something like Croquet-SimplifiedTeaTime-Router?
[4:32pm] <amiller> i'm thinking blockchain, i don't know about croquet teamtime router but my guess is that is an ordinary distributed agreement protocol?
[4:32pm] <kpreid> btw, I was playing with explicitly modeling E semantics in a nondeterministic state-machine-like setting earlier this year. what I found was that it's very hairy simply because E is an imperative programming language and even simple object behaviors are tough to describe logically
[4:33pm] <amiller> okay so for bitcoin, the 'state' at any given time is the total set of unspent inputs
[4:33pm] <amiller> there are a lot of those
[4:33pm] <amiller> any transaction though only touches a small number of them
[4:33pm] <amiller> each transaction contains some number of inputs, some number of outputs; the transaction modifies the state by deleting all the inputs it spends, and inserting a new entry for each output
[4:34pm] <Zarutian> amiller: that last is basicly what many RealTimeStragedy games use and is what Croquet used. Basicly everyone sends their commands they want to affect their portion of the (game)state to a central server that does nothing but recive them, put them in some ordered sequence and broadcasts the sequence as it gets added to.
[4:34pm] <amiller> using magic merkle trees, any operation that touches M cells can be verified using O(M * log N) where N is the total number in the database
[4:34pm] <amiller> so it's linear in the number of state cells you actually read/modify
[4:34pm] <amiller> but it's subpolynomial in the total size of the state
[4:34pm] <Zarutian> unspent inputs? dontcha mean unspent outputs?
[4:34pm] <amiller> sure unspent outputs
[4:34pm] <amiller> one mans output is another mans input
[4:35pm] <amiller> okay so any instruction in E
[4:35pm] <amiller> has some stateful effect on the vat
[4:35pm] <amiller> it's hopefully deterministic
[4:36pm] <amiller> which means anyone with a replica of the state, applying the same instruction/input, will get the same updated state
[4:37pm] <kpreid> yes
[4:37pm] <amiller> is that true of implementations of E? they use like a deterministic subset of java?
[4:37pm] <Zarutian> amiller: deterministic vat where replicas get the same broadcasted inputstream, which I think you just described, is pretty much what a Croquet Island is iirc.
[4:37pm] <kpreid> implementation language is irrelevant
[4:37pm] <amiller> okay
[4:37pm] <amiller> well then look this is all it comes down to
[4:37pm] <kpreid> E does not expose visibly nondeterministic things to unprivileged code
[4:37pm] <amiller> if the state is an authenticated data structure
[4:37pm] <amiller> then it's publicly validatable
[4:38pm] <amiller> because you only have to look at each transaction as it gets broadcast
[4:38pm] <amiller> you don't need to have a full copy of the state
[4:38pm] CIA-46 left the chat room. (Read error: Operation timed out)
[4:38pm] <amiller> so for namecoin, the state is just the dns lookup table, and every transaction is some sequence of modifications to the lookup table, so it's a natural fit
[4:38pm] <amiller> for bitcoin, the state is just a set of unspent-coins, each transaction is modifications to that
[4:39pm] <amiller> you could implement any register machine this way
[4:39pm] <Zarutian> (well namecoin has unspent-coins like bitcoin plus the dns/name-value mapping stuff)
[4:40pm] <amiller> maybe it's worth describing some kind of stack language or something to show that you can compile some kind of script into a sequence of actions on an authenticated data structure
[4:40pm] <amiller> or else just work out a couple other examples
[4:40pm] <amiller> like what sort of property rights behavior would you want to specify
[4:42pm] <amiller> the components of this system again are going to be a) some network of miners or mintettes or 'notaries' that decides on a linear sequence of transactions, b) the 'public' who follows along with each transaction but only keeps root hashes around, acting as verifiers c) the users whoever they are that make transactions
[4:43pm] <Zarutian> amiller: hmm.. iirc namecoin allows one to subdivide the namespace one has registered a TLD for as DNS and hand out control of submappings as one sees fit. So, I wonder if one can hand out transactions (possibly conflicting ones) that do nothing but bind such a name to value A for one transaction or bind value B to the name.
[4:44pm] <amiller> ah okay so let me try to describe this state machine as a general purpose cap checker
[4:44pm] <amiller> possessing a cap is always about having the matching private key to some public key
[4:44pm] <Zarutian> (similiar on how one can serialize an unpublished btc transaction into an btc uri and encode as QR code and so on)
[4:44pm] <amiller> so when you give someone a cap, you write their public key into the state somehow
[4:45pm] <amiller> ah that's cool, that breaks my model a bit
[4:45pm] <amiller> since you can designate a public key
[4:45pm] <amiller> but give someone only a particular transaction
[4:45pm] <amiller> then they don't have hte private key / original cap, but they have an attenuated cap
[4:45pm] <amiller> i don't know how to describe that generally.
[4:46pm] <amiller> but that's the sort of thing you want to do with the authenticated data structure
[4:46pm] <amiller> it's just a big access control list
[4:46pm] <Zarutian> amiller: sound similiar on what MarkM was going on in his email list series on capcerts which I tried to condense into a wiki page and give it name: (active) capcerts.
[4:46pm] * amiller looks into it
[4:46pm] <amiller> the wiki page http://wiki.erights.org/wiki/Capability-based_Active_Invocation_Certificates
[4:47pm] <Zarutian> yes,
[4:48pm] <amiller> "We are unaware of any theory of composable auditability" i think that is a gap that is filled in by merkletreez
[4:48pm] <amiller> you're right this is exactly what i want!
[4:48pm] <Zarutian> though I was thinking about that as a way for vats to dynamicly attenuate and or construct ?control datastructures?
[4:49pm] <amiller> ah what's a good example pattern
[4:49pm] <amiller> at this point i normally start thinking about a chess game
[4:49pm] <amiller> and i'm still certain that's the right sort of way to think of it (i got the idea from a markm page) but it usually just confuses people when i try to explain it
[4:50pm] <Zarutian> lets say you want to give someone the capability of moving a pawn forward in a chess game hosted by a vat
[4:50pm] <amiller> perfect, go on
[4:50pm] <Zarutian> but you want to attenuate it so they can only do it before move nr 25 or some such
[4:52pm] <amiller> initially, 'you' have the capability of making any move?
[4:52pm] <amiller> or only the next move?
[4:52pm] <Zarutian> only that you are on a holiday where the price of Internet connection is so high or inconvient that you want to send your friend that cap via a postcard
[4:52pm] <Zarutian> amiller: I imagine that I would have a set of capabilities to instruct the pieces of my colour to do allowed moves
[4:53pm] * Zarutian coninues
[4:53pm] <Zarutian> but you are in luck as you know the public key of his vat.
[4:55pm] <Zarutian> so you make a chit which explains, in E code, what capability you are reffering to, the code that instanciates the attenuation and the public key of the friends vat and signs it with your vat private key.
[4:55pm] <Zarutian> (the vat you use to direct the moves in that chess game)
[4:55pm] <amiller> ohhhhh yeah. it's attenuation through function closures, basically
[4:56pm] <Zarutian> then your friend presents aforesaid chit to the chess game hosting vat
[4:57pm] <Zarutian> and gets that attenuated capability
[5:00pm] * warner has been thinking about this stuff a bunch recently
[5:00pm] <warner> I keep playing around with different ways of connecting the attenuating functions
[5:01pm] <warner> there's stack-based languages, schemes where you pass one function to another (and it invokes the second function with less-powerful arguments than the first one received), schemes where you run each function in an environment that was set up for it by the previous function, etc
[5:02pm] CIA-100 joined the chat room.
[5:02pm] <Zarutian> well, that is the rough idea
[5:04pm] <amiller> warner, do they all turn out to be equivalent?
[5:05pm] <warner> I think so. I think they'll have different ease-of-programming feels, though
[5:05pm] <warner> I have to actually build a couple to compare them properly, though
[5:05pm] <Zarutian> the implementation, yet to be realized, is basicly that each capcert describes the body of an unary function that only gets a enviroment which is safeEnv augmented by a unsealer for the issuer of the capcert and (lazyly initialized) registry of sealers indexed by keyid/fingerprints of other issuers.
[5:06pm] <Zarutian> and that function is given to whoever/whatever presented the capcert
[5:06pm] <amiller> back to the chess example
[5:06pm] <amiller> in a way, at the beginning, we have a pair of mutual capabilities to play any chess game
[5:07pm] <amiller> but as we make moves, we attenuate the ways of finishing the game
[5:07pm] <amiller> eventually we've played one single chess game
[5:07pm] <amiller> we could just pass signed move transactions to each other out of band and then play the whole game in one commit
[5:07pm] <Zarutian> "whittled down the possibilities" is a phrase that comes to mind
[5:07pm] <amiller> or we can play each move on the table
[5:08pm] <amiller> maybe it doesn't matter which
[5:08pm] <amiller> suppose i have the cap of playing my opening move
[5:08pm] <Zarutian> passing signed move transaction to each other is exactly how mail-chess works afaiu
[5:08pm] <amiller> but i want to partially play it
[5:08pm] <amiller> i want to commit to moving one of my panws
[5:08pm] <amiller> but i don't yet specify which - that's where my intent may be to designate someone to have that attenuated ability
[5:09pm] <amiller> but just like before i can either just give him the ability to play both steps at once, or i can do the first one
[5:09pm] <amiller> to play partial moves like that, then the state would have to include some attenuation mechanism, a transaction isn't just a chess move, but a partial chess move sometimes
[5:09pm] <amiller> the next person definitely can't move until i've played a complete move
[5:09pm] <amiller> then again maybe they can!
[5:10pm] <amiller> what if i say that i'm only going to move a pawn on my second move
[5:10pm] <amiller> can i enter that into the state before i even make my first move
[5:10pm] <Zarutian> amiller: the attenuation mechanism is what E can express iirc.
[5:11pm] <Zarutian> amiller: depends if your set of capabilties have to be renewed every move somehow or not.
[5:11pm] <amiller> can i express either case in E?
[5:11pm] <Zarutian> lesse see
[5:15pm] <Zarutian> yes, as your move-piece-capabilities could have been attenuated with caretakers beforehand and you put in an ?thunk? which gets executed on second move before you get to decide on that turn and another thunk after. The former thunk tells the caretakers of all other pieces than your pawns to not allow through messages while the latter tells those caretakers to re-enable.
[5:17pm] <Zarutian> (that depends of course that there is a mini-cron like factility that runs such thunks implemented in the chess game support code)
[5:18pm] <amiller> is there a canonical example of chess implemented in E
[5:18pm] <amiller> or something similar
[5:19pm] <amiller> where players alternately receive caps for their turns
[5:19pm] <amiller> does it really require a cron? i wouldn't think so
[5:20pm] <kpreid> amiller: there's a "racetrack" game in the EoJ dist where players submit moves for their cars, but I forget what other point it was meant to illustrate
[5:20pm] <Zarutian> or barring that mini-cron not existing you could give your opponent a capcert that does that second move attenuation, sets a flag. Then you have your capcert that reenables if that flag is set.
[5:20pm] <Zarutian> kpreid: promise pipelining, eventual send and far references iirc
[5:21pm] <amiller> is there a single essential primitive for E? like makeBrandPair?
[5:21pm] <amiller> from which you can construct all the rest of it
[5:22pm] <kpreid> no, and makeBrandPair isn't a primitive
[5:22pm] <kpreid> the core of E is lambda calculus + assignment + turns/queued messages
[5:23pm] <kpreid> well, you could build the last
[5:29pm] <amiller> hmm, so for me to attenuate my own capability, e.g. for me to commit to moving one of my pawns but saving the decision of which one for later,
[5:29pm] <amiller> i would need to interact with some agent who held a higher cap?
[5:30pm] <amiller> if all i have is a capability to move on of my pieces on this turn, there's no way i can send a message to the vat that actually attenuates my own cap by partially constraining it
[5:30pm] <dash> amiller: what do you mean by "higher"?
[5:30pm] <kpreid> "commit to" is not well-defined in E since state is private
[5:30pm] <davidsarah> arggh...
[5:31pm] <kpreid> but you are talking about a public-state vat which changes things
[5:31pm] * davidsarah really wants to participate but has to do work
[5:31pm] <kpreid> Oh, wait, it works even in a simpler model.
[5:31pm] <kpreid> Let's imagine for a moment that the game is managed by a normal E vat and I'm another E vat
[5:31pm] <davidsarah> such as a functional process model like Erlang, for example
[5:32pm] * davidsarah goes back to doing what they should be doing
[5:33pm] <kpreid> I want to commit to "move a pawn". I write a facet (i.e. a wrapper object) which passes on only "move a pawn" messages, and I *transfer that object to the public vat*. I drop my reference to my "make any move" capability.
[5:33pm] <kpreid> Hm, but if you replace CapTP with a cryptocap system my dropping the reference is unobservable.
[5:34pm] * Zarutian raises hand: how can you assure anyone that you have indeed dropped that "make any move" cap?
[5:34pm] <amiller> mm
[5:34pm] <kpreid> Well, it just needs to be a cap system which includes a "revoke this capability" operation.
[5:34pm] <amiller> quite.
[5:34pm] <kpreid> (this implies for shareability to have a "clone-wrt-revocation" operation as well ,but that's OK)
[5:34pm] <Zarutian> kpreid: pretty much all caps would be caretaken then?
[5:35pm] <kpreid> Think of it less like a caretaker and more like dropping an entry from the swiss table
[5:35pm] <Zarutian> kpreid: aah, okay.
[5:36pm] <kpreid> But anyway, the point is that I can deliver a move-restrictor *to* the public system and so make it public.
[5:36pm] <kpreid> (On the other hand, this implies I can DoS the public system.)
[5:36pm] <amiller> lets assume you can pay for your resource
[5:36pm] <amiller> if it just comes down to state
[5:36pm] <amiller> or swissnum entries
[5:36pm] * Zarutian attempts to bribe davidsarah with a bitcoin to take part for few minutes
[5:38pm] <amiller> bitcoin afterall is basically just a usage token, you have place at least one satoshi down as a rental deposit on every bitcoin output you create
[5:38pm] <amiller> so delivering a move restrictor is creating a new object in the public vat
[5:38pm] <amiller> there's a new reference added (a new swissnum?)
[5:38pm] <kpreid> yes
[5:38pm] <amiller> oh, and if the old one is revoked, then it's a replacement
[5:38pm] <Zarutian> yes, to last (if I understand where kpreid is going with this)
[5:39pm] <Zarutian> (creating new restrictor in the public vat that is)
[5:42pm] <amiller> when i actually make a complete move, i'm also creating a new object to represent my opponents next move
[5:42pm] <kpreid> well, the game managing public vat should contain the code for that
[5:43pm] <amiller> well someone initializes the game
[5:43pm] <amiller> designates the two players by their public keys
[5:50pm] <amiller> where are the public keys in E?
[5:50pm] <amiller> vats?
[5:51pm] <amiller> if alice and bob are playing chess are alice and bob each identified by their vat, that could make sense to me but i think i'm wrong
[5:51pm] <dash> only trust makes distinctions
[5:52pm] <kpreid> amiller: in standard E a vat is id'd by a public key (used to authenticate the vat when contacting it)
[5:52pm] <kpreid> + one swissnum for each persistently accessible object
[5:52pm] <warner> hm, what if you could publish a revokecap that *anyone* could exercise?
[5:53pm] <warner> something where anybody else could present it to the public system and get confirmation that it really does revoke the authority that you claimed
[5:56pm] <amiller> kpreid, so what does it mean that in your game example above, one of the players was another E vat
[5:56pm] <kpreid> not actually necessary
[5:56pm] <kpreid> just that the communication to the public vat is over something sufficiently captp-like for my model to hold
[5:57pm] <amiller> how can i delegate a cap in E publicly, by designating their public key?
[5:59pm] <kpreid> there is no "public" in E so as soon as you do that you're creating new things, so that depends on your design of extension
[5:59pm] <amiller> mm
[5:59pm] <amiller> ok then maybe that's the essential thing you need to represent bitcoin in E...
[6:01pm] <amiller> maybe you just need one requireSignature(f, pubkey) function?
[6:01pm] welterde left the chat room. (Ping timeout: 264 seconds)
[6:02pm] <amiller> that seems clumsy, since i don't know where the pubkeys come from
[6:05pm] <amiller> in tahoe-lafs, a verify cap is a public key, and the write-cap is the matching signing key
[6:05pm] <amiller> so if i designate someones pubkey to execute some function, then they _have_ that capability even if i don't communicate anything to them
[6:06pm] <kpreid> since vats are the reliance units it's entirely reasonable to add facilities by which an object can have its vat sign something (with some kind of add'l note identifying the object)
[6:06pm] <kpreid> or similar operations
[6:07pm] <amiller> ah okay so here's where the rubber hits the fan
[6:08pm] <amiller> if someone's access to a cap is constrained by public key, how do they do one of those partial execution / attenuations
[6:08pm] <amiller> then can't send the public vat a function that signs a message for them!
[6:08pm] <amiller> they can't*
[6:09pm] <kpreid> the defined-by-public-key capability would have to be *to the move-restrictor they wrote*.
[6:09pm] <amiller> right but the move restrictor would have to support further delegation
[6:09pm] <amiller> the simplest implementation of defined-by-public-key would require the actual message to be signed by the delegatee
[6:09pm] <amiller> but that's not good enough because you can't keep redelegating publicly
[6:10pm] <amiller> i mean you could wrap your private key up in a closure and send it to the public vat
[6:10pm] <kpreid> the move-restrictor holds a *local* reference to the make-a-move cap
[6:10pm] <kpreid> so there is no signing needed
[6:12pm] welterde joined the chat room.
[6:20pm] <amiller> i'm going in a bit of a loop trying to understand current E and the capcert active invocation scheme
[6:21pm] <kpreid> I can't help you there, I only know of capcert as that thing that Zarutian rambles about
[6:21pm] * kpreid is a ocap guy, not a crypto guy, and lets that statement identity get to his head too much
[6:21pm] <amiller> Use signing key pairs to represent object identity, where the (public) signature verification key designates the object and the (secret) signing key represents the permission to be the object.
[6:21pm] <amiller> Zarutian, maybe you can help me close this gap then
[6:22pm] <amiller> i understand how to do a thing in E now, but i understand how i need to introduce a public key somewhere, and capcert does that but i don't understand where the key comes in
[6:22pm] <amiller> the public key is associated with an object?
[6:23pm] <amiller> when i create an instance of a chess game, do i create two player objects, one for alice and one for bob, each identified by a public key?
[6:23pm] <amiller> their transactions are signed messages to their respective 'player' objects in the public vat
[6:25pm] <Zarutian> amiller: the public key is associated with a vat
[6:26pm] <Zarutian> (it is going to be the same one as captp uses once I figgure out how to extract/use it)
[6:27pm] <amiller> what has to change for there to be a public-vat then
[6:28pm] <Zarutian> as I understand it a vat is something that runs somewhere and not just inert data
[6:29pm] <Zarutian> what you probably want is an unum with public state.
[6:30pm] <amiller> what would capcert look like if it ran on one of those?
[6:30pm] <Zarutian> on unum or vat?
[6:30pm] <kpreid> Zarutian: we're trying to make a public unum which *implements a vat*
[6:30pm] <Zarutian> oh, I see
[6:32pm] <amiller> public keys and signatures have to be involved, they have to be threaded along with the function calls somehow, it's just not clear yet how to bind it all up
[6:33pm] <amiller> it's no good to have every message signed
[6:34pm] <amiller> because if i create a new capability and reference that someone else can invoke, and it sends a message, that message needs to carry the weight of my original signature when the cap was defined
[6:34pm] <amiller> i don't have to sign the actual message that gets sent.
[6:34pm] <amiller> that's the first major difference between what's needed here and what capcert does
[6:35pm] <Zarutian> hmm... the only way I can think of at the moment is that the unum creator includes his public key in the initialization code then sends a signed message desginating the public keys of the players.
[6:35pm] <kpreid> amiller: I think you missed my point
[6:35pm] warner left the chat room. (Quit: yay meetings)
[6:35pm] <kpreid> amiller: when I create a new capability, I give its implementation to the public vat; this means that it uses an intra-vat, not crypto, reference
[6:36pm] <kpreid> uses an intra-vat reference to the previously existing capability, I mean
[6:36pm] <Zarutian> (to anyone replicating the vat (in effect publishing the message)
[6:37pm] <Zarutian> )
[6:38pm] <Zarutian> kpreid: so each player has in the public vat an evaluator than evals any code signed by that player?
[6:39pm] <kpreid> that's just standard E mobile code, not a feature for this, but yes.
[6:39pm] <Zarutian> so, the evaluator of each player represents that player inside the public-vat unum?
[6:42pm] <amiller> messages to those evaluators must be signed then, but those are the only kind of messages that need to be signed
[6:42pm] <kpreid> the evaluator is not a special case
[6:42pm] <kpreid> it's just one of the things that you can get access to during unserialization in a vat
[6:43pm] <Zarutian> given a starting state, signed by a public-vat unum creator(s), and the history of signed messages to the evaluators (or avatar objects) inside that unum you can do this?
[6:44pm] <Zarutian> (this being what ever amiller is after)
[6:46pm] <kpreid> I'm assuming the premise that we can define a public Turing-complete system in which we can implement an evaluator, yes.
[6:46pm] <amiller> turing-complete isn't necessary if we can pick anything else
[6:47pm] <amiller> the calculus-of-inductive-constructions that Coq is based on is sub-turing
[6:47pm] <amiller> always terminates in polynomial time in the length of the code
[6:47pm] <amiller> i don't think that aspect matters really
[6:47pm] <kpreid> sure, refinements
[6:47pm] <amiller> i don't understand this history of signed messages though
[6:47pm] <amiller> messages are signed?
[6:47pm] <amiller> oh right the messages are always signed between vats
[6:48pm] <amiller> it's just they're not always thought of as a history log i suppose
[6:48pm] <kpreid> in Pluribus (standard E comm stack), connections are authenticated using a key pair, but messages on the connection are not signed
[6:48pm] <Zarutian> amiller: each message from outside the public-vat unum that are meant to change the public state rather than merely the state of your local copy is signed.
[6:48pm] <kpreid> what a public vat needs, well, you're working that out
[6:49pm] <Zarutian> (similiar how you can keep a chess board updated based on reports heard on the radio of a chess tournament)
[6:50pm] <amiller> okay i think i follow that
[6:50pm] <amiller> alright so this avatar/evaluator and vats
[6:50pm] <amiller> a public key represents an external vat, say Alice's vat
[6:50pm] <amiller> so when i create this chess game for alice and bob, do i create player objects for each of Alice and Bob? do those objects live on the public vat or on their respective vats
[6:50pm] <kpreid> I reject the avatar notion.
[6:51pm] <amiller> Alice is white, how do I say that the first move needs to come from alice
[6:51pm] <kpreid> as I said, the evaluator is just *one of the facilities available* when unserializing messages
[6:51pm] <kpreid> there are no "player objects" on the public vat
[6:51pm] <amiller> well, some facility needs to get enhanced with a public key and a signature validation.
[6:51pm] <amiller> we're just trying to figure out which one
[6:51pm] <amiller> i think only one is necessary if we pick correctly
[6:51pm] <kpreid> there is facet-for-use-by-Alice and facet-for-use-by-Bob
[6:51pm] <kpreid> these receive move messages
[6:51pm] <Zarutian> kpreid: how else are you going to keep what Alice can do seperate from what Bob or anyone can do? the public-vat unum cant hold secrets
[6:52pm] <kpreid> signatures are needed to authorize messages, yes
[6:53pm] <Zarutian> kpreid: okay you could have facets in the public-vat unum that check if the message they recived is signed by this or that key.
[6:53pm] <kpreid> no, the signatures should properly be part of the comm layer
[6:53pm] <amiller> kpreid, in your view, where do you put the public keys?
[6:53pm] <kpreid> the part which decides *that* the facet is to receive a message
[6:53pm] <kpreid> amiller: in the comm subsystem of the public vat
[6:54pm] <amiller> i mean who desginates a public key, and when?
[6:54pm] <kpreid> the comm system is the translator between the network/crypto world and the ocap world
[6:54pm] <amiller> i need to be able to do something like say here's a new capability and it requires signatures matching <pubkey>
[6:54pm] <kpreid> in an ordinary E system, you tell the comm system to publish a cap, and thus get back a cryptocap for it
[6:54pm] <kpreid> in this one, you would provide a cap and a pubkey instead
[6:54pm] <Zarutian> kpreid: so the facet is outside the public-vat unum but inside the comm system. Does the public-vat unum serialization have anyway to specify that a facet can only recive messages signed by the desgined private key?
[6:55pm] <kpreid> No, *this* comm system is part of the public-vat-which-is-an-unum
[6:55pm] <kpreid> that is, it's part of the state which is maintained/verified distributedly
[6:55pm] <Zarutian> aah, I see
[6:56pm] <Zarutian> that was what I was trying to get at
[6:57pm] <Zarutian> so the serialized depiction of a public-vat unum contains the state accessible to code inside the unum and state supporting that code and state?
[6:57pm] <kpreid> yes
[6:58pm] <Zarutian> I was confusing the picture of the pipe with the picture of the picture of the pipe, so to speak
[6:58pm] <amiller> this publish-a-cap, i don't understand
[6:58pm] <amiller> what function is that?
[6:59pm] <kpreid> it takes a local object, i.e. one that has only intra-vat references, and makes it possible to refer to it outside the vat
[6:59pm] <kpreid> by (in normal E) generating, storing, and returning a new swiss number (+ other info) for it
[7:01pm] <amiller> is that makeURI?
[7:01pm] <kpreid> I think some e programs define a utility for it called makeURI, yes, but ordinarily it's split into two pieces, called makeSturdyRef and sturdyToURI
[7:02pm] <amiller> ahhh so makeSturdyRef probably should require a public key
[7:03pm] <amiller> and it creates a new entry in our table
[7:03pm] <kpreid> yes, exactly
[7:03pm] <amiller> so we have an authenticated datastructure that holds all the sturdyrefs
[7:04pm] <amiller> okay so there is there a way to destroy a sturdyref
[7:04pm] <kpreid> yes. in a regular vat, since the corresponding structure holds the swiss numbers for all of the exported objects, it's a critical secret
[7:04pm] <kpreid> an object can be deregistered from that table at any time
[7:09pm] <amiller> okay so if i create a sturdyRef for white's first move in the chess game, then the move message itself must be signed according to that public key
[7:10pm] <amiller> on the other hand, if i create a sturdyRef for a function that returns the move cap
[7:10pm] <amiller> then i can sign a message to that function, attenuate it, then create a new sturdyref for that wrapper
[7:11pm] <kpreid> didn't follow those steps, sorry. Are you asking about setting up an attenuation of the move cap?
[7:12pm] <amiller> i want to attenuate the move cap, but also delegate it to some other public key
[7:13pm] <kpreid> ah, so you would send a message into the public vat saying makeSturdyRef(attenuator, delegateeKey)
[7:13pm] <kpreid> and the attenuator gets unserialized into the attenuation wrapper which is publicly observable
[7:14pm] <amiller> but suppose the game began with makeSturdyRef(whites_first_move, alicepubkey)
[7:14pm] <amiller> how does alice attenuate whites_first_move
[7:15pm] <kpreid> basically for these purposes you want makeSturdyRef to be available implicitly when delivering a message to whites_first_move
[7:15pm] <amiller> makeSturdyRef-with-pubkeys will only check the signature on invocations to whites_first_move?
[7:15pm] <kpreid> there is an E builtin method which is "call yourself with the provided function", which is how you bootstrap doing stuff on the target vat
[7:15pm] <kpreid> er, "call the provided function, supplying yourself"
[7:16pm] <kpreid> (the yourself arg isn't even necessary for high-level purposes)
[7:17pm] <amiller> when would the signature be verified
[7:17pm] <kpreid> The signature of what?
[7:18pm] <amiller> of the message sent to whites_first_move
[7:18pm] <kpreid> it would be verified as part of receiving the message
[7:18pm] <kpreid> this seems obvious, so I wonder if I'm missing something
[7:18pm] <kpreid> (verified by the comm system, not the whites_first_move object)
[7:19pm] <amiller> the signature needs to be validated at some point earlier than when the message is sent
[7:19pm] <amiller> for example if alice creates an attenuated version
[7:19pm] <amiller> like only_move_a_pawn(whites_first_move)
[7:19pm] <kpreid> Alice creates an attenuated version *by sending a message*.
[7:19pm] <amiller> sending a message to whites_first_move != invoking it?
[7:20pm] <kpreid> Depends on what you mean by "invoking".
[7:20pm] <kpreid> In E, everything is an object which has methods
[7:20pm] <kpreid> a function is simply the case where there is only one ordinary method
[7:21pm] <amiller> hm, okay, so lets say that whites_first_move is an object with one method 'move()'
[7:21pm] <kpreid> But it also has the Miranda methods, otherwise it's not a well-behaved object.
[7:21pm] <amiller> now if i create an attenuation, that is a new object with a method move_a_pawn()?
[7:21pm] <amiller> did that require sending a message to whites_first_move?
[7:21pm] <kpreid> Yes, or move() if you want.
[7:21pm] <kpreid> Well.
[7:22pm] <kpreid> Within the E model, if I am Alice, I am going to create an attenuating object, and then deliver it to whites_first_move over the network (which implicitly serializes and unserializes it to do that).
[7:23pm] <kpreid> It will be defined such that when I get the object back, it doesn't serialize itself again but becomes stuck on the public vat.
[7:23pm] <kpreid> (btw for info on Miranda messages see http://wiki.erights.org/wiki/Miranda_protocol)
[7:24pm] <amiller> i don't understand what you mean by 'deliver the attenuating object to whites_first_move'
[7:24pm] <kpreid> I need to have that object exist on the public vat
[7:25pm] <kpreid> that means I send a representation of it embedded in a message to that vat — that is, to an object in that vat, and whites_first_move is the object I'm going to use, since it's what the attenuator needs to have a reference to anyway.
[7:26pm] <amiller> what kind of message is it that you send to whites_first_move in the public vat?
[7:27pm] <amiller> surely not a move() message? i'm thinking of messages as 'invocations of a method'
[7:27pm] <kpreid> Yes, but of a Miranda method in this case; specifically __whenMoreResolved (the name refers to something other than what we're using it for here)
[7:44pm] <amiller> i can't figure out how to use a __whenMoreResolved, can you give an example
[7:44pm] <kpreid> ? "are we live?"
[7:44pm] <eel2> ? "are we live?"
[7:44pm] <eel2> # value: "are we live?"
[7:44pm] <kpreid> ok...
[7:45pm] <kpreid> ? var boardState := ""
[7:45pm] <eel2> ? var boardState := ""
[7:45pm] <eel2> # value: ""
[7:45pm] <kpreid> ? def whitesMove(move) { boardState := move }
[7:45pm] <eel2> ? def whitesMove(move) { boardState := move }
[7:45pm] <eel2> # value: <whitesMove>
[7:45pm] <kpreid> ? whitesMove("example")
[7:45pm] <eel2> ? whitesMove("example")
[7:45pm] <kpreid> ? boardState
[7:45pm] <eel2> ? boardState
[7:46pm] <eel2> # value: "example"
[7:46pm] <kpreid> ? def makeAttenuator(inner) { return def attenuator(move) { inner("pawn " + move) } }
[7:46pm] <eel2> ? def makeAttenuator(inner) { return def attenuator(move) { inner("pawn " + move) } }
[7:46pm] <eel2> # value: <makeAttenuator>
[7:47pm] <kpreid> (obviously this is all going on in one vat)
[7:47pm] <kpreid> ? def attwhite := whitesMove <- __whenMoreResolved(makeAttenuator)
[7:47pm] <eel2> ? def attwhite := whitesMove <- __whenMoreResolved(makeAttenuator)
[7:47pm] <eel2> # value: <Promise>
[7:47pm] <kpreid> ? attwhite
[7:47pm] <eel2> ? attwhite
[7:47pm] <kpreid> oh, right, no retval from that
[7:49pm] <kpreid> ? var attwhite := null; whitesMove <- __whenMoreResolved(fn _ { attwhite := makeAttenuator(inner) })
[7:49pm] <eel2> ? var attwhite := null; whitesMove <- __whenMoreResolved(fn _ { attwhite := makeAttenuator(inner) })
[7:49pm] <eel2> # problem: problem: Failed: Undefined variable: inner
[7:49pm] <kpreid> ? var attwhite := null; whitesMove <- __whenMoreResolved(fn _ { attwhite := makeAttenuator(whitesMove) })
[7:49pm] <eel2> ? var attwhite := null; whitesMove <- __whenMoreResolved(fn _ { attwhite := makeAttenuator(whitesMove) })
[7:49pm] <eel2> # value: <Promise>
[7:50pm] <kpreid> ? attwhite <- ("1")
[7:50pm] <eel2> ? attwhite <- ("1")
[7:50pm] <eel2> # value: <Promise>
[7:50pm] <kpreid> ? boardState
[7:50pm] <eel2> ? boardState
[7:50pm] <eel2> # value: "pawn 1"
[7:50pm] <kpreid> amiller: there we go
[7:51pm] <kpreid> the fn _ {...} gets delivered over the wire, invoked on the public vat's side and constructs the attenuator there
[7:52pm] <amiller> oh wow, thank you! that makes sense
[7:52pm] <kpreid> ...I was expecting considerably more explanation to be needed. Good to hear.
[7:53pm] zooko left the chat room. (Ping timeout: 244 seconds)
[7:54pm] <amiller> so all of the messages sent to whitesmove via the sturdyref will need to be signature validated
[7:54pm] <amiller> but it's okay to send it a __whenMoreResolved message
[7:54pm] <amiller> which contains the promise for the result of the attenuation function
[7:54pm] <kpreid> yep
[7:55pm] <kpreid> er, not quite
[7:55pm] <kpreid> the __whenMoreResolved message contains a function which contains a ref back to the caller to deliver the attenuation-facet back
[7:56pm] <kpreid> (in our scenario, that ref would implicitly need to involve a public key transfer)
[7:56pm] <kpreid> but one of the key E-nesses here is that we are defining our application logic in an OO/functional fashion, without worrying about the necessary crypto operations to present the abstraction
[8:00pm] <amiller> is there a syntax sugar for __whenMoreResolved perhaps
[8:00pm] <kpreid> we've tossed around ideas but haven't nailed it down
[8:00pm] <kpreid> most likely a "where" block (by analogy with "when")
[8:01pm] <kpreid> def attwhite := where (whitesMove) -> { makeAttenuator(whitesMove) }
[8:04pm] <amiller> whitesMove is there twice, but it seems like it necessarily has to be the same in both cases?
[8:04pm] <kpreid> in this application it is, but there could be more objects involved
[8:04pm] <kpreid> the where arg chooses what object you want to be the neighbor of what you're building; the body can be whatever
[8:09pm] <amiller> ? def dummy() { }
[8:09pm] <eel2> ? def dummy() { }
[8:09pm] <eel2> # value: <dummy>
[8:09pm] <amiller> ? var attwhite := null; dummy <- __whenMoreResolved(fn _ { attwhite := makeAttenuator(whitesMove) })
[8:09pm] <eel2> ? var attwhite := null; dummy <- __whenMoreResolved(fn _ { attwhite := makeAttenuator(whitesMove) })
[8:09pm] <eel2> # value: <Promise>
[8:09pm] <amiller> ? attwhite <- ("1")
[8:09pm] <eel2> ? attwhite <- ("1")
[8:10pm] <eel2> # value: <Promise>
[8:10pm] <amiller> ?boardState
[8:10pm] <eel2> ? boardState
[8:10pm] <eel2> # value: "pawn 1"
[8:10pm] <amiller> ? attwhite <- ("2")
[8:10pm] <eel2> ? attwhite <- ("2")
[8:10pm] <eel2> # value: <Promise>
[8:10pm] <amiller> ?boardState
[8:10pm] <eel2> ? boardState
[8:10pm] <eel2> # value: "pawn 2"
[8:10pm] <kpreid> btw in a real distributed system, you couldn't do _assignment_ of a variable from another vat - I did that just as a shorthand for passing a message back
[8:10pm] <amiller> it doesn't matter what object i call __whenMoreResolved? I don't understand the 'neighbor' relationship
[8:10pm] <kpreid> by neighbor I meant "in the same vat as"
[8:11pm] <kpreid> in *this* case it doesn't matter because you're writing all of the code in the same vat
[8:11pm] <amiller> well there's going to need to be some way that __whenMoreResolved is modified to verify a signature
[8:11pm] <kpreid> NO!
[8:11pm] <amiller> mm
[8:12pm] <kpreid> __whenMoreResolved is an ordinary method. It gets ordinary messages.
[8:12pm] <kpreid> Verifying signatures on _network_ messages is the job of the comm system
[8:12pm] <kpreid> (Which does not care what application we are implementing on it at all.)
[8:13pm] <amiller> suppose i have two move objects/functions though, whitesMove and blacksMove
[8:13pm] <amiller> and we have sturdyrefs with public keys for each of those
[8:14pm] <amiller> either you will need to sign some message in order to call makeAttenuator(whitesMove)
[8:14pm] <kpreid> no, makeAttenuator is local (serialized along with the rest) code, so no crypto ops
[8:15pm] <amiller> i get that the network is going to do the crypto ops, but i can't figure out what rule it will need to know which signature to check and when
[8:16pm] <kpreid> the table of sturdyrefs (they're not really sturdyrefs any more) stores what key(s) messages to a given object should be signed with
[8:16pm] <kpreid> in fact, you could make it 1:1 - the public key signing a message _designates_ what object to deliver it to
[8:16pm] <kpreid> (*IANACryptographer)
[8:17pm] <amiller> at some point there is going to be a move() message sent to whitesMove
[8:17pm] <amiller> but it's not going to be signed with the whitesMove public key
[8:17pm] <kpreid> yes, from the attwhite object living in the public vat
[8:17pm] <kpreid> it is a local, object-reference. no crypto needed
[8:18pm] <kpreid> the fact "attwhite contains a reference to whitesMove" is part of the vat's state
[8:22pm] zooko joined the chat room.
[8:23pm] nejucomo left the chat room. (Ping timeout: 245 seconds)
[8:25pm] <amiller> okay i think what happens is that a message signature gets checked when a sturdyref gets unserialized.
[8:26pm] <kpreid> a signature gets checked _when the comm system receieves a message_ before it delivers the message to the target object.
[8:26pm] <kpreid> That is, as far as I can see, the only sensible way to do it.
[8:26pm] <amiller> the comm system needs to know which pubkey to check the signature against though
[8:26pm] <amiller> it needs to do that not based on the message recipient but on the sturdyrefs it needs to have translated
[8:27pm] <kpreid> The comm system's job is to know what objects have been granted to what pubkeys.
[8:27pm] <kpreid> Sorry, explain that last claim?
[8:27pm] <amiller> objects get sent messages, but it's sturdyrefs that are going to be associated with pubkeys
[8:28pm] <kpreid> I think we should stop using the term "sturdyref", because a sturdyref is really a crypto thing that doesn't apply to this situation.
[8:28pm] <amiller> i need some endpoint to refer to
[8:28pm] <kpreid> A sturdyref is authority-to-send; the authority-to-send in this implementation is the *signing key*.
[8:29pm] <kpreid> (plus the target public-vat to contact)
[8:29pm] <amiller> there are two endpoints, there's the event where you designate a public key and then the even when the signature is checked
[8:30pm] <amiller> so we were talking about having a modified sturdyRef or makeURI that takes a publickey as a parameter
[8:30pm] <amiller> it doesn't matter what happens with the public key just that it is designated at some point
[8:30pm] <kpreid> yes...
[8:30pm] <amiller> so the question is where the other end point goes, and what i think is that it should go in the place where the sturdyRef is translated
[8:31pm] <amiller> like when the swissnum is looked up
[8:31pm] <kpreid> there is no swissnum
[8:31pm] <kpreid> we can't have swissnums in this system, because the vat state is public
[8:33pm] <kpreid> the replacement for the swissnum in the comm system state is the public key
[8:34pm] <kpreid> the replacement for the swissnum in a sturdyref is the private key
[8:36pm] <amiller> this fn _ { attwhite := makeAttenuator(whitesMove) }) that gets serialized
[8:36pm] <amiller> it doesn't get serialized with the text whitesMove
[8:36pm] <amiller> i'd have to refer to it by a remote ref of some kind right
[8:36pm] <amiller> like its public key?
[8:36pm] <kpreid> correct, we have to construct a remote ref, so we generate a key-pair for it
[8:36pm] <amiller> okay
[8:36pm] <kpreid> oh
[8:37pm] <kpreid> the situation is asymmetric
[8:37pm] <kpreid> if it were symmetric, we would make a key-pair and transmit the *private key*
[8:37pm] <kpreid> But we don't actually want a private key there, because the public vat is public
[8:38pm] <kpreid> er, wait, I'm confused, that's a different case.
[8:38pm] <kpreid> What I just started explaining is the case for "attwhite", the local variable that needs to get modified by code on the public vat
[8:38pm] <kpreid> (rather, &attwhite)
[8:38pm] <kpreid> But "whitesMove" is a different case - we are sending a reference to an object in the public vat, *to* the public vat.
[8:39pm] <kpreid> So, yes, there does need to be a signature verification independent of receiving a message, to be able to designate the object.
[8:40pm] <kpreid> That verification is still invoked within the comm system, specifically the unserialization subsystem.
[8:40pm] <amiller> i think it just needs to be done during the deserializing code
[8:40pm] <amiller> when the remote ref is dereferenced
[8:41pm] <kpreid> Yes...though at some stage it is recognized as not-a-remote-ref
[8:41pm] <kpreid> (but rather local)
[8:42pm] <amiller> that transition is exactly when the sig should be checked
[8:43pm] <amiller> so you sign your serialized code
[8:43pm] <kpreid> As part of signing the message it is a component of, yes.
[8:43pm] <amiller> ah, sure
[8:44pm] <amiller> okay and if you have multiple remoterefs with diferent pubkeys, you need a signature for each one
[8:44pm] <amiller> or if you only want to have a single signature you could always group them by redelegating them
[8:44pm] <amiller> this matches how bitcoin works btw
[8:44pm] <amiller> the transations are signed
[8:45pm] <amiller> multiple times, one for each input
[8:53pm] zooko left the chat room. (Read error: Connection reset by peer)
[8:56pm] zooko joined the chat room.
[8:59pm] * amiller git-clones e-on-cl and hopes for the best
[9:00pm] <amiller> are there any other rooms i can use to play with eel2
[9:00pm] <amiller> couldn't get private messages to work with him
[9:01pm] <kpreid> by design, there is no non-public access, but there is more obscure access
------------------------------------------------------------------------
The primary problem is: how do you preserve the capability properties for sent and received messages if there is no place to put crypto secrets?
(Incidentally, #erights has been much more active (i.e. not dead) of late, due to some migration of general capability discussion from #tahoe-lafs. Join the fun!)
------------------------------------------------------------------------
[4:04pm] <amiller> ah related but not too important, one of the things that has amused me is that in #opentransactions one of the guys trying to use the opentransactions development branch
[4:04pm] <Zarutian> amiller: a bit like Nese in Deepness of the sky
[4:04pm] <amiller> is using it for this in-game currency in this massive text-based mmorpg he maintains
[4:05pm] <amiller> it's a truly epic thing, he's worked on it for over 10 years as a pencil and paper thing, he has a large following
[4:05pm] <Zarutian> amiller: ú, ya have a link to its website?
[4:05pm] <amiller> he goes off sometimes on these stories and it takes me a while to figure out if it's in the fictional universe or it's a metaphor
[4:06pm] <Zarutian> amiller: well sometimes fiction is only made to make mega metaphors and sometimes vice versa
[4:06pm] <kpreid> opentransactions is what, a framework for bitcoinish things?
[4:06pm] <amiller> ihttp://www.devtome.org/wiki/index.php?title=Galactic_Milieu
[4:07pm] <amiller> opentransactions is very peculiar
[4:07pm] <Zarutian> kpreid: iirc it is trying to implement some of Nick Szabo ideas in bitcoin-esque system afaik
[4:07pm] <amiller> first of all it includes an implementation of chaumian blinding for cash
[4:07pm] <amiller> it uses lucre, which ben laurie wrote
[4:07pm] <amiller> so it's meant to do something right off the bat that bitcoin doesnt
[4:08pm] <amiller> on the other hand, it doesn't have any distributed component, let alone a proof-of-work-based anonymous distributed component
[4:08pm] <amiller> it's based on a heritage of systems including Loom and Truledger that use digital signatures to minimize the reliance on the server that runs the thing
[4:08pm] <amiller> but it's not a complete solution, you're still very reliant on the server, for the reason that the server is able to 'counterfeit' money
[4:08pm] <amiller> basically they don't have any double-spend solution.
[4:09pm] <amiller> they're double-spend-vulnerable to the server
[4:09pm] <Zarutian> aah, I heard about those. Dismissed them out of hand due to exacly that, lack of decentralization
[4:09pm] <amiller> well, depending on whether or not bitcoin is a valid solution to distributed anonymous agreement, something like opentransactions may be the best thing
[4:09pm] <Zarutian> but as namecoin as demonstrated, it seems to be possible to transact something else but fungible coins in blockchain based systems
[4:11pm] <amiller> the basis of any system like this is a 'consensus' component
[4:11pm] <amiller> or what i called a 'notary' in my crappy tahoe-lafs post
[4:11pm] <Zarutian> amiller: consensus of the miners?
[4:11pm] <amiller> if bitcoin is possible, then you can use the proof of work lottery as the consensus component
[4:11pm] <amiller> consensus as in Byzantine consensus, but yeah
[4:12pm] <amiller> majority vote, transaction commit, w/e
[4:12pm] <amiller> if bitcoin works, then bitcoin is the first practical 'anonymous' decentralized agreement system
[4:12pm] <amiller> if it doesn't work, you can still have any of the other kinds of distributed systems
[4:12pm] <amiller> like in ben laurie's paper about bitcoin he describes that as a network of mintettes
[4:12pm] <amiller> it's just a typical distributed system, not an anonymous-public-entry one
[4:13pm] <amiller> http://www.links.org/files/decentralised-currencies.pdf
[4:13pm] <Zarutian> amiller: well, I have been musing on how to extend something like namecoin/bitcoin so one can declare new kinds of erights that can be transacted via the blockchain
[4:13pm] <amiller> so what i want to show is that because the consensus part can be factored out,
[4:13pm] <amiller> you could do anything like namecoin or erights and just swap out the agreement component
[4:14pm] <amiller> so it can run on either a cluster of mintettes, or on a blockchain/mining network
[4:15pm] <Zarutian> I thought the main idea was that everyone checked if outstanding transactions didnt conflict with the already agreed on history of transaction which is encoded in the blockchain
[4:15pm] <amiller> well the definition of 'conflict' is extensible in bitcoin
[4:15pm] <amiller> there's a little scripting language that no one knows how to use
[4:15pm] <amiller> the model that i am using for the general case of this
[4:15pm] <Zarutian> amiller: sorry, what are mintettes? mint-ettes? somethings that mint?
[4:15pm] <amiller> is that each 'transaction' has a validation function attached to it that describes its rules
[4:15pm] <amiller> and you have to query into your history database to run the validation function
[4:16pm] <amiller> Zarutian, you should look at my example https://github.com/amiller/redblackmerkle/blob/master/toycoin.py
[4:17pm] <Zarutian> amiller: well the scripting system in bitcoin is rather small and I think it was mainly to sidestep costly updates of the client software
[4:17pm] <Zarutian> (costly in "what did the devs change now? do I bother check and continue to trust them?"
[4:17pm] <Zarutian> )
[4:17pm] <amiller> well it's just nerfed
[4:17pm] <amiller> mintettes are just nodes in a typical network
[4:18pm] <amiller> in a typical distributed system, you designate your N nodes in the network
[4:18pm] <amiller> each one gets a private key, for exmple
[4:18pm] <amiller> okay let me try saying there are three orthogonal components to any system like this
[4:19pm] <Zarutian> as meredith said in that CCC talk titled "Science of insecurity" you really do not want turing completeness in your protocols or at very least very very rarely.
[4:19pm] <amiller> a) the central agreement system, is it decentralized? single server? anonymous like bitcoin? b) is it possible to validate transactions based on public history? how easily? merkle trees are useful here. c) what application layer is there? Is it just one rule like bitcoin, or is there a scripting language for Smart Contracts?
[4:19pm] <amiller> now for my analysis:
[4:20pm] <Zarutian> amiller: one rule like bitcoin? what is that rule?
[4:21pm] <amiller> 1) a) bitcoin is an anonymous decentralized consensus system, the only one of its kind; b) bitcoin right now it is possible to validate transactions, but only if you have a copy of the entire history. with the merkle tree thing i'm suggesting, you can validate any transaction with just the root hash; c) it has a scripting language, but it's disabled.
[4:21pm] <amiller> right - one rule like bitcoin - if you ignore the script, which is effectively neutered, then there is only one kind of rule for bitcoin
[4:21pm] <amiller> the sum of the inputs must match the sum of the outputs, and the signature must match the public key in each of the inputs
[4:21pm] <amiller> (that's exactly what's in my toycoin example as well)
[4:22pm] <Zarutian> well I thought the sum of the inputs must be equal or greater than the sum of the outputs
[4:22pm] <amiller> hah, yeah you're right
[4:22pm] <amiller> the difference goes to the miners
[4:22pm] <Zarutian> otherwise how would fees work
[4:23pm] <Zarutian> exactly
[4:23pm] <amiller> 2) opentransactions a) has only a single server consensus sytem for now. b) it is not possible to validate transactions, hence the double-spend problem, it's also not meant to be fully public c) it has a full smart contracts layer
[4:24pm] <amiller> opentransactions isn't going to go full merkle tree because they'd rather have some server reliance but gain privacy
[4:24pm] <amiller> it's probably possible to get both, using homomorphic encryption, but i can't think about that too directly or i start to go nuts
[4:25pm] <amiller> i'm mostly only interested in the full public case, so that's where i basically have to diverge from opentransactions
[4:25pm] <amiller> okay so let me ask you about how to extend erights to bitcoin
[4:26pm] <amiller> the goal of course is a) fully decentralized because we use bitcoin's mining kind of thing, b) public validation should be possible, i can explain how to do that with magic trees
[4:26pm] <amiller> c) the scripting language should be as expressive as E.
[4:27pm] <amiller> er let me just wind myself out trying to explain how i think it will work
[4:27pm] <amiller> una are basically just state machines
[4:27pm] <Zarutian> hmm.. this has given me idea. What about transactions being like capcerts, only you can refer to other capcerts by hash and then the input to each can be used by the capcert to select which output the referring one wants, among other things.
[4:28pm] <amiller> lets hash this out i think we'll get there quickly since we're on the same page mostly
[4:28pm] <amiller> but i'm not sure about the E part
[4:28pm] * Zarutian is catching up
[4:28pm] <amiller> E is a single state machine, isn't it?
[4:28pm] <amiller> do instructions get executed in a deterministic order
[4:28pm] <amiller> there's conceptually a single-threaded linearized timeline
[4:29pm] <kpreid> for any single vat, yes
[4:29pm] <amiller> different vats are under no obligation to share a linearizable timeline then
[4:29pm] <Zarutian> as I recall E has vats and those are each singly threaded event-loops that handle messages from outside
[4:29pm] <kpreid> amiller: correct
[4:29pm] <Zarutian> (the stuff that arrives via the far refs)
[4:30pm] <amiller> okay so i have no idea how to think about the multiple vat case.
[4:30pm] <amiller> but i really enjoy thinking about a decentralized implementation of a single vat
[4:30pm] <amiller> each vat stores some state and contains rules for state transitions
[4:30pm] <amiller> and the point of the distributed network is to reach an agreement on a sequential execution of transitions
[4:31pm] <amiller> it's important to look at the worst-case complexity of applying one of these transitions
[4:31pm] <Zarutian> amiller: where would the linerization of the timeline happen? in the blockchain of some bitcoin-esqu protocol or at a vat or more something like Croquet-SimplifiedTeaTime-Router?
[4:32pm] <amiller> i'm thinking blockchain, i don't know about croquet teamtime router but my guess is that is an ordinary distributed agreement protocol?
[4:32pm] <kpreid> btw, I was playing with explicitly modeling E semantics in a nondeterministic state-machine-like setting earlier this year. what I found was that it's very hairy simply because E is an imperative programming language and even simple object behaviors are tough to describe logically
[4:33pm] <amiller> okay so for bitcoin, the 'state' at any given time is the total set of unspent inputs
[4:33pm] <amiller> there are a lot of those
[4:33pm] <amiller> any transaction though only touches a small number of them
[4:33pm] <amiller> each transaction contains some number of inputs, some number of outputs; the transaction modifies the state by deleting all the inputs it spends, and inserting a new entry for each output
[4:34pm] <Zarutian> amiller: that last is basicly what many RealTimeStragedy games use and is what Croquet used. Basicly everyone sends their commands they want to affect their portion of the (game)state to a central server that does nothing but recive them, put them in some ordered sequence and broadcasts the sequence as it gets added to.
[4:34pm] <amiller> using magic merkle trees, any operation that touches M cells can be verified using O(M * log N) where N is the total number in the database
[4:34pm] <amiller> so it's linear in the number of state cells you actually read/modify
[4:34pm] <amiller> but it's subpolynomial in the total size of the state
[4:34pm] <Zarutian> unspent inputs? dontcha mean unspent outputs?
[4:34pm] <amiller> sure unspent outputs
[4:34pm] <amiller> one mans output is another mans input
[4:35pm] <amiller> okay so any instruction in E
[4:35pm] <amiller> has some stateful effect on the vat
[4:35pm] <amiller> it's hopefully deterministic
[4:36pm] <amiller> which means anyone with a replica of the state, applying the same instruction/input, will get the same updated state
[4:37pm] <kpreid> yes
[4:37pm] <amiller> is that true of implementations of E? they use like a deterministic subset of java?
[4:37pm] <Zarutian> amiller: deterministic vat where replicas get the same broadcasted inputstream, which I think you just described, is pretty much what a Croquet Island is iirc.
[4:37pm] <kpreid> implementation language is irrelevant
[4:37pm] <amiller> okay
[4:37pm] <amiller> well then look this is all it comes down to
[4:37pm] <kpreid> E does not expose visibly nondeterministic things to unprivileged code
[4:37pm] <amiller> if the state is an authenticated data structure
[4:37pm] <amiller> then it's publicly validatable
[4:38pm] <amiller> because you only have to look at each transaction as it gets broadcast
[4:38pm] <amiller> you don't need to have a full copy of the state
[4:38pm] CIA-46 left the chat room. (Read error: Operation timed out)
[4:38pm] <amiller> so for namecoin, the state is just the dns lookup table, and every transaction is some sequence of modifications to the lookup table, so it's a natural fit
[4:38pm] <amiller> for bitcoin, the state is just a set of unspent-coins, each transaction is modifications to that
[4:39pm] <amiller> you could implement any register machine this way
[4:39pm] <Zarutian> (well namecoin has unspent-coins like bitcoin plus the dns/name-value mapping stuff)
[4:40pm] <amiller> maybe it's worth describing some kind of stack language or something to show that you can compile some kind of script into a sequence of actions on an authenticated data structure
[4:40pm] <amiller> or else just work out a couple other examples
[4:40pm] <amiller> like what sort of property rights behavior would you want to specify
[4:42pm] <amiller> the components of this system again are going to be a) some network of miners or mintettes or 'notaries' that decides on a linear sequence of transactions, b) the 'public' who follows along with each transaction but only keeps root hashes around, acting as verifiers c) the users whoever they are that make transactions
[4:43pm] <Zarutian> amiller: hmm.. iirc namecoin allows one to subdivide the namespace one has registered a TLD for as DNS and hand out control of submappings as one sees fit. So, I wonder if one can hand out transactions (possibly conflicting ones) that do nothing but bind such a name to value A for one transaction or bind value B to the name.
[4:44pm] <amiller> ah okay so let me try to describe this state machine as a general purpose cap checker
[4:44pm] <amiller> possessing a cap is always about having the matching private key to some public key
[4:44pm] <Zarutian> (similiar on how one can serialize an unpublished btc transaction into an btc uri and encode as QR code and so on)
[4:44pm] <amiller> so when you give someone a cap, you write their public key into the state somehow
[4:45pm] <amiller> ah that's cool, that breaks my model a bit
[4:45pm] <amiller> since you can designate a public key
[4:45pm] <amiller> but give someone only a particular transaction
[4:45pm] <amiller> then they don't have hte private key / original cap, but they have an attenuated cap
[4:45pm] <amiller> i don't know how to describe that generally.
[4:46pm] <amiller> but that's the sort of thing you want to do with the authenticated data structure
[4:46pm] <amiller> it's just a big access control list
[4:46pm] <Zarutian> amiller: sound similiar on what MarkM was going on in his email list series on capcerts which I tried to condense into a wiki page and give it name: (active) capcerts.
[4:46pm] * amiller looks into it
[4:46pm] <amiller> the wiki page http://wiki.erights.org/wiki/Capability-based_Active_Invocation_Certificates
[4:47pm] <Zarutian> yes,
[4:48pm] <amiller> "We are unaware of any theory of composable auditability" i think that is a gap that is filled in by merkletreez
[4:48pm] <amiller> you're right this is exactly what i want!
[4:48pm] <Zarutian> though I was thinking about that as a way for vats to dynamicly attenuate and or construct ?control datastructures?
[4:49pm] <amiller> ah what's a good example pattern
[4:49pm] <amiller> at this point i normally start thinking about a chess game
[4:49pm] <amiller> and i'm still certain that's the right sort of way to think of it (i got the idea from a markm page) but it usually just confuses people when i try to explain it
[4:50pm] <Zarutian> lets say you want to give someone the capability of moving a pawn forward in a chess game hosted by a vat
[4:50pm] <amiller> perfect, go on
[4:50pm] <Zarutian> but you want to attenuate it so they can only do it before move nr 25 or some such
[4:52pm] <amiller> initially, 'you' have the capability of making any move?
[4:52pm] <amiller> or only the next move?
[4:52pm] <Zarutian> only that you are on a holiday where the price of Internet connection is so high or inconvient that you want to send your friend that cap via a postcard
[4:52pm] <Zarutian> amiller: I imagine that I would have a set of capabilities to instruct the pieces of my colour to do allowed moves
[4:53pm] * Zarutian coninues
[4:53pm] <Zarutian> but you are in luck as you know the public key of his vat.
[4:55pm] <Zarutian> so you make a chit which explains, in E code, what capability you are reffering to, the code that instanciates the attenuation and the public key of the friends vat and signs it with your vat private key.
[4:55pm] <Zarutian> (the vat you use to direct the moves in that chess game)
[4:55pm] <amiller> ohhhhh yeah. it's attenuation through function closures, basically
[4:56pm] <Zarutian> then your friend presents aforesaid chit to the chess game hosting vat
[4:57pm] <Zarutian> and gets that attenuated capability
[5:00pm] * warner has been thinking about this stuff a bunch recently
[5:00pm] <warner> I keep playing around with different ways of connecting the attenuating functions
[5:01pm] <warner> there's stack-based languages, schemes where you pass one function to another (and it invokes the second function with less-powerful arguments than the first one received), schemes where you run each function in an environment that was set up for it by the previous function, etc
[5:02pm] CIA-100 joined the chat room.
[5:02pm] <Zarutian> well, that is the rough idea
[5:04pm] <amiller> warner, do they all turn out to be equivalent?
[5:05pm] <warner> I think so. I think they'll have different ease-of-programming feels, though
[5:05pm] <warner> I have to actually build a couple to compare them properly, though
[5:05pm] <Zarutian> the implementation, yet to be realized, is basicly that each capcert describes the body of an unary function that only gets a enviroment which is safeEnv augmented by a unsealer for the issuer of the capcert and (lazyly initialized) registry of sealers indexed by keyid/fingerprints of other issuers.
[5:06pm] <Zarutian> and that function is given to whoever/whatever presented the capcert
[5:06pm] <amiller> back to the chess example
[5:06pm] <amiller> in a way, at the beginning, we have a pair of mutual capabilities to play any chess game
[5:07pm] <amiller> but as we make moves, we attenuate the ways of finishing the game
[5:07pm] <amiller> eventually we've played one single chess game
[5:07pm] <amiller> we could just pass signed move transactions to each other out of band and then play the whole game in one commit
[5:07pm] <Zarutian> "whittled down the possibilities" is a phrase that comes to mind
[5:07pm] <amiller> or we can play each move on the table
[5:08pm] <amiller> maybe it doesn't matter which
[5:08pm] <amiller> suppose i have the cap of playing my opening move
[5:08pm] <Zarutian> passing signed move transaction to each other is exactly how mail-chess works afaiu
[5:08pm] <amiller> but i want to partially play it
[5:08pm] <amiller> i want to commit to moving one of my panws
[5:08pm] <amiller> but i don't yet specify which - that's where my intent may be to designate someone to have that attenuated ability
[5:09pm] <amiller> but just like before i can either just give him the ability to play both steps at once, or i can do the first one
[5:09pm] <amiller> to play partial moves like that, then the state would have to include some attenuation mechanism, a transaction isn't just a chess move, but a partial chess move sometimes
[5:09pm] <amiller> the next person definitely can't move until i've played a complete move
[5:09pm] <amiller> then again maybe they can!
[5:10pm] <amiller> what if i say that i'm only going to move a pawn on my second move
[5:10pm] <amiller> can i enter that into the state before i even make my first move
[5:10pm] <Zarutian> amiller: the attenuation mechanism is what E can express iirc.
[5:11pm] <Zarutian> amiller: depends if your set of capabilties have to be renewed every move somehow or not.
[5:11pm] <amiller> can i express either case in E?
[5:11pm] <Zarutian> lesse see
[5:15pm] <Zarutian> yes, as your move-piece-capabilities could have been attenuated with caretakers beforehand and you put in an ?thunk? which gets executed on second move before you get to decide on that turn and another thunk after. The former thunk tells the caretakers of all other pieces than your pawns to not allow through messages while the latter tells those caretakers to re-enable.
[5:17pm] <Zarutian> (that depends of course that there is a mini-cron like factility that runs such thunks implemented in the chess game support code)
[5:18pm] <amiller> is there a canonical example of chess implemented in E
[5:18pm] <amiller> or something similar
[5:19pm] <amiller> where players alternately receive caps for their turns
[5:19pm] <amiller> does it really require a cron? i wouldn't think so
[5:20pm] <kpreid> amiller: there's a "racetrack" game in the EoJ dist where players submit moves for their cars, but I forget what other point it was meant to illustrate
[5:20pm] <Zarutian> or barring that mini-cron not existing you could give your opponent a capcert that does that second move attenuation, sets a flag. Then you have your capcert that reenables if that flag is set.
[5:20pm] <Zarutian> kpreid: promise pipelining, eventual send and far references iirc
[5:21pm] <amiller> is there a single essential primitive for E? like makeBrandPair?
[5:21pm] <amiller> from which you can construct all the rest of it
[5:22pm] <kpreid> no, and makeBrandPair isn't a primitive
[5:22pm] <kpreid> the core of E is lambda calculus + assignment + turns/queued messages
[5:23pm] <kpreid> well, you could build the last
[5:29pm] <amiller> hmm, so for me to attenuate my own capability, e.g. for me to commit to moving one of my pawns but saving the decision of which one for later,
[5:29pm] <amiller> i would need to interact with some agent who held a higher cap?
[5:30pm] <amiller> if all i have is a capability to move on of my pieces on this turn, there's no way i can send a message to the vat that actually attenuates my own cap by partially constraining it
[5:30pm] <dash> amiller: what do you mean by "higher"?
[5:30pm] <kpreid> "commit to" is not well-defined in E since state is private
[5:30pm] <davidsarah> arggh...
[5:31pm] <kpreid> but you are talking about a public-state vat which changes things
[5:31pm] * davidsarah really wants to participate but has to do work
[5:31pm] <kpreid> Oh, wait, it works even in a simpler model.
[5:31pm] <kpreid> Let's imagine for a moment that the game is managed by a normal E vat and I'm another E vat
[5:31pm] <davidsarah> such as a functional process model like Erlang, for example
[5:32pm] * davidsarah goes back to doing what they should be doing
[5:33pm] <kpreid> I want to commit to "move a pawn". I write a facet (i.e. a wrapper object) which passes on only "move a pawn" messages, and I *transfer that object to the public vat*. I drop my reference to my "make any move" capability.
[5:33pm] <kpreid> Hm, but if you replace CapTP with a cryptocap system my dropping the reference is unobservable.
[5:34pm] * Zarutian raises hand: how can you assure anyone that you have indeed dropped that "make any move" cap?
[5:34pm] <amiller> mm
[5:34pm] <kpreid> Well, it just needs to be a cap system which includes a "revoke this capability" operation.
[5:34pm] <amiller> quite.
[5:34pm] <kpreid> (this implies for shareability to have a "clone-wrt-revocation" operation as well ,but that's OK)
[5:34pm] <Zarutian> kpreid: pretty much all caps would be caretaken then?
[5:35pm] <kpreid> Think of it less like a caretaker and more like dropping an entry from the swiss table
[5:35pm] <Zarutian> kpreid: aah, okay.
[5:36pm] <kpreid> But anyway, the point is that I can deliver a move-restrictor *to* the public system and so make it public.
[5:36pm] <kpreid> (On the other hand, this implies I can DoS the public system.)
[5:36pm] <amiller> lets assume you can pay for your resource
[5:36pm] <amiller> if it just comes down to state
[5:36pm] <amiller> or swissnum entries
[5:36pm] * Zarutian attempts to bribe davidsarah with a bitcoin to take part for few minutes
[5:38pm] <amiller> bitcoin afterall is basically just a usage token, you have place at least one satoshi down as a rental deposit on every bitcoin output you create
[5:38pm] <amiller> so delivering a move restrictor is creating a new object in the public vat
[5:38pm] <amiller> there's a new reference added (a new swissnum?)
[5:38pm] <kpreid> yes
[5:38pm] <amiller> oh, and if the old one is revoked, then it's a replacement
[5:38pm] <Zarutian> yes, to last (if I understand where kpreid is going with this)
[5:39pm] <Zarutian> (creating new restrictor in the public vat that is)
[5:42pm] <amiller> when i actually make a complete move, i'm also creating a new object to represent my opponents next move
[5:42pm] <kpreid> well, the game managing public vat should contain the code for that
[5:43pm] <amiller> well someone initializes the game
[5:43pm] <amiller> designates the two players by their public keys
[5:50pm] <amiller> where are the public keys in E?
[5:50pm] <amiller> vats?
[5:51pm] <amiller> if alice and bob are playing chess are alice and bob each identified by their vat, that could make sense to me but i think i'm wrong
[5:51pm] <dash> only trust makes distinctions
[5:52pm] <kpreid> amiller: in standard E a vat is id'd by a public key (used to authenticate the vat when contacting it)
[5:52pm] <kpreid> + one swissnum for each persistently accessible object
[5:52pm] <warner> hm, what if you could publish a revokecap that *anyone* could exercise?
[5:53pm] <warner> something where anybody else could present it to the public system and get confirmation that it really does revoke the authority that you claimed
[5:56pm] <amiller> kpreid, so what does it mean that in your game example above, one of the players was another E vat
[5:56pm] <kpreid> not actually necessary
[5:56pm] <kpreid> just that the communication to the public vat is over something sufficiently captp-like for my model to hold
[5:57pm] <amiller> how can i delegate a cap in E publicly, by designating their public key?
[5:59pm] <kpreid> there is no "public" in E so as soon as you do that you're creating new things, so that depends on your design of extension
[5:59pm] <amiller> mm
[5:59pm] <amiller> ok then maybe that's the essential thing you need to represent bitcoin in E...
[6:01pm] <amiller> maybe you just need one requireSignature(f, pubkey) function?
[6:01pm] welterde left the chat room. (Ping timeout: 264 seconds)
[6:02pm] <amiller> that seems clumsy, since i don't know where the pubkeys come from
[6:05pm] <amiller> in tahoe-lafs, a verify cap is a public key, and the write-cap is the matching signing key
[6:05pm] <amiller> so if i designate someones pubkey to execute some function, then they _have_ that capability even if i don't communicate anything to them
[6:06pm] <kpreid> since vats are the reliance units it's entirely reasonable to add facilities by which an object can have its vat sign something (with some kind of add'l note identifying the object)
[6:06pm] <kpreid> or similar operations
[6:07pm] <amiller> ah okay so here's where the rubber hits the fan
[6:08pm] <amiller> if someone's access to a cap is constrained by public key, how do they do one of those partial execution / attenuations
[6:08pm] <amiller> then can't send the public vat a function that signs a message for them!
[6:08pm] <amiller> they can't*
[6:09pm] <kpreid> the defined-by-public-key capability would have to be *to the move-restrictor they wrote*.
[6:09pm] <amiller> right but the move restrictor would have to support further delegation
[6:09pm] <amiller> the simplest implementation of defined-by-public-key would require the actual message to be signed by the delegatee
[6:09pm] <amiller> but that's not good enough because you can't keep redelegating publicly
[6:10pm] <amiller> i mean you could wrap your private key up in a closure and send it to the public vat
[6:10pm] <kpreid> the move-restrictor holds a *local* reference to the make-a-move cap
[6:10pm] <kpreid> so there is no signing needed
[6:12pm] welterde joined the chat room.
[6:20pm] <amiller> i'm going in a bit of a loop trying to understand current E and the capcert active invocation scheme
[6:21pm] <kpreid> I can't help you there, I only know of capcert as that thing that Zarutian rambles about
[6:21pm] * kpreid is a ocap guy, not a crypto guy, and lets that statement identity get to his head too much
[6:21pm] <amiller> Use signing key pairs to represent object identity, where the (public) signature verification key designates the object and the (secret) signing key represents the permission to be the object.
[6:21pm] <amiller> Zarutian, maybe you can help me close this gap then
[6:22pm] <amiller> i understand how to do a thing in E now, but i understand how i need to introduce a public key somewhere, and capcert does that but i don't understand where the key comes in
[6:22pm] <amiller> the public key is associated with an object?
[6:23pm] <amiller> when i create an instance of a chess game, do i create two player objects, one for alice and one for bob, each identified by a public key?
[6:23pm] <amiller> their transactions are signed messages to their respective 'player' objects in the public vat
[6:25pm] <Zarutian> amiller: the public key is associated with a vat
[6:26pm] <Zarutian> (it is going to be the same one as captp uses once I figgure out how to extract/use it)
[6:27pm] <amiller> what has to change for there to be a public-vat then
[6:28pm] <Zarutian> as I understand it a vat is something that runs somewhere and not just inert data
[6:29pm] <Zarutian> what you probably want is an unum with public state.
[6:30pm] <amiller> what would capcert look like if it ran on one of those?
[6:30pm] <Zarutian> on unum or vat?
[6:30pm] <kpreid> Zarutian: we're trying to make a public unum which *implements a vat*
[6:30pm] <Zarutian> oh, I see
[6:32pm] <amiller> public keys and signatures have to be involved, they have to be threaded along with the function calls somehow, it's just not clear yet how to bind it all up
[6:33pm] <amiller> it's no good to have every message signed
[6:34pm] <amiller> because if i create a new capability and reference that someone else can invoke, and it sends a message, that message needs to carry the weight of my original signature when the cap was defined
[6:34pm] <amiller> i don't have to sign the actual message that gets sent.
[6:34pm] <amiller> that's the first major difference between what's needed here and what capcert does
[6:35pm] <Zarutian> hmm... the only way I can think of at the moment is that the unum creator includes his public key in the initialization code then sends a signed message desginating the public keys of the players.
[6:35pm] <kpreid> amiller: I think you missed my point
[6:35pm] warner left the chat room. (Quit: yay meetings)
[6:35pm] <kpreid> amiller: when I create a new capability, I give its implementation to the public vat; this means that it uses an intra-vat, not crypto, reference
[6:36pm] <kpreid> uses an intra-vat reference to the previously existing capability, I mean
[6:36pm] <Zarutian> (to anyone replicating the vat (in effect publishing the message)
[6:37pm] <Zarutian> )
[6:38pm] <Zarutian> kpreid: so each player has in the public vat an evaluator than evals any code signed by that player?
[6:39pm] <kpreid> that's just standard E mobile code, not a feature for this, but yes.
[6:39pm] <Zarutian> so, the evaluator of each player represents that player inside the public-vat unum?
[6:42pm] <amiller> messages to those evaluators must be signed then, but those are the only kind of messages that need to be signed
[6:42pm] <kpreid> the evaluator is not a special case
[6:42pm] <kpreid> it's just one of the things that you can get access to during unserialization in a vat
[6:43pm] <Zarutian> given a starting state, signed by a public-vat unum creator(s), and the history of signed messages to the evaluators (or avatar objects) inside that unum you can do this?
[6:44pm] <Zarutian> (this being what ever amiller is after)
[6:46pm] <kpreid> I'm assuming the premise that we can define a public Turing-complete system in which we can implement an evaluator, yes.
[6:46pm] <amiller> turing-complete isn't necessary if we can pick anything else
[6:47pm] <amiller> the calculus-of-inductive-constructions that Coq is based on is sub-turing
[6:47pm] <amiller> always terminates in polynomial time in the length of the code
[6:47pm] <amiller> i don't think that aspect matters really
[6:47pm] <kpreid> sure, refinements
[6:47pm] <amiller> i don't understand this history of signed messages though
[6:47pm] <amiller> messages are signed?
[6:47pm] <amiller> oh right the messages are always signed between vats
[6:48pm] <amiller> it's just they're not always thought of as a history log i suppose
[6:48pm] <kpreid> in Pluribus (standard E comm stack), connections are authenticated using a key pair, but messages on the connection are not signed
[6:48pm] <Zarutian> amiller: each message from outside the public-vat unum that are meant to change the public state rather than merely the state of your local copy is signed.
[6:48pm] <kpreid> what a public vat needs, well, you're working that out
[6:49pm] <Zarutian> (similiar how you can keep a chess board updated based on reports heard on the radio of a chess tournament)
[6:50pm] <amiller> okay i think i follow that
[6:50pm] <amiller> alright so this avatar/evaluator and vats
[6:50pm] <amiller> a public key represents an external vat, say Alice's vat
[6:50pm] <amiller> so when i create this chess game for alice and bob, do i create player objects for each of Alice and Bob? do those objects live on the public vat or on their respective vats
[6:50pm] <kpreid> I reject the avatar notion.
[6:51pm] <amiller> Alice is white, how do I say that the first move needs to come from alice
[6:51pm] <kpreid> as I said, the evaluator is just *one of the facilities available* when unserializing messages
[6:51pm] <kpreid> there are no "player objects" on the public vat
[6:51pm] <amiller> well, some facility needs to get enhanced with a public key and a signature validation.
[6:51pm] <amiller> we're just trying to figure out which one
[6:51pm] <amiller> i think only one is necessary if we pick correctly
[6:51pm] <kpreid> there is facet-for-use-by-Alice and facet-for-use-by-Bob
[6:51pm] <kpreid> these receive move messages
[6:51pm] <Zarutian> kpreid: how else are you going to keep what Alice can do seperate from what Bob or anyone can do? the public-vat unum cant hold secrets
[6:52pm] <kpreid> signatures are needed to authorize messages, yes
[6:53pm] <Zarutian> kpreid: okay you could have facets in the public-vat unum that check if the message they recived is signed by this or that key.
[6:53pm] <kpreid> no, the signatures should properly be part of the comm layer
[6:53pm] <amiller> kpreid, in your view, where do you put the public keys?
[6:53pm] <kpreid> the part which decides *that* the facet is to receive a message
[6:53pm] <kpreid> amiller: in the comm subsystem of the public vat
[6:54pm] <amiller> i mean who desginates a public key, and when?
[6:54pm] <kpreid> the comm system is the translator between the network/crypto world and the ocap world
[6:54pm] <amiller> i need to be able to do something like say here's a new capability and it requires signatures matching <pubkey>
[6:54pm] <kpreid> in an ordinary E system, you tell the comm system to publish a cap, and thus get back a cryptocap for it
[6:54pm] <kpreid> in this one, you would provide a cap and a pubkey instead
[6:54pm] <Zarutian> kpreid: so the facet is outside the public-vat unum but inside the comm system. Does the public-vat unum serialization have anyway to specify that a facet can only recive messages signed by the desgined private key?
[6:55pm] <kpreid> No, *this* comm system is part of the public-vat-which-is-an-unum
[6:55pm] <kpreid> that is, it's part of the state which is maintained/verified distributedly
[6:55pm] <Zarutian> aah, I see
[6:56pm] <Zarutian> that was what I was trying to get at
[6:57pm] <Zarutian> so the serialized depiction of a public-vat unum contains the state accessible to code inside the unum and state supporting that code and state?
[6:57pm] <kpreid> yes
[6:58pm] <Zarutian> I was confusing the picture of the pipe with the picture of the picture of the pipe, so to speak
[6:58pm] <amiller> this publish-a-cap, i don't understand
[6:58pm] <amiller> what function is that?
[6:59pm] <kpreid> it takes a local object, i.e. one that has only intra-vat references, and makes it possible to refer to it outside the vat
[6:59pm] <kpreid> by (in normal E) generating, storing, and returning a new swiss number (+ other info) for it
[7:01pm] <amiller> is that makeURI?
[7:01pm] <kpreid> I think some e programs define a utility for it called makeURI, yes, but ordinarily it's split into two pieces, called makeSturdyRef and sturdyToURI
[7:02pm] <amiller> ahhh so makeSturdyRef probably should require a public key
[7:03pm] <amiller> and it creates a new entry in our table
[7:03pm] <kpreid> yes, exactly
[7:03pm] <amiller> so we have an authenticated datastructure that holds all the sturdyrefs
[7:04pm] <amiller> okay so there is there a way to destroy a sturdyref
[7:04pm] <kpreid> yes. in a regular vat, since the corresponding structure holds the swiss numbers for all of the exported objects, it's a critical secret
[7:04pm] <kpreid> an object can be deregistered from that table at any time
[7:09pm] <amiller> okay so if i create a sturdyRef for white's first move in the chess game, then the move message itself must be signed according to that public key
[7:10pm] <amiller> on the other hand, if i create a sturdyRef for a function that returns the move cap
[7:10pm] <amiller> then i can sign a message to that function, attenuate it, then create a new sturdyref for that wrapper
[7:11pm] <kpreid> didn't follow those steps, sorry. Are you asking about setting up an attenuation of the move cap?
[7:12pm] <amiller> i want to attenuate the move cap, but also delegate it to some other public key
[7:13pm] <kpreid> ah, so you would send a message into the public vat saying makeSturdyRef(attenuator, delegateeKey)
[7:13pm] <kpreid> and the attenuator gets unserialized into the attenuation wrapper which is publicly observable
[7:14pm] <amiller> but suppose the game began with makeSturdyRef(whites_first_move, alicepubkey)
[7:14pm] <amiller> how does alice attenuate whites_first_move
[7:15pm] <kpreid> basically for these purposes you want makeSturdyRef to be available implicitly when delivering a message to whites_first_move
[7:15pm] <amiller> makeSturdyRef-with-pubkeys will only check the signature on invocations to whites_first_move?
[7:15pm] <kpreid> there is an E builtin method which is "call yourself with the provided function", which is how you bootstrap doing stuff on the target vat
[7:15pm] <kpreid> er, "call the provided function, supplying yourself"
[7:16pm] <kpreid> (the yourself arg isn't even necessary for high-level purposes)
[7:17pm] <amiller> when would the signature be verified
[7:17pm] <kpreid> The signature of what?
[7:18pm] <amiller> of the message sent to whites_first_move
[7:18pm] <kpreid> it would be verified as part of receiving the message
[7:18pm] <kpreid> this seems obvious, so I wonder if I'm missing something
[7:18pm] <kpreid> (verified by the comm system, not the whites_first_move object)
[7:19pm] <amiller> the signature needs to be validated at some point earlier than when the message is sent
[7:19pm] <amiller> for example if alice creates an attenuated version
[7:19pm] <amiller> like only_move_a_pawn(whites_first_move)
[7:19pm] <kpreid> Alice creates an attenuated version *by sending a message*.
[7:19pm] <amiller> sending a message to whites_first_move != invoking it?
[7:20pm] <kpreid> Depends on what you mean by "invoking".
[7:20pm] <kpreid> In E, everything is an object which has methods
[7:20pm] <kpreid> a function is simply the case where there is only one ordinary method
[7:21pm] <amiller> hm, okay, so lets say that whites_first_move is an object with one method 'move()'
[7:21pm] <kpreid> But it also has the Miranda methods, otherwise it's not a well-behaved object.
[7:21pm] <amiller> now if i create an attenuation, that is a new object with a method move_a_pawn()?
[7:21pm] <amiller> did that require sending a message to whites_first_move?
[7:21pm] <kpreid> Yes, or move() if you want.
[7:21pm] <kpreid> Well.
[7:22pm] <kpreid> Within the E model, if I am Alice, I am going to create an attenuating object, and then deliver it to whites_first_move over the network (which implicitly serializes and unserializes it to do that).
[7:23pm] <kpreid> It will be defined such that when I get the object back, it doesn't serialize itself again but becomes stuck on the public vat.
[7:23pm] <kpreid> (btw for info on Miranda messages see http://wiki.erights.org/wiki/Miranda_protocol)
[7:24pm] <amiller> i don't understand what you mean by 'deliver the attenuating object to whites_first_move'
[7:24pm] <kpreid> I need to have that object exist on the public vat
[7:25pm] <kpreid> that means I send a representation of it embedded in a message to that vat — that is, to an object in that vat, and whites_first_move is the object I'm going to use, since it's what the attenuator needs to have a reference to anyway.
[7:26pm] <amiller> what kind of message is it that you send to whites_first_move in the public vat?
[7:27pm] <amiller> surely not a move() message? i'm thinking of messages as 'invocations of a method'
[7:27pm] <kpreid> Yes, but of a Miranda method in this case; specifically __whenMoreResolved (the name refers to something other than what we're using it for here)
[7:44pm] <amiller> i can't figure out how to use a __whenMoreResolved, can you give an example
[7:44pm] <kpreid> ? "are we live?"
[7:44pm] <eel2> ? "are we live?"
[7:44pm] <eel2> # value: "are we live?"
[7:44pm] <kpreid> ok...
[7:45pm] <kpreid> ? var boardState := ""
[7:45pm] <eel2> ? var boardState := ""
[7:45pm] <eel2> # value: ""
[7:45pm] <kpreid> ? def whitesMove(move) { boardState := move }
[7:45pm] <eel2> ? def whitesMove(move) { boardState := move }
[7:45pm] <eel2> # value: <whitesMove>
[7:45pm] <kpreid> ? whitesMove("example")
[7:45pm] <eel2> ? whitesMove("example")
[7:45pm] <kpreid> ? boardState
[7:45pm] <eel2> ? boardState
[7:46pm] <eel2> # value: "example"
[7:46pm] <kpreid> ? def makeAttenuator(inner) { return def attenuator(move) { inner("pawn " + move) } }
[7:46pm] <eel2> ? def makeAttenuator(inner) { return def attenuator(move) { inner("pawn " + move) } }
[7:46pm] <eel2> # value: <makeAttenuator>
[7:47pm] <kpreid> (obviously this is all going on in one vat)
[7:47pm] <kpreid> ? def attwhite := whitesMove <- __whenMoreResolved(makeAttenuator)
[7:47pm] <eel2> ? def attwhite := whitesMove <- __whenMoreResolved(makeAttenuator)
[7:47pm] <eel2> # value: <Promise>
[7:47pm] <kpreid> ? attwhite
[7:47pm] <eel2> ? attwhite
[7:47pm] <kpreid> oh, right, no retval from that
[7:49pm] <kpreid> ? var attwhite := null; whitesMove <- __whenMoreResolved(fn _ { attwhite := makeAttenuator(inner) })
[7:49pm] <eel2> ? var attwhite := null; whitesMove <- __whenMoreResolved(fn _ { attwhite := makeAttenuator(inner) })
[7:49pm] <eel2> # problem: problem: Failed: Undefined variable: inner
[7:49pm] <kpreid> ? var attwhite := null; whitesMove <- __whenMoreResolved(fn _ { attwhite := makeAttenuator(whitesMove) })
[7:49pm] <eel2> ? var attwhite := null; whitesMove <- __whenMoreResolved(fn _ { attwhite := makeAttenuator(whitesMove) })
[7:49pm] <eel2> # value: <Promise>
[7:50pm] <kpreid> ? attwhite <- ("1")
[7:50pm] <eel2> ? attwhite <- ("1")
[7:50pm] <eel2> # value: <Promise>
[7:50pm] <kpreid> ? boardState
[7:50pm] <eel2> ? boardState
[7:50pm] <eel2> # value: "pawn 1"
[7:50pm] <kpreid> amiller: there we go
[7:51pm] <kpreid> the fn _ {...} gets delivered over the wire, invoked on the public vat's side and constructs the attenuator there
[7:52pm] <amiller> oh wow, thank you! that makes sense
[7:52pm] <kpreid> ...I was expecting considerably more explanation to be needed. Good to hear.
[7:53pm] zooko left the chat room. (Ping timeout: 244 seconds)
[7:54pm] <amiller> so all of the messages sent to whitesmove via the sturdyref will need to be signature validated
[7:54pm] <amiller> but it's okay to send it a __whenMoreResolved message
[7:54pm] <amiller> which contains the promise for the result of the attenuation function
[7:54pm] <kpreid> yep
[7:55pm] <kpreid> er, not quite
[7:55pm] <kpreid> the __whenMoreResolved message contains a function which contains a ref back to the caller to deliver the attenuation-facet back
[7:56pm] <kpreid> (in our scenario, that ref would implicitly need to involve a public key transfer)
[7:56pm] <kpreid> but one of the key E-nesses here is that we are defining our application logic in an OO/functional fashion, without worrying about the necessary crypto operations to present the abstraction
[8:00pm] <amiller> is there a syntax sugar for __whenMoreResolved perhaps
[8:00pm] <kpreid> we've tossed around ideas but haven't nailed it down
[8:00pm] <kpreid> most likely a "where" block (by analogy with "when")
[8:01pm] <kpreid> def attwhite := where (whitesMove) -> { makeAttenuator(whitesMove) }
[8:04pm] <amiller> whitesMove is there twice, but it seems like it necessarily has to be the same in both cases?
[8:04pm] <kpreid> in this application it is, but there could be more objects involved
[8:04pm] <kpreid> the where arg chooses what object you want to be the neighbor of what you're building; the body can be whatever
[8:09pm] <amiller> ? def dummy() { }
[8:09pm] <eel2> ? def dummy() { }
[8:09pm] <eel2> # value: <dummy>
[8:09pm] <amiller> ? var attwhite := null; dummy <- __whenMoreResolved(fn _ { attwhite := makeAttenuator(whitesMove) })
[8:09pm] <eel2> ? var attwhite := null; dummy <- __whenMoreResolved(fn _ { attwhite := makeAttenuator(whitesMove) })
[8:09pm] <eel2> # value: <Promise>
[8:09pm] <amiller> ? attwhite <- ("1")
[8:09pm] <eel2> ? attwhite <- ("1")
[8:10pm] <eel2> # value: <Promise>
[8:10pm] <amiller> ?boardState
[8:10pm] <eel2> ? boardState
[8:10pm] <eel2> # value: "pawn 1"
[8:10pm] <amiller> ? attwhite <- ("2")
[8:10pm] <eel2> ? attwhite <- ("2")
[8:10pm] <eel2> # value: <Promise>
[8:10pm] <amiller> ?boardState
[8:10pm] <eel2> ? boardState
[8:10pm] <eel2> # value: "pawn 2"
[8:10pm] <kpreid> btw in a real distributed system, you couldn't do _assignment_ of a variable from another vat - I did that just as a shorthand for passing a message back
[8:10pm] <amiller> it doesn't matter what object i call __whenMoreResolved? I don't understand the 'neighbor' relationship
[8:10pm] <kpreid> by neighbor I meant "in the same vat as"
[8:11pm] <kpreid> in *this* case it doesn't matter because you're writing all of the code in the same vat
[8:11pm] <amiller> well there's going to need to be some way that __whenMoreResolved is modified to verify a signature
[8:11pm] <kpreid> NO!
[8:11pm] <amiller> mm
[8:12pm] <kpreid> __whenMoreResolved is an ordinary method. It gets ordinary messages.
[8:12pm] <kpreid> Verifying signatures on _network_ messages is the job of the comm system
[8:12pm] <kpreid> (Which does not care what application we are implementing on it at all.)
[8:13pm] <amiller> suppose i have two move objects/functions though, whitesMove and blacksMove
[8:13pm] <amiller> and we have sturdyrefs with public keys for each of those
[8:14pm] <amiller> either you will need to sign some message in order to call makeAttenuator(whitesMove)
[8:14pm] <kpreid> no, makeAttenuator is local (serialized along with the rest) code, so no crypto ops
[8:15pm] <amiller> i get that the network is going to do the crypto ops, but i can't figure out what rule it will need to know which signature to check and when
[8:16pm] <kpreid> the table of sturdyrefs (they're not really sturdyrefs any more) stores what key(s) messages to a given object should be signed with
[8:16pm] <kpreid> in fact, you could make it 1:1 - the public key signing a message _designates_ what object to deliver it to
[8:16pm] <kpreid> (*IANACryptographer)
[8:17pm] <amiller> at some point there is going to be a move() message sent to whitesMove
[8:17pm] <amiller> but it's not going to be signed with the whitesMove public key
[8:17pm] <kpreid> yes, from the attwhite object living in the public vat
[8:17pm] <kpreid> it is a local, object-reference. no crypto needed
[8:18pm] <kpreid> the fact "attwhite contains a reference to whitesMove" is part of the vat's state
[8:22pm] zooko joined the chat room.
[8:23pm] nejucomo left the chat room. (Ping timeout: 245 seconds)
[8:25pm] <amiller> okay i think what happens is that a message signature gets checked when a sturdyref gets unserialized.
[8:26pm] <kpreid> a signature gets checked _when the comm system receieves a message_ before it delivers the message to the target object.
[8:26pm] <kpreid> That is, as far as I can see, the only sensible way to do it.
[8:26pm] <amiller> the comm system needs to know which pubkey to check the signature against though
[8:26pm] <amiller> it needs to do that not based on the message recipient but on the sturdyrefs it needs to have translated
[8:27pm] <kpreid> The comm system's job is to know what objects have been granted to what pubkeys.
[8:27pm] <kpreid> Sorry, explain that last claim?
[8:27pm] <amiller> objects get sent messages, but it's sturdyrefs that are going to be associated with pubkeys
[8:28pm] <kpreid> I think we should stop using the term "sturdyref", because a sturdyref is really a crypto thing that doesn't apply to this situation.
[8:28pm] <amiller> i need some endpoint to refer to
[8:28pm] <kpreid> A sturdyref is authority-to-send; the authority-to-send in this implementation is the *signing key*.
[8:29pm] <kpreid> (plus the target public-vat to contact)
[8:29pm] <amiller> there are two endpoints, there's the event where you designate a public key and then the even when the signature is checked
[8:30pm] <amiller> so we were talking about having a modified sturdyRef or makeURI that takes a publickey as a parameter
[8:30pm] <amiller> it doesn't matter what happens with the public key just that it is designated at some point
[8:30pm] <kpreid> yes...
[8:30pm] <amiller> so the question is where the other end point goes, and what i think is that it should go in the place where the sturdyRef is translated
[8:31pm] <amiller> like when the swissnum is looked up
[8:31pm] <kpreid> there is no swissnum
[8:31pm] <kpreid> we can't have swissnums in this system, because the vat state is public
[8:33pm] <kpreid> the replacement for the swissnum in the comm system state is the public key
[8:34pm] <kpreid> the replacement for the swissnum in a sturdyref is the private key
[8:36pm] <amiller> this fn _ { attwhite := makeAttenuator(whitesMove) }) that gets serialized
[8:36pm] <amiller> it doesn't get serialized with the text whitesMove
[8:36pm] <amiller> i'd have to refer to it by a remote ref of some kind right
[8:36pm] <amiller> like its public key?
[8:36pm] <kpreid> correct, we have to construct a remote ref, so we generate a key-pair for it
[8:36pm] <amiller> okay
[8:36pm] <kpreid> oh
[8:37pm] <kpreid> the situation is asymmetric
[8:37pm] <kpreid> if it were symmetric, we would make a key-pair and transmit the *private key*
[8:37pm] <kpreid> But we don't actually want a private key there, because the public vat is public
[8:38pm] <kpreid> er, wait, I'm confused, that's a different case.
[8:38pm] <kpreid> What I just started explaining is the case for "attwhite", the local variable that needs to get modified by code on the public vat
[8:38pm] <kpreid> (rather, &attwhite)
[8:38pm] <kpreid> But "whitesMove" is a different case - we are sending a reference to an object in the public vat, *to* the public vat.
[8:39pm] <kpreid> So, yes, there does need to be a signature verification independent of receiving a message, to be able to designate the object.
[8:40pm] <kpreid> That verification is still invoked within the comm system, specifically the unserialization subsystem.
[8:40pm] <amiller> i think it just needs to be done during the deserializing code
[8:40pm] <amiller> when the remote ref is dereferenced
[8:41pm] <kpreid> Yes...though at some stage it is recognized as not-a-remote-ref
[8:41pm] <kpreid> (but rather local)
[8:42pm] <amiller> that transition is exactly when the sig should be checked
[8:43pm] <amiller> so you sign your serialized code
[8:43pm] <kpreid> As part of signing the message it is a component of, yes.
[8:43pm] <amiller> ah, sure
[8:44pm] <amiller> okay and if you have multiple remoterefs with diferent pubkeys, you need a signature for each one
[8:44pm] <amiller> or if you only want to have a single signature you could always group them by redelegating them
[8:44pm] <amiller> this matches how bitcoin works btw
[8:44pm] <amiller> the transations are signed
[8:45pm] <amiller> multiple times, one for each input
[8:53pm] zooko left the chat room. (Read error: Connection reset by peer)
[8:56pm] zooko joined the chat room.
[8:59pm] * amiller git-clones e-on-cl and hopes for the best
[9:00pm] <amiller> are there any other rooms i can use to play with eel2
[9:00pm] <amiller> couldn't get private messages to work with him
[9:01pm] <kpreid> by design, there is no non-public access, but there is more obscure access
------------------------------------------------------------------------
--
Kevin Reid <http://switchb.org/kpreid/>
Kevin Reid <http://switchb.org/kpreid/>