Topic: User assets, peer-to-peer exchange, off-chain accounting & transitive txn in btc (Read 9619 times)
September 02, 2014, 03:48:30 PM
There will be an update coming soon. Although we were unable to secure funding from the community, Jorge and I are working together with others on a currently stealth-mode project that includes aspects of Freimarkets. We are also working on an update to the whitepaper to include all the advances that have come in the last year. Our mental model of how Freimarkets would be implemented has diverged a bit for the better from what we wrote down a year ago.
August 29, 2014, 12:50:04 PM
Update?
August 26, 2013, 11:54:56 AM
We have a crowd-fund proposal in the project development thread:
https://bitcointalksearch.org/topic/crowdfund-user-issued-assets-p2p-exchange-off-chain-transactions-and-more-278671
I hope that this thread can serve for a more technical discussion now that the whitepaper is out.
Freimarkets solves a superset of the problems BitShares seeks to solve, although the implementation pathway is completely different (extensions to bitcoin instead of a new system entirely). Freimarkets is a more general proposal, however, consisting as it is of general low-level primitives that enable user assets and peer-to-peer exchange, but also unrelated applications like transitive trust credit relationships, derivatives, etc.
https://bitcointalksearch.org/topic/crowdfund-user-issued-assets-p2p-exchange-off-chain-transactions-and-more-278671
I hope that this thread can serve for a more technical discussion now that the whitepaper is out.
Freimarkets solves a superset of the problems BitShares seeks to solve, although the implementation pathway is completely different (extensions to bitcoin instead of a new system entirely). Freimarkets is a more general proposal, however, consisting as it is of general low-level primitives that enable user assets and peer-to-peer exchange, but also unrelated applications like transitive trust credit relationships, derivatives, etc.
August 23, 2013, 10:10:57 PM
Very fitting development given the BitShares announcement.
Excited to see these two develop. Digging through the whitepaper now. Should this not be in Project Development though?
Excited to see these two develop. Digging through the whitepaper now. Should this not be in Project Development though?
August 23, 2013, 07:04:22 PM
Off-and-on for the past couple years, Jorge Timón (jtimon) and Mark Friedenbach (maaku) have been developing an extension of the Bitcoin and (pre-OpenCoin) Ripple distributed protocols which enable user-specified bearer instruments, off-chain accounting, atomic trades, peer-to-peer auctions/exchange, derivatives and transitive transactions, and the multitude of financial contracts these primitives would make possible. The specification is now reasonably complete enough that we would like to receive input from the community.
(The full specification is available for download as a PDF document - what follows is a high level summary. Furthermore, we have a crowd-fund in progress to help pay for the necessary development to implement this. Any feedback from the technical people here would be especially welcome.)
Overview:
Herein we propose a new transaction format which enables hierarchies of independently verified sub-transactions, additional validation scripts and introspective opcodes, strict currency controls for user assets, as well as relaxation of the rules regarding coin generation via coinbase transactions for the purpose of supporting user-defined assets on the block-chain. We also introduce the concept of private centralized accounting servers to perform transactions of off-chain assets that cam interact with each other as well as with in-chain assets. These changes necessarily require a hard-fork, and will be deployed to the Freicoin chain first (merged mined against bitcoin). Combined with suitable extensions to the peer-to-peer, JSON-RPC, RESTful, and wallet interfaces, these protocol changes complete bitcoin’s repertoire of low-level constructs, allowing the emulation of the wide variety of financial instruments mentioned above.
Here are some example applications we've worked out in detail:
This proposal adds primitives to bitcoin necessary for implementing non-currency financial constructs, such as dividend-yielding bonds, asset ownership tokens, credit relationships, a variety of forms of smart contracts, and distributed marketplaces for exchanging all of the above. Private accounting servers provide a mechanism to support unlimited volume of off-chain transactions while being able to interact with in-chain assets through atomic cross-chain trade and an integrated peer-to-peer market.
User-issued assets:
Divisible currency and/or tokens representing user-issued assets may be minted in special coinbase transactions separate from the usual first transaction of a block (where bitcoins are currently, and continue to be minted). Coins created in such generating transactions are not bitcoins, but rather user-issued asset shares which represent fungible ownership of the underlying asset type, or asset tokens identified by per-asset unique bitstrings. Such coins and tokens can be included in transactions containing regular p2p-issued coins, which in this proposal is sometimes called the host currency or fee currency.
The creator of the new asset can define an interest/demurrage rate. The quantity issued may be fixed or he may define a list of issuance tokens that permit their owners issue new units of the asset being defined.
The creator of the asset definition transaction may also specify a list of authorizer tokens. The signature of an authorizer is required every time a transaction involves inputs or outputs of that asset. This allows issuers/gateways to manage closed list of “authorized accounts” of registered users if regulatory restrictions of their jurisdiction requires them to do so or if they desire whitelisting of participants (for example, local currencies or restricted stock sales). It also allows issuers to charge fees when the assets are traded or moved.
Using unique tokens to manage new issuance and authorizers allows the creator to follow his own key cycling policy or security protocols. By utilizing multisig or multiple signatures, it is possible for transactions to remain valid even across one or more key rotations.
These various properties of the asset, its interest/demurrage rate, unit granularity and display scale, and listings of issuer and authorizer tokens are set in the coinbase string of the asset definition transaction.
Partial transactions:
This proposal extends the transaction format with an optionally empty nested level of sub-transactions. Sub-transactions differ from regular, top-level transactions in that their inputs and outputs are not required to balance and they have associated with them a quantity and granularity allowing for fractional redemption.
Since validation of sub-transactions occurs separately from each other and the higher-level enclosing transaction, pre-signed, unbalanced transactions are able to act as offers on a distributed exchange: market participants sign offers adding coins of one asset type in exchange for an output of another type. These signed offers are broadcast through a side-channel and aggregated by miners. When a cross-over is detected (a bid higher than an ask), the miner combines the two pre-signed offers and claims the difference as a fee.
Other use cases are enabled. For example, when the underlying assets represent lines of credit, the exchange mechanism allows payments based on transitive trust relationships, in the style of the original Ripplepay application by Ryan Fugger.
Private ledgers:
Private accounting servers (the “accountant”) use a variant of the bitcoin code base that is stripped of the distributed consensus proof-of-work mechanism. Accountants are responsible for eliminating double-spending, reserving balances for pending transfers, and authorizing transactions, sometimes conditionally on external events. Accountants are able to prevent transactions from going through if the owner has already obligated funds elsewhere, by keeping track of the available balance (actual balance minus funds in various stages of commit). Accountants use various distributed consensus mechanisms for coordinating the transaction commitment with other private accounting servers or public block chains.
The level of privacy may vary from one server to another. Server operators are allowed freedom in choosing which parts of the block chain audit log to publish, with a sensible default being the block headers and coinbase transactions, allowing for validation of authenticated inclusion and index proofs used to notify users of their wallet balance, history and current activity, but not revealing other user’s balances.
By using newly added introspective opcodes to construct scripts dependent on external chains, it is possible for private transactions to be conditional on public block chain data or other private accounting servers.
Note that the opposite relation cannot apply at this time. Public chains could support transactions conditional to data on other chains to enhance cross-chain trade, but then the observing chain’s validation becomes dependent on the observed chain validation. This approach to cross-chain has been described several times elsewhere, and would be trivial to implement with this protocol extension.
For more details, check out the PDF:
http://freico.in/docs/freimarkets.pdf
(The full specification is available for download as a PDF document - what follows is a high level summary. Furthermore, we have a crowd-fund in progress to help pay for the necessary development to implement this. Any feedback from the technical people here would be especially welcome.)
Overview:
Herein we propose a new transaction format which enables hierarchies of independently verified sub-transactions, additional validation scripts and introspective opcodes, strict currency controls for user assets, as well as relaxation of the rules regarding coin generation via coinbase transactions for the purpose of supporting user-defined assets on the block-chain. We also introduce the concept of private centralized accounting servers to perform transactions of off-chain assets that cam interact with each other as well as with in-chain assets. These changes necessarily require a hard-fork, and will be deployed to the Freicoin chain first (merged mined against bitcoin). Combined with suitable extensions to the peer-to-peer, JSON-RPC, RESTful, and wallet interfaces, these protocol changes complete bitcoin’s repertoire of low-level constructs, allowing the emulation of the wide variety of financial instruments mentioned above.
Here are some example applications we've worked out in detail:
- Issuing new assets by means of asset definition transactions (coinbase transactions other than the usual first transaction of a block). Such assets are allowed to specify their own interest/demurrage rate, unit granularity, display scale, and contain a hash field referencing an external resource, possibly a legal or Ricardian contract that the chain itself doesn't validate.
- Issuing unique and indivisible assets that are transferred in sets instead of numeric amount, and allow fast look ups on their current ownership to enhance smart property use cases and manage some permissions of the regular custom assets.
- Atomic exchange of assets of differing types through inclusion of inputs and outputs of both types in a single transaction.
- Signing orders (partial-transactions giving up one asset in exchange for another) that are binding but not completed until they get into the chain as part of a balanced transaction, and have attached expiration dates or can be explicitly cancelled by double-spending the signed inputs.
- Executing an arbitrary number of these orders atomically by creating a complete valid transaction where the orders are included as nested sub-transactions, thereby executing an atomic trade without requiring each of the parties to be online or in direct communication with each other. Composing orders from separate markets into an atomic trade with intermediate assets enables payments based on transitive trust relationships.
- Destruction of coins, tokens, or assets when no longer needed by a special class of non-spendable, prunable output script.
- Restricting the conditions by which a transaction or sub-transaction may be selected for inclusion by specifying validation scripts, which are run when the enclosing block is validated. Introspection of the block chain from within the bitcoin scripting environment is enabled by the introduction of new opcodes.
- Running accounting servers as private chains with centralized rather than distributed consensus, in which off-chain assets can be issued, transferred and traded in the same way they are in the public chain, with the private block chain providing an audit log.
- Execute an arbitrary number of trades from different accounting servers and/or the public chain in an atomic transaction, using either the public chain or an agreed upon timestamping service for the commit phase.
- Public chains or private accounting servers configured to “observe” other chains to enable much faster but secure cross-chain trade, compared with the existing slow, multi-phase protocols involving revelation of hashed secrets. This requires the ability to extract proofs from the observed chain in order to validate conditional transactions.
- Restrict the usage of a custom asset by assigning to it rotatable signing keys which that must sign all transactions involving the restricted assets prior to inclusion (support for KYC regulatory compliance).
This proposal adds primitives to bitcoin necessary for implementing non-currency financial constructs, such as dividend-yielding bonds, asset ownership tokens, credit relationships, a variety of forms of smart contracts, and distributed marketplaces for exchanging all of the above. Private accounting servers provide a mechanism to support unlimited volume of off-chain transactions while being able to interact with in-chain assets through atomic cross-chain trade and an integrated peer-to-peer market.
User-issued assets:
Divisible currency and/or tokens representing user-issued assets may be minted in special coinbase transactions separate from the usual first transaction of a block (where bitcoins are currently, and continue to be minted). Coins created in such generating transactions are not bitcoins, but rather user-issued asset shares which represent fungible ownership of the underlying asset type, or asset tokens identified by per-asset unique bitstrings. Such coins and tokens can be included in transactions containing regular p2p-issued coins, which in this proposal is sometimes called the host currency or fee currency.
The creator of the new asset can define an interest/demurrage rate. The quantity issued may be fixed or he may define a list of issuance tokens that permit their owners issue new units of the asset being defined.
The creator of the asset definition transaction may also specify a list of authorizer tokens. The signature of an authorizer is required every time a transaction involves inputs or outputs of that asset. This allows issuers/gateways to manage closed list of “authorized accounts” of registered users if regulatory restrictions of their jurisdiction requires them to do so or if they desire whitelisting of participants (for example, local currencies or restricted stock sales). It also allows issuers to charge fees when the assets are traded or moved.
Using unique tokens to manage new issuance and authorizers allows the creator to follow his own key cycling policy or security protocols. By utilizing multisig or multiple signatures, it is possible for transactions to remain valid even across one or more key rotations.
These various properties of the asset, its interest/demurrage rate, unit granularity and display scale, and listings of issuer and authorizer tokens are set in the coinbase string of the asset definition transaction.
Partial transactions:
This proposal extends the transaction format with an optionally empty nested level of sub-transactions. Sub-transactions differ from regular, top-level transactions in that their inputs and outputs are not required to balance and they have associated with them a quantity and granularity allowing for fractional redemption.
Since validation of sub-transactions occurs separately from each other and the higher-level enclosing transaction, pre-signed, unbalanced transactions are able to act as offers on a distributed exchange: market participants sign offers adding coins of one asset type in exchange for an output of another type. These signed offers are broadcast through a side-channel and aggregated by miners. When a cross-over is detected (a bid higher than an ask), the miner combines the two pre-signed offers and claims the difference as a fee.
Other use cases are enabled. For example, when the underlying assets represent lines of credit, the exchange mechanism allows payments based on transitive trust relationships, in the style of the original Ripplepay application by Ryan Fugger.
Private ledgers:
Private accounting servers (the “accountant”) use a variant of the bitcoin code base that is stripped of the distributed consensus proof-of-work mechanism. Accountants are responsible for eliminating double-spending, reserving balances for pending transfers, and authorizing transactions, sometimes conditionally on external events. Accountants are able to prevent transactions from going through if the owner has already obligated funds elsewhere, by keeping track of the available balance (actual balance minus funds in various stages of commit). Accountants use various distributed consensus mechanisms for coordinating the transaction commitment with other private accounting servers or public block chains.
The level of privacy may vary from one server to another. Server operators are allowed freedom in choosing which parts of the block chain audit log to publish, with a sensible default being the block headers and coinbase transactions, allowing for validation of authenticated inclusion and index proofs used to notify users of their wallet balance, history and current activity, but not revealing other user’s balances.
By using newly added introspective opcodes to construct scripts dependent on external chains, it is possible for private transactions to be conditional on public block chain data or other private accounting servers.
Note that the opposite relation cannot apply at this time. Public chains could support transactions conditional to data on other chains to enhance cross-chain trade, but then the observing chain’s validation becomes dependent on the observed chain validation. This approach to cross-chain has been described several times elsewhere, and would be trivial to implement with this protocol extension.
For more details, check out the PDF:
http://freico.in/docs/freimarkets.pdf
Jump to: