From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id F4123884 for ; Thu, 23 Jun 2016 12:58:31 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f174.google.com (mail-qk0-f174.google.com [209.85.220.174]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5A44B176 for ; Thu, 23 Jun 2016 12:58:31 +0000 (UTC) Received: by mail-qk0-f174.google.com with SMTP id a186so105373782qkf.0 for ; Thu, 23 Jun 2016 05:58:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ORrvcH9aDD3MVAqIr2iNMTp4HYAn1mXgm+SjCoGfc/w=; b=rUKAk9Isp/PO/Umbzy8Np2ntIu13keeQj4QdSxIT9O8EetfDDJoKy2/YIj9/uns3d6 jCoMiAeoTXPwVY8JW+yNEq7zZ7Vefygm6IEZuDTIG8M9f6zdgr8xZTrV8nNDCw/i/jS2 zAks495+iAkQdd8KfErHZdjcW0fHV8eqdC9CbiaAwerPmgOGjMgC2dU6BTR+2CRSutU7 1UnINOijspHisH6F6xkRzLtLCEa8fncarUFOSNFwQ28+aHnnRDO4zG2eLk2CjuoaTl73 pX8XStfeDyG3yYgK6nC8S04ryZZiwNdiN2xO2XKPvbVPoD0kl27Fg4hWyWJxOA2h/zZE 8Wzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ORrvcH9aDD3MVAqIr2iNMTp4HYAn1mXgm+SjCoGfc/w=; b=jxYgf40wyUn2GFUQY876SfYmC774U7It1ZGyNZ6yGhFsfnaed2rstuCFhnQSIPlcm9 VCidFTSm4aDhgInGVtkiCsomm825SpN9mS+LC82njqm91m0j8TzH3Oq2ZTm/saR4EeG2 NUOeZ/cbqJhysZA9ONTAw02Vqy/JQbTTbCXgS5OOm5ZTYlHL6NpPIfhIIbARqMHaKs2F PCqchpwnpmkTs6cq/SUPa6isZaq8koiE3aJXEBeWzpW49oRFM1rS7Ut45XqjhBwsESYK t4MPHxI+Z6ON2CV31ESGd35pNQ5hAY6VFfl9LeLzvNTAt/UJfjCJAFuVZDQf4vAzPZ3Y KWOA== X-Gm-Message-State: ALyK8tIzxuN+aHrReR+O63YJBbxKaYBYGRtLlFdV3tbovesiU5aDQvmqRKeQ1xAr7pkOkE9he7rG9nGHTgjuxA== X-Received: by 10.200.37.9 with SMTP id 9mr25368725qtm.31.1466686710430; Thu, 23 Jun 2016 05:58:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.50.85 with HTTP; Thu, 23 Jun 2016 05:58:29 -0700 (PDT) In-Reply-To: <20160623111152.GB19360@fedora-21-dvm> References: <20160620085649.GA29964@fedora-21-dvm> <20160623111152.GB19360@fedora-21-dvm> From: Alex Mizrahi Date: Thu, 23 Jun 2016 15:58:29 +0300 Message-ID: To: Peter Todd Content-Type: multipart/alternative; boundary=001a113bcc445f432a0535f19c29 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Building Blocks of the State Machine Approach to Consensus X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 12:58:32 -0000 --001a113bcc445f432a0535f19c29 Content-Type: text/plain; charset=UTF-8 > > The point I'm making is simply that to be useful, when you close a seal you > have to be able to close it over some data, in particular, another seal. > That's > the key thing that makes the idea a useful construct for smart contacts, > value > transfer/currency systems, etc. > OK, your second post ("Closed Seal Sets and Truth Lists for Better Privacy and Censorship Resistance") seems to clarify that this data is one of arguments to the condition function. Frankly this stuff is rather hard to follow. (Or maybe I'm dumb.) Now I don't get scability properties. Let's consider a simplest scenario where Alice creates some token, sends it to Bob, who sends it to Claire. So now Claire needs to get both a proof that Alice sent it to Bob and that Bob sent it to Claire, right? So Claire needs to verify 2 proofs, and for a chain of N transfers one would need to verify N proofs, right? And how it works in general: 1. Alice creates a token. To do that she constructs an unique expression which checks her signature and signs a message "This token has such and such meaning and its ownership originally associated with seal " with her PGP key. 2. To transfer this token to Bob, she asks Bob for his auth expression and sends a seal oracle a message (Alice_expression (Bob_expression . signature)) where signatures is constructed in such a way that it evaluates as true. Oracle stores this in a map: Alice_expression -> (Bob_expression . signatures) 3. Bob sends token to Claire in a same way: (Bob_expression (Claire_expression . signature)) 4. Now Claire asks if Alice_expression->(Bob_expression . _) and Bob_expression->(Claire_expression . _) are in oracle's map. She might trust the oracle to verify signatures, but oracle doesn't understand token semantics. Thus she needs to check if these entries were added. If I understand correctly, Alice_expression->(Bob_expression . _) record can be communicated in just 3 * size_of_hash_digest bytes. So this seems to have rather bad scalability even with trusted oracles, am I missing something? --001a113bcc445f432a0535f19c29 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The point I'm making is simply that to = be useful, when you close a seal you
have to be able to close it over so= me data, in particular, another seal. That's
the key thing that make= s the idea a useful construct for smart contacts, value
transfer/currenc= y systems, etc.

OK, your second post ("Closed Seal Sets and Truth Lists for Better Privacy and C= ensorship Resistance") seems to clarify that this data is one of argum= ents to the condition function.
Frankly this stuff i= s rather hard to follow. (Or maybe I'm dumb.)
Now I don't get scability properties. Let'= ;s consider a simplest scenario where Alice creates some token, sends it to= Bob, who sends it to Claire. So now Claire needs to get both a proof that = Alice sent it to Bob and that Bob sent it to Claire, right? So Claire needs= to verify 2 proofs, and for a chain of N transfers one would need to verif= y N proofs, right?

And = how it works in general:

1. Alice creates a token. To do that she constructs an unique expression w= hich checks her signature and signs a message "This token has such and= such meaning and its ownership originally associated with seal <hash of= the expression>" with her PGP key.
2. To tr= ansfer this token to Bob, she asks Bob for his auth expression and sends a = seal oracle a message (Alice_expression (Bob_expression . signature)) where= signatures is constructed in such a way that it evaluates as true. Oracle = stores this in a map: Alice_expression -> (Bob_expression . signatures)<= /span>
3. Bob sends token to Claire in= a same way: (Bob_expression (Claire_expression . signature))
4. Now Claire asks if Alice_expression->(Bob_exp= ression . _) and Bob_expression->(Claire_expression . _) are in oracle&#= 39;s map. She might trust the oracle to verify signatures, but oracle doesn= 't understand token semantics. Thus she needs to check if these entries= were added.
If I understand correctly= , Alice_expression->(Bob_expression . _) record can be communicated in j= ust 3 * size_of_hash_digest bytes.
So this seems to have rather bad sca= lability even with trusted oracles, am I missing something?
--001a113bcc445f432a0535f19c29--