Skip to main content

Crypto-Conditions
draft-thomas-crypto-conditions-04

Document Type Expired Internet-Draft (individual)
Expired & archived
Authors Stefan Thomas , Rome Reginelli , Adrian Hope-Bailie
Last updated 2018-07-23 (Latest revision 2018-01-19)
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Expired
Telechat date (None)
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:

Abstract

The crypto-conditions specification defines a set of encoding formats and data structures for *conditions* and *fulfillments*. A condition uniquely identifies a logical "boolean circuit" constructed from one or more logic gates, evaluated by either validating a cryptographic signature or verifying the preimage of a hash digest. A fulfillment is a data structure encoding one or more cryptographic signatures and hash digest preimages that define the structure of the circuit and provide inputs to the logic gates allowing for the result of the circuit to be evaluated. A fulfillment is validated by evaluating that the circuit output is TRUE but also that the provided fulfillment matches the circuit fingerprint, the condition. Since evaluation of some of the logic gates in the circuit (those that are signatures) also take a message as input the evaluation of the entire fulfillment takes an optional input message which is passed to each logic gate as required. As such the algorithm to validate a fulfillment against a condition and a message matches that of other signature schemes and a crypto-condition can serve as a sophisticated and flexible replacement for a simple signature where the condition is used as the public key and the fulfillment as the signature.

Authors

Stefan Thomas
Rome Reginelli
Adrian Hope-Bailie

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)