Ian G wrote:
E.g., Ricardian contracts (my stuff) take the user agreement as a
document and bind it into each transaction by means of the hash of the
contract; they also ensure various other benefits such as the contract
being available and readable to all at all times, and the acceptability
of same, by the simple expedient of coding the decimalisation into the
contract. Ensuring that the contract is readable, applicable and is
available to all is a huge win in any court case.
Other governance tricks: the usage of signed receipts can be used to
construct a full audit of the digital system. Also, signed receipts are
strong evidence of a transaction, which leads by some logic to a new
regime which we call triple entry accounting. This dramatically changes
the practice of accounting (which feeds into governance).
With DB side, one trick is to use psuedonym accounts for the basis, and
this allows no-loss protocols to be created. Again, this is useful for
governance, because if you have a lossy protocol, you have a potential
for fraud.
we had done something analogous in the x9.59 financial standard. the x9a10
financial standard group had been given the requirement to preserve the
financial infrastructure for all retail payments.
http://www.garlic.com/~lynn/x959.html#x959
digital signature on the transaction itself provided for end-to-end
strong authentication (armoring payment transaction as countermeasure
to various kinds of replay attacks ... as have been in the news recently
related to large data breaches and then being able to subsequently
use the information for fraudulent transactions).
one of the "problems" was that some of the other attempts at PKI-related
payments protocols in that period ... were creating enormous
(two orders of magnitude) processing and payload bloat
http://www.garlic.com/~lynn/subpubkey.html#bloat
one of the implied x9a10 requirements was efficiency, i.e. mechanism that could
be
deployed in ALL environments (internet, point-of-sale, cellphone, etc) ...
and needed to be highly concerned about processing and payload efficiency.
the actual transaction is digitally signed ... and it is also the thing that
is authorized, logged, archived, audited, etc.
so part of x9.59 provided for a hash of the receipt (contract, bill-of-materials,
sku data, "level 3" data, etc) as part of the digitally signed payload
(as opposed to including the whole receipt). Then in any subsequent dispute,
if both parties didn't produce identical receipts ... the hash from the
audited/logged/archived transaction could be used to determine the
valid/correct receipt.
While the receipt wasn't part of the actual audited/archived/logged transaction,
the process provided a mechanism (in cases of disputes) for establishing the
legitimate receipt.
we claimed privacy agnostic for x9.59 ... i.e. there was an account number in
protocol but the degree that any jurisdiction required a binding between an
account number and an individual was outside the x9.59 protocol. x9.59 was
designed so that it could be used for credit, debit, stored value, ach, etc.
In many jurisdictions, credit & debit can have some "know you customer"
requirements for financial institutions (binding between individuals
and account numbers) ... however there was 1) no requirement to divulge
such bindings during retail transactions and 2) x9.59 applies equally
well to stored-value retail transactions (where there is much less
frequently a requirement imposed for "know your customer".
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
