This probably increases both traffic and the size of the unspent transaction output set.

I actually read that completely differently - that the bounty specifically requires support for the cryptographic anonymizing protocols that were proposed and discussed in the first few posts of this thread. Nevertheless, some clarity from he judges would be appreciated.

Hrm. "Autonomously executed" is a mouthful, but I see your point. I'll see if I can find a better way to phrase it...


Our hope with this crowd-fund is that through public discussion of the proposal we could educate people on why it's valuable, and get people excited about seeing it implemented. User assets, distributed p2p exchange, off-chain transactions... these are all things that people on this forum are clamoring for, and this proposal delivers them all simultaneously, as well as other more esoteric features like ripple-esque credit lines, smart property tools, and AML/KYC compliance. Seeing that Freicoin developers are serious about making this happen would drive investment in freicoins, and getting donors to provide the financial resources to make this happen would protect that investment. But as you say, it is a form of the prisoner's delima, resolution of which will hopefully come if/when we get the momentum which follows our first big donor...


We have ideas for how to distribute demurrage other than to the miners, if/when that is ever a problem. My personal idea is a proof-of-stake budgetary voting system I've called 'republicoin', which is designed to resemble a combination of participatory budgeting processes and parliamentarian democracy. But that's an issue we can address if/when it ever becomes a problem.

The initial distribution is a separate issue. It's given us significant street cred outside of the bitcoin community that we've setup a non-profit to handle most of the initial distribution. It's opened some doors for collaboration as well, although we have yet to see how that pans out. In either case, giving 20% vs 100% to the miners would have resulted in the same amount of burnt cycles and excess heat in either case during these first few years, so at least this way some charitable good comes of it.

Yes, I'm in favor of replace-by-fee. I think we mean something different by binding, however. In this case we mean that the orders are pre-signed, even though the counter-party is not known at the time the offer is created: the signature on the offer is all that's required to get the final matched exchange transaction on the chain. You could, for example, sign an offer, broadcast it, and then disconnect from the network and never come back. The offer remains in force until some other condition invalidates it, such as a double-spend, passing the nExpireTime, scriptValid ceasing to validate, etc.

The important distinction is not whether you can back out or what steps are required, but the fact that the participants need not be online at the same time. This is in contrast to some other proposals, which clear the market by generating regular bitcoin transactions, which then must be signed by each of the participants before being included in a block*. In these proposals the offer isn't really a binding offer, because the participation of both counter-parties is required up to the very last moment. Having offers be binding (sufficient for inclusion) allows the protocol to operate over a decentralized, p2p network with lossy message transmission/retention and occasionally-connected nodes.

* It is possible to do some limited pre-signing with SIGHASH_SINGLE, but sighash modes really are not general enough to handle all the use cases we desire. It was through investigating the problems with SIGHASH_SINGLE that we were eventually lead down the path of adding isolated sub-transactions.

killerstorm, if you're willing to invest in return for 6% of your investment amount as freicoins (current market prices), would you not also be willing to donate 94% of that original amount, and buy up your own coins on the exchange of your choice?

It's the latter - foundation funds are meant to be donated to charities, not used for internal development. I have advocated in the past for infrastructure prizes, but was shot down. In any case, jtimon and I have reclused ourselves from that decision making process, due to the obvious conflict of interest. But I'll bring it up at the next meeting.

Killerstorm, any comment on the content of the proposal? You've been working in this area for a while, so I thought you might have something to say. There's a thread in the developer subforum:

https://bitcointalk.org/index.php?topic=280292.0

Offers are pooled and cleared about every 10 minutes or so, exactly what you're asking for now. Miners are free to enforce a spread by not matching transactions unless there's enough of a crossover fee to to justify the effort. In fact, that would be the expected default behavior if matched exchanges are treated like other transactions - they only get selected for inclusion if they meet the fee thresholds.

You seem to have retracted from the everything-on-the-block-chain position. But specifying some explicit mechanism for aggregating offers and clearing trades is not the correct approach either. In that case you end up mandating the conditions under which one may run an exchange node, ending up with a compromise the fits nobody's needs.

The best approach is to specify what an offer looks like, how they are combined into atomic trades, and that's it. Let competitive pressures determine how often the market is cleared, what minimum fees are required, what matching engine technologies are used, and what latency vs. volume tradeoffs are made.

As far as I can tell, genjix's implementation is neither decentralized nor private, correct? The hard parts are still left to be done.

There is absolutely no reason to put bids and asks in the block chain. You don't need consensus on bids and asks, just the resulting trades. A better model is to broadcast bids and asks, and have miners or other agents only commit matched exchanges. This is the approach we are taking with Freimarkets (and we do so avoiding direct pairwise interaction or trusted third parties, and with off-chain transactions as an option).

The use-a-block-chain-for-everything mentality is somewhat bizarre - a very scarce public resource should be only be used conservatively and when it is absolutely needed.

We have a crowd-fund proposal in the project development thread:

https://bitcointalk.org/index.php?topic=278671.0

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.

No, it has nothing to do with transaction fees. What are you talking about?

No. Don't do it. Give them an authenticated mechanism to request a new payback address.

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:

• 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

The first draft of the whitepaper describing our proposal has been completed. We especially encourage anyone technical to take a look at it and give us some feedback:

http://freico.in/docs/freimarkets.pdf

I wouldn't want to distract with a discussion of Freicoin, or BitShares or MasterCoin except in so far as it relates to this proposal.

Demurrage does not apply to user-issued assets unless the creator opts-in, in which case the rate is selectable and users are just as capable of entering a positive rate, AKA interest. We view the ability to have direct in-chain storage fees or interest bearing assets as a feature, not a deficiency. In my own experience talking to people online and at conferences, most bitcoin users wary of demurrage currency nevertheless look positively at specific applicaitons of demurrage, such as warehousing fees for gold storage, for example. And the value of interest-bearing assets is obvious enough that I don't need to go into it. Well, this is a proposed framework for building specific applications, within which interest/demurrage has a clear use case.

It is understandable to object to demurrage applied to currency (although jtimon and I clearly disagree with such objections), but as a fee currency for this proposal it is in fact useful as it frees the valuation of the currency from speculative pressures, removing uncertainty over future fee costs. It also keeps this new coin from competing with bitcoin, if you view store-of-value as a desirable property for a payment currency.

To your other point, building on bitcoin is a very, very good thing. Not only does it mean that we benefit from all the good work that other bitcoin developers are doing, but it also makes it very easy for other applications in the bitcoin ecosystem to integrate with this proposal. Private accounting servers, for example, are simply bitcoin nodes running their own private chain; any existing bitcoin wallet could be modified to talk to them instead, as opposed to Open-Transactions which has its own completely different API. Further, a separate “holy grail” for integrating the two is not required: bitcoin <--> freimarkets <--> off-chain transactions is simply a special case of the cross-chain trade, something which is already supported by bitcoin, and which this proposal enhances.

And besides, I'm not as convinced as you are that the Satoshi client is so full of problems. Have you looked at the latest, post-0.8 repo? It's actually rather clean, and continuing to improve. Maybe I'm biased as a bitcoin developer myself, but I think it's better to stay within the family.

Hi J.R., I remember speaking to you at the conference about this very idea. Best of luck to you as well.


EDIT: I legally cannot be in a position of making forward-looking statements. I revised this post accordingly:

Excellent question. We are looking for donors. In the jurisdictions we domicile, such direct consumer investments are not yet legal. We want to be very careful to make sure that this project is carried out in accordance with the law.

But with that in mind I will do my best to try to answer your question. There are two general observations that I would like to start with:

• The valuation of a commodity depends on its present or expected future utility. To an extent this is factored into the current market prices, but it an historical observation that unexpected increases in present or future utility result in corresponding and measurable increases in valuation.
• This proposal, if implemented strictly increases the utility of bitcoin (by providing new capabilities) and freicoin (by providing a new role as the fee currency).

I don't think I can say any more about the ramifications of this proposal without making a forward-looking statement, which I am legally not in a position to do.

Any donation, for any reason is welcome. I would hope that people will donate because they like the idea and want to see it happen. But I also think the above observations give rise to three general classes of large, self-interested donors:

• Donors who presently hold a large amount of bitcoin (early adopters, professional investors, etc.). The “return” for these donors is the boost this project may or may not bring to bitcoin in general, and the corresponding decrease to volatility, perceived risk, etc. Particularly if you are holding a significant number of bitcoins, this is something you should be worried about.
• Donors who simultaneously invest in Freicoin. Freicoins are nearly devoid of value today, and the donor perceives a possible outcome in which that the work we are doing will give freicoins near-term utility, boosting their price. I suppose that these donors would perceive pairing a donation with some large BUY orders as something akin to investing.
• Donors who are running a business that would benefit directly from this proposal. A company like Bitstamp, for example, could branch into providing bitstampUSD and bitstampBTC public assets, and act as a gateway for redeeming either. For corporate donors, a few thousands dollars might be a reasonable investment if it opens up millions of dollars of business.

(reserved)

Examples

English & Dutch auctions

In the English auction, the owner of an asset declares his intent to sell by auction, and starts collecting bids of the following form:


When the auction is ended, the seller selects the highest bid and composes a complete transaction:


Since this is a higher-level transaction, the signature of the seller covers the included highest bid sub-transaction.

A Dutch auction is basically the same, but with the roles of the buyer and seller reversed. The seller suggests a price by constructing an offer of the following format:


The seller then broadcasts this offer and waits some period of time to see if anyone takes it. If not, the price is lowered and a new offer broadcast. The seller knows an offer has been accepted and the auction closed when he detects a transaction of the following form on the network:


The first buyer to get a combined transaction on the chain using one of the seller's offers wins the auction.

Note that although a variety of auction types are implementable, this system is unfortunately not expressive enough to manage the ideal Vickrey second-price auction in a trust-free manor. There are, however, implementable cryptographic protocols for doing so out-of-protocol using homomorphic encryption.

Double auction (market/exchange)

This is a generalization of the multi-item English auction. For any asset pairing, an out-of-chain mechanism exists for constructing, sharing, and collecting signed offers of the following forms:


The first offer is a bid of assetA for assetB at a price of 1B/1A. The second offer is the corresponding ask: assetB for assetA at a price of 2B/2A. So long as the bid price is greater than the ask price, it is possible for anyone to combine these two offers together to yield a composite market transaction:


The use of granularity and quantity allow fractional parts of each offer to be claimed, since in general there is no expectation that the offers

Note that although the crossover spread could be claimed as an output, anyone else could take the bids and construct their own matching transaction and claim the fee for their own. We assume that miners will know how to do this, and one way or another the fee is ultimately claimed by them. Market clearing becomes a profitable source of revenue in addition to payment transaction fees.

Transitive trust relationships

By issuing assets representing IOU debts and signing outstanding offers representing lines of credit, standard marketplace mechanisms can be used to execute payments through networks of transitive trust relationships. These payments look just like the double-auction marketplace transactions covered above, except that they typically involve 3 or more asset types.

Baskets currencies and gateways

A basket currency can be issued and fully managed within the block chain. The basket manager issues asset value and then offers it in bidirectional exchange for multiple other assets at a fixed rate.

Gateways are similar to basket currencies: an issuer creates an asset and then distributes it when funds are received out-of-protocol. This could be in the form of a fiat wire transfer, physical deposit of precious metals, or a cross-chain transaction (atomically swapping bitcoin for freicoin, for example). Assets are redeemed by a similar process in reverse.

Off-chain transactions

For ultimate privacy and scalability, off-chain accounting services are preferred. This proposal provides the missing pieces necessary for accounting servers to implement their own private block chains with a secure audit log and without the expensive distributed consensus mechanism, allowing opt-in global consensus only when it is necessary for “cross-chain” (multi-server, or public/private) trade.

To support global consensus mechanisms, a new suite of extrospective opcodes are added, allowing transactions to contain cross-chain conditional dependencies.

---

More examples (including cross-chain transactions for public/private trade) are being written up as part of the whitepaper PDF, and will be posted shortly.

UPDATE: A first draft of the whitepaper PDF is now available for download.

This is a proposal for implementing bitcoin's missing pieces, the holy trinity of user-issued assets, distributed peer-to-peer exchange, off-chain transactions, and the multitude of financial constructs these primitives make possible.

---

Summary:

Off-and-on for the past couple years, Jorge Timón and Mark Friedenbach have been developing an extension of the Bitcoin and (pre-OpenCoin) Ripple distributed protocols which allows any person to issue their own blockchain assets, enables signing of binding offers within a distributed, p2p exchange, and provides the foundation for off-chain transactions using bitcoin-derived private accounting servers and cross-chain trades. You will find the high-level details of our proposal below, plus a short listing of near-term uses, and a few example applications. A more detailed whitepaper PDF (including formal specification and examples) may be viewed here.

The protocol will be deployed to the Freicoin block chain, which will be merged mined against bitcoin. Demurrage prevents competition with bitcoin's store-of-value, the proposal builds on the interest and reference-height features already present in Freicoin, and that community has already reached consensus in favor of the proposal. The situation is ideal for bitcoin as gateways and bridges allow people to transact in bitcoins or the currency of their choice without clogging the bitcoin block chain (the Freicoin maximum block size will expand to accommodate new traffic), and the proposal will be developed as a set of neutral patches which may be applied to any bitcoin-derived coin or private accounting server.

We are seeking $125,000 USD (or equivalent bitcoin) to make it happen. This will pay all of our project and living expenses for the approximately 2 developer-years it will take to implement the core features of the protocol and a testing and deployment schedule, as well as limited travel budget to the major bitcoin conferences where results can be published and stakeholder input received.

Our stretch goal of $175,000 USD will add private accounting servers and associated protocols (off-chain transactions), which we estimate to take an additional 3-6 months to develop and deploy.

The bitcoin/freicoin donation address for this project is:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Public donation address for Freimarkets crowdfund:
1KRabAP1uc179hivEcJA8dCNQ3kC6oU5Av
-----BEGIN PGP SIGNATURE-----

iQIcBAEBAgAGBQJTFLs3AAoJECsa1YSJj/UD9V4QAJZ8zVUD7IKJqNTnelf220Vb
HzMpcetNquOMLsEsJGvQhgSo5IMDqq+1K98wFM5k6cj3GeiAg2gPnRE9N8FMPlmt
5QPNDIkUQhXXropVy/ry89r0WSmbOFG+oNe01i60KqnoQ7ZHPGba1C6SZ8q/Lxmw
bKGaAP6TzZPIPICnncgH3oT/Na4l+r7AAnWaBrNWDuyCR+t2tU/b9TXTiTpTSIyP
3ErlD7DPJMtsOLGmjrT5XfaMoFh5FCBNbQhhNI/hAiacyKwj4iX5o42aET9NZYEO
PGW28kPL6hVO97vrBBo1RAlcOQtKSrKPBeuzqQg4ZIMQdBk1Vesex1hXc3weAqu7
j2DoeX7Fq9YCPnvQ92dHBXF3a1bgN5PLu9d/lIPDptmqA36GsIcjVE/Nmo0bnU/a
6DvrQXZJ62vwwu66pP8PdtDa3U4M8fr4NTRGx1Q0gx/4LRxqLznNSu3RTdWo8ZND
3sA2b3AfOCW0Kyv+6hwE74Mp2gwvcfiPnATQxMUB4qH6UasXFSH5ibcB1JKvhvWA
kX63S3pJKB6HQ5Hc60N0N2BGJeAwvHvllXavKoUCuaS3MbYnu3ZZSkx82b1amJ6p
5F5gfLRk35iRfluz7Dv3EBbN8rm8uuNQd8BEMAAofacKz6CZNj+yxMq4FVAyxhpK
aNoWm8SU3qE2HDrC+o3m
=YiM4
-----END PGP SIGNATURE-----

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. 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 a wide variety of financial instruments.

Together this enables the following sorts of applications:

• 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.

About us:

Mark Friedenbach is a software engineer, formerly a contractor at NASA-Ames Research Center who left to become an independent bitcoin protocol developer. He is chiefly responsible for Freicoin's specific implementation details, as well as later modifications such implementation and optimization of the FIR filter difficulty adjustment algorithm (designed by @galambo). Mark was a speaker at the Bitcoin 2013 U.S. conference, and it is currently engaged in implementing Alan Reiner's Ultimate blockchain compression w/ trust-free lite nodes proposal, work which will continue alongside this proposal if funded.

Jorge Timón is a software engineer with 4 years of experience at Indra, working on big international projects including software for several insurance companies. He co-designed Ripple Distributed Protocol v0.6 (pre-OpenCoin) with Ryan Fugger and explained it and Freicoin at several complementary currency related conferences, a community in which he remains an active member. He proposed and co-designed Freicoin and is currently working on various free software tools for the Freicoin Foundation.

Both Mark and Jorge are advisors on the subject matter of new money systems for the board of the non-profit Lifeboat Foundation.

Single point of control... over that limited supply of coins. 80% of the monetary base, yes, but still finite. (1) Once those coins are spent they're gone. (2) Their movement can be tracked by anybody. (3) If anything funny happened, he market would pull the rug out from under us so fast, there'd be no hope of recovery.

When we conceived the idea of the Foundation in its current form, we were just weeks away from release. Our options were (1) release as-is with 100% miner subsidy and the associated opportunity cost; (2) add a simple, hardcoded budgeting system and issue the coins through non-profits; or (3) spend a year or more developing a fair, decentralized voting system for determining what to do with the coins, which may or may not have worked in its first incarnation. We chose the middle path, but for reference the most championed proposal for decentralized, non-mining issuance is described here:

http://www.freicoin.org/demurrage-should-it-all-go-to-miners-t20-40.html#p354

Are the keys to 80% of the eventual monetary base physically in my possession? Yes. Are we asking users to trust us while we figure out how to start a not-for-profit Foundation and do the distribution legally? Yes.

That's a far cry from a centralized protocol like the fiat banking system, or even lesser claims of centralization like the checkpointing systems that existed in PPCoin or SolidCoin.

Would we prefer a secure, decentralized voting mechanism with incentives structured to provide fair and equitable issuance without undue early adopter bias or vote manipulation? Yes. And while we're at it, I'd also like a pony, a million bitcoin, and to know who shot JFK.