v1.1.0

This release is intended to make things simpler for developers to implement Travel Rule compliance solutions on top of TRISA. Many of these tools will be used in the Envoy project. The big updates include:

Transaction States - you can now add a workflow state to a SecureEnvelope to indicate to the counterparty what state the envelope is in. E.g. is the transaction started, pending, accepted, in need of repair, rejected, or completed? These states hint at the expected response from the counterparty and make it easier to identify what is going on when messages are mirrored or echoed.

Address Confirmation - an alpha version of address confirmation has been added (just the protocol buffer definitions). It includes three trial methods: simple, key/token, and on-chain. In the simple method, the counterparty simply reports if they have control or not. In key/token a token is encrypted with the public key of the crypto address and the counterparty must return the decrypted token using the private key. In on-chain, the counterparty must post a transaction to a supplied beneficiary address with a very small amount that serves as a nonce value; once the originating party sees the transaction on the chain they know that the counterparty has control of the address. This protocol definition does not service as an official position from TRISA about how to conduct address proof-of-control (as it has been removed from the white paper) but provides an opportunity for counterparty peers to conduct such confirmation in an automated way.

Other changes include easier rejection envelopes, HMAC validation, and better documentation.

What's Changed

• Envoy Documentation Update by @bbengfort in #160
• Easier Rejection Errors by @bbengfort in #161
• Expose HMAC validation to user by @bbengfort in #162
• Transaction States by @bbengfort in #163
• Address Confirmation Message Definitions

Full Changelog: v1.0.0...v1.1.0