<p dir="ltr">Den 1 jan 2015 18:33 skrev "ianG" <<a href="mailto:iang@iang.org">iang@iang.org</a>>:<br>
><br>
> On 31/12/2014 03:53 am, grarpamp wrote:<br>
>><br>
>> I'd consider models of hashing and signing distributed materials<br>
>> as a serious and necessary applied crypto conversation.<br>
><br>
><br>
> One of the things that is going on in the bitcoin 2.0 world is that some of the groups are wrestling with how to distribute different instruments.  As we know, Natoshi Sakamoto hit upon an elegant simplification by eliminating the semantics of his issue, by the trick of only having one.  This simplification breaks down as soon as you want more than one issue, more than one chain, more than one semantics.  As soon as you want choice in anything, more or less.<br>
><br>
> One way to distribute information about something like an issuance of value is what I call the Ricardian Contract [0].  This is a contractual document that has a few smart fields slipped in, and carries its own PKI.  When cleartext signed to fix it, it can then be canonically hashed to form the identifier for the unit of issuance.<br>
><br>
> Now, if you look at things like blockchains, there is an emerging pattern that many people want to run their own, and different ones.  But the basic pattern is the same, in that the description of any given blockchain remains largely in the same format, with some different parameters [1].  If one imagines a commercial service running a chain for some particular purpose -- call it coffeechain for low value fast retail -- then we could also include some static contractual information.  Something like an open combination of params and legal text could be useful to describe coffeechain.<br>
><br>
> The same pattern might be observed with IoT devices that can be accessed from anywhere.  We need to access the public key of the device, we need examine the params, and we need to be able to examine the service conditions.<br>
><br>
> Why is this interesting?  Because if we are in a world of millions of these things, we also need some strong identifiers, and ways to go from the identifier to the description without fail, and ways to go from the description to the identifier without fail.<br>
><br>
> We also need a world in which anyone can play.  We don't want a world where in order to run a chain or put up a new device, we have to get the permission of someone else, or get enslaved to some facade security model which incumbents lock up and stop from migrating in OODA time.<br>
><br>
> Using an open document and taking the message digest of it for service as the identifier for that document/device achieves some of those goals, at least on paper.<br>
><br>
><br>
>> Not<br>
>> least of why because many of the people on these lists have no<br>
>> idea how to actually do such things, let alone well.<br>
><br>
><br>
> Indeed.  And my knowledge of IoT devices is rather popularist.  So, does a device have these characteristics?  Does it have some params that need exploring?  Does it have a service agreement?  A need to publish keys, control info, etc?<br>
><br>
> Could we benefit from having an architecture that settles on one identifier across the IoT space, and uses (eg) a DHT to find the document for it?<br>
><br>
> I don't know.  It seems analogous enough to ask, what would a cryptographically secure data infrastructure be for small cheap devices on the net?</p>
<p dir="ltr">I'm not sure if I have correctly understood what you are looking for, do you want a generic public append-only data structures with custom validation rules?</p>
<p dir="ltr">But the blockchain derived document management system Factom might be relevant. They've got things like what they call "proof of process" where you frequently publish documents in a chain where one can verify that there's just ONE chain of such documents and which is the most recent one (you can't hide or replace old documents or create forks). <a href="http://factom.org">http://factom.org</a></p>
<p dir="ltr">Then we have the various Turing complete prototype altcoins where you can create your own namespaces á la Namecoin and register and process arbitary data. But that's still not all the way there. </p>
<p dir="ltr">I've been considering something much more flexible myself by merging the concepts between Namecoin, Pay-to-script-hash addresses in Bitcoin (P2SH) and the Turing complete coins plus Zero-knowledge proofs like what Zerocoin uses. </p>
<p dir="ltr">Here is what Zerocoin does: there's a global mixing address which you use by committing to a unique secret "serial number", a nonce, when sending coins to it. All these transactions are then entered into an RSA based one-way accumulator (assuming this is for simplifying ZKP creation). To withdraw you create an address in a deterministic way from your serial number (so it can't be used twice this way) and generate a Zero-knowledge proof of that you did indeed send coins to the mixer and haven't previously claimed then. This allows you to withdraw a random set of coins of the same value as what you sent to the mixer. </p>
<p dir="ltr">P2SH is a way in Bitcoin to force the usage of a certain script to withdraw coins from that address. Multisignature addresses all use P2SH, to enforce the requirement of signing with multiple specified keys. </p>
<p dir="ltr">Now you could extend this: you would register a data structure / namespace with predefined validation rules which you then must prove you have followed by using Zero-knowledge proofs. This way you can keep the contents and even the validation rules you're using secret, and yet the miners don't need to know anything more than that your public transaction with its commitment hashes and its pointers to your previous transactions has a valid Zero-knowledge proof.</p>
<p dir="ltr">This allows anybody to prove and verify just about anything that can be stated algorithmically AND simultaneously ensure global consistency of those same claims. Scoreboards, financial audits, checkpointing your own internal databases, etc, you could use it for just about anything.</p>
<p dir="ltr">And for your question on identifiers, this would allow you to specify that too in the transactions as part of the public data. You could refer to an entry in another DNS data structure, or to a DHT, or a Tor or I2P service, etc... <br>
</p>