Transactional system with peer-to-peer distributed architecture for exchanging units of account
a distributed architecture and transaction system technology, applied in the field of protocols, can solve the problems of inability to change the condition and not always possibl
- Summary
- Abstract
- Description
- Claims
- Application Information
AI Technical Summary
Benefits of technology
Problems solved by technology
Method used
Image
Examples
first embodiment
[0068]First we introduce the concepts of “contract” and “context”, the application of a contract on a context resulting in “constraints”.
[0069]As mentioned in the preamble, it has recently been introduced in Bitcoin an option to specify the condition of an output by placing in it the hash of this condition (called «Pay to Script Hash» or #P2SH), which must be provided in clear in the input of the transaction that uses this output (and this condition must be satisfied for that transaction to be valid). To date, the conditions that can be expressed in Bitcoin are merely conditions of multi-signatures to be provided in said input. We will use this method in the following examples.
[0070]The left side of FIG. 3 presents an example thereof:
[0071]A transaction “Tx1” provides 1000 units of account to a recipient node identified by a hash code referred to as “C1”, these 1000 units can only be consumed by an input with a script whose hash code (obtained by applying a predetermined hash functi...
second embodiment
[0132]A second embodiment of the method of the invention will now be described, which also consists in validating each transaction based on the consistency model shown in FIG. 2, but additionally based (in the context) on the specification of transaction types and input parameters they admit, thus constraining the outputs of the downstream transaction in a particular manner.
[0133]FIG. 8 diagrammatically depicts a networked risk-pooling example using this embodiment.
[0134]In this embodiment, the blockchain is structured in different “pots”, each associated with an individual user terminal and to the damage risk that this user can be exposed to. Each transaction can have inputs connected to several upstream transactions from different pots and several transactions can be generated on a same pot e.g. to allow multiple payments.
[0135]In the example shown in FIG. 8, users:[0136]each have a pot that they feed through «Refill» transactions;[0137]specify «Potential Contribution» transaction...
PUM
Login to View More Abstract
Description
Claims
Application Information
Login to View More 


