The ipdb-tx-spec from ipdb

ipdb-tx-spec's People

Contributors

For each version, include some test vectors, i.e. example inputs and example outputs, maybe even some intermediate values.

The main baseline of this issue is that there are no baselines. The main limitation of this issue is that there are no limits.

To set the tone, let's start with the future, and an example of something that can be in this issue:

I hope this convinces you to contribute!

Some things that this issue hopes to explore:

Interface Description Language (IDL) used (e.g.; ASN.1, Protocol Buffers).
Generic database-independent model definitions, allowing for usage in heterogeneous networks, meaning networks in which the underlying database systems used may vary for different nodes.
Model definition that would allow other protocols (e.g.; ocean) to build their own model on top. Perhaps this is already so for COALA IP and ocean. /cc @TimDaub
Support for other crypto-conditions, such as hashlocks, RSA signatures, and the prefix compound condition.
Extensions to crypto-conditions, to support new conditions, such as different signatures.
Pluggable locking mechanism (e.g. replace crypto-conditions by something else) /cc @diminator @vrde.
Pluggable hashing algorithm (e.g.: see https://github.com/multiformats/multihash).
Specification of protocols regarding the construction of transactions, for all cases but especially for cases involving highly complex compound conditions with multiple participants that may not trust each other (if that matters).
Security guarantees of the transaction model, especially with respect to malleability -- if that makes sense.
Message that should be signed when fulfilling a condition. For instance, should it be always the same thing for all inputs of a transaction?