Bitcoin Forum

UPDATE: A first draft of the whitepaper PDF is now available for download (http://freico.in/docs/freimarkets.pdf).

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 (http://freico.in/docs/freimarkets.pdf).

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 (https://blockchain.info/address/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 (https://bitcointalk.org/index.php?topic=88208.0) 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.

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.

(reserved)

(reserved)

Hi guys!

Very pleased to see stuff like this going forward. As you may know, I'm up to my eyeballs doing my own version of some of these features :)

One question: Are you looking for investors or are you looking for donors? I can't tell from what you have posted so far if there is a way for donors to earn money if you are successful.

Best of luck to you! Don't listen to anybody who says you can't do it  :)

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.

Your proposal seems similar to BitShares in many ways with the following differences:

1) you charge a tax, I pay a dividend.
2) your user currencies are effectively bearer bonds, I have no 'user currencies' but I also need no user currencies... though adding them may be an option.
3) you are looking for donations, we have funding.
4) you have some centralized servers which are an interesting concept.
5) you are revamping bitcoin code... we are developing from scratch.

It is interesting to note that your development costs / estimates are higher than mine for BitShares despite similar feature sets.

Glad to see these ideas out there, but perhaps your development team would like to work for us on BitShares?  "With our powers combined!!".  Seriously, if you have talented C++ developers I would love an opportunity to talk with you about the potential for joining our team.

It looks like the race is on between this, Master Coin, and BitShares... may the best technology win!

Hope to see you all at http://www.cryptocurrencycon.com/ where Charles and I will be presenting on what we are doing and hopefully releasing our first beta product for the community to use.

Thank you very much for your support!
We agree that we need some of this features, but as I already told you in other occasions, I still don't understand how are you going to support some of this features on an upper layer without modifying the core protocol (say, binding open orders). But it's good that there's more people working on adding the same features.


To complete maaku's answer...


I would like to add:

• New bitcoin entrepreneurs that need some of this features in place for their business plans to be viable.
  
• Complementary currencies (or barter networks) that want to interconnect their systems and would enhance their current use value by doing so.
• Other business that aren't currently related to bitcoin but are interested in some potential features like the myriad of potential smart property use cases.

I'm not sure I understand this. If you mean Freicoin's demurrage FEE, I have to remind you that it's a free market currency and its users do so voluntarily. Taxes are collected by states through coercion.

In any case, since this will be free software, Bitcoin or any other altchain derived from it that has no demurrage can easily add it. This will be coded as a series of commits on top of Bitcoin and that we will periodically rebase as we do now for Freicoin.


Thank you. To be fair this is inspired in several works by others: Ryan's two phase commit protocol, Jaromil's Freecoin and the theoretical work done by several bitcoin developers (like Gregory Maxwell and Peter Todd) on off-chain transactions (https://en.bitcoin.it/wiki/Off-Chain_Transactions).


Actually we think this is an advantage because it will enable greater collaboration as well as getting the benefits of other people's bitcoin new improvements.


There's always the possibility of collaboration, but we want this to be free software from the beginning and obviously we think our design is the best way to implement all this features. As said we will publish the complete specifications with more examples in the software development subforum soon for peer review.


Well, there's also colored coins and the new Ripple. But, yes, may the best win even if it's not FreiMarkets.


I won't be able to attend, but hopefully maaku can make it. I may go to this one at my side of the Atlantic though: http://theconference.eu/

BitShares is free and open source from the beginning, why do you think its not?

Yes, that is what I mean.  I was using 'tax' in the loosest sense of the word.  Demurrage is a faulty concept based upon faulty economics.

Building on top of the bitcoin source for anything but the smallest of changes will inherit all of bitcoins problems and the ability to do merges will become increasingly difficult.   At the very least starting with a cleaner code base like libbitcoin would set you up with a better design.    This is really the 'windows' vs 'os x' approach to software.   Considering you are starting with Freicoin's system perhaps it makes sense to stick with it.

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.

To be fair, BitShares does implement a 'tax' for unspent outputs that are over 1 year old so that the chain can be pruned.   As long as you move your funds once per year there is no tax (aside from the transaction fee).  Though generally, dividends would outweigh this 'cost' and so it ultimately only serves to recycle value controlled by lost private keys over time.

People are so passionate about their own projects that it is hard to not threadjack and say "But look at what I'm doing! It's so much better!" :)

Presumably we all have a pretty big stake in the success of distributed currency, and if any of us are successful, all of us profit. For that reason, I don't see these somewhat competing ideas as being in cutthroat competition. That said, if somebody is criticizing your approach, and they also happen to run a competing project, take it with a big grain of salt ;)

You won't hear any criticism from me though. I know you guys are smart, and I'm watching with great interest.

Clearly this isn't cut throat... is good that we are all barking up a similar tree, the market will then sort out the best.   It would be interesting to have a conference with everyone and see if we couldn't unify our efforts some, but I suppose NIH syndrome is very prevalent and we each have something slightly different that we are hanging on to.   

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'm very excited to see how this project evolves and we invite you to attend not only C3, but also the december Vegas event and our launch in Tokyo in February. I love the free flow of ideas and the constant evolution of concepts to implementations each with both their blessings and curses.

What I have alway been most passionate about is the long term viability and cryptocurrencies in general throughout the harsh realities of bad actors, regulators and philosophical shifts that could potentially rob the ecosystem of its best features. As we are both in charge of open source projects, I suspect we'll both benefit from each other's code base and development knowledge at some point and of course I suspect the places where we compete will refine our ability to express the best features of our respective platforms.

Keep up the great work and I wish you the best of luck.

Freicoin Foundation gets 80% of all mined Freicoins.

I thought it's supposed to finance further development of Freicoin, why are you looking for external donations then?

Is that because price of Freicoin is too low? (i.e. sum which  Freicoin Foundation is able to donate isn't enough for this development.)

Or is that the case that Freicoin Foundation cannot donate towards this?

If the former is the case, perhaps you can do fundraiser in a different way:

1. Suppose Freicoin Foundation agrees to donate 1 million FRC to this. (Which is only ~1.25% of all funds it will ever get.)
2. If your fundraiser goal is $125k, then it works when exchange rate is 1 FRC = $0.125 USD.
3. So you just ask investors to buy freicoins up to that point. Currently it is equivalent to FRC/BTC being 0.00125.  Which is not absolutely ridiculous because it was traded around that price when it was first introduced on vircurex.
4. Perhaps you can offer these investors a deal to sell them Freicoins for 0.00125 BTC each even if market is above that. (I.e. offer a forward or call option contract.)
5. Investors might see returns on their investments when Freimarkets are implemented.
6. I don't think it costs that much to bump FRC exchange rate upwards... Currently you need only 87 BTC to eat all asks below 0.00125 on vircurex... Of course, more asks might appear in process, so don't do that at home.
7. In any case, investors find buying something much more palatable than donating towards something. Even if investors need 5000 BTC to finance this endeavor this way, it is still easier than to collect 1250 BTC in donations.

HTH

EDIT: Disclosure: I bought some Freicoins, but I'm not going to donate them to you guys, sorry.

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 (http://freicoin.freeforums.org/foundation-infrastructure-prizes-input-needed-t196.html), 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

It seems to me that for that funding alternative to work, freimarkets should be somehow exclusive to Freicoin, which is not. Unless we hide our code during development (and the plan is to have in on github from development day 1), any existing chain (or a new can be created) can deploy it at the same time (or even before) Freicoin deploys it. Therefore selling FRC as "the way to invest in freimarkets" wouldn't be a very honest offer.
Opencoin used something close to what you're proposing and now they have a conlfict of interest because if they open source the ripple servers today, xrp price and their whole business viability could be questioned.

By selling FRC into existence as you suggest we would also be capping FRC's price.
And more importantly, the foundation would be making very direct decisions on the money issuance, which is precisely what we're trying to avoid with the several discussed issuance programs.
The foundation was NOT created to fund Freicoin development but because although proof of work is a great security solution, we think is a wasteful issuance mechanism.
And we think we can do better than btc and xrp when it comes to issuance: it's a field full of potential innovations we want to explore.
You can see the foundation's web under development to have an idea of what issuance programs we have in mind for the short term (the numbers are made up and should be discussed):

http://foundation.herokuapp.com/
https://github.com/freicoin/foundation

Unfortunately we're not a legal nonprofit organization yet and we want to avoid legal concerns so at the beginning only nonprofits will be able to receive funds. That excludes the Freicoin Foundation itself.
But we plan to list the Freicoin Foundation (the "bag" for its operating costs, separated from the "issuance bag") just like another nonprofit and applying the same rules.
Maybe if Foundation's bag becomes big enough it can pay us for
development (instead of us paying for hosting and domains), but I
would really like to be able to have them separated.
Some people criticize bitcoin because it's "anonymous and for
criminals" (like if criminals weren't already served with the usd). I
like to answer to that "I wish my government could be as transparent
as Freicoin will allow the Freicoin Foundation to be".
And I want to remove the will from that sentence.
This can be a great tool for attracting other movements to
cryptocurrencies and there's lot of open possibilities: SCIP-based
curecoin, mining donations, open knowledge funding through
crowdfunding...

I also happen to believe that Freimarkets it's interesting enough on
its own to get funded without any promised return beyond the free
software delivered. Many free software projects have been funded this
way (or very similarly through bounties) and there's plenty of
interest for some of the features offered, for example, p2p exchange
and off-chain transactions. Supporting arbitrary interest-bearing
assets, having the orders outside of the chain, keeping bitcoin's
inputs/outputs approach instead of less secure and private account
approach and supporting off-chain assets are already huge
improvements over Ripple in my opinion. Maybe some invest in this to
protect their previous BTC investment because they see XRP as a
competitor and this would bring all Ripple functionality and more to
the blockchain.

The complementary currencies community is also working in an
intertrading protocol and private chains exchanging assets between
them would give them just that.

There could also be some interest in a technology like this from certain
industry sectors related to smart property like e-gold, security
locks, tickets, agorist stock exchanges...

There's a lot of actors who could invest in this selfishly even
without any promise of return. Maybe not one of them can afford to
fund it on its own, but if they all join forces I would say they can
fund this 5 times or more.

Isn't private donations the funding model for colored coins as well?

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?

Well, it would take a while for me to review this...

One the first glance, one thing I didn't like is "binding" orders. If they can be double-spent, they aren't really binding...

Mempool rules are not enforced, they depend on miners being good guys and running non-modified node software.

You know about replace-by-fee patch, right? https://bitcointalk.org/index.php?topic=179612.0

I don't think that mempool rules will be relevant in future, as they go against what game theory suggests.

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.

This is funny... Suppose Freicoin is wildly successful, and total monetary base is equivalent to 10 trillion 2013 US dollars.

Then miners get 500 billlion USD worth of Freicoins each year, and, due to the way mining economics works, they'll burn equivalent amount of energy (and pay for amortization of equipment). This is wasteful on epic scales.

On the other hand, Freicoins which Foundation gets now are worth pennies...

Do you see what I'm talking about? IMO it would make much more sense to give all created money to miners, but send 80% of demurrage money to Foundation.

This way you could redirect money miners are going to spend on electricity to charity... Potentially that might be a large sum each year.

But you did exactly the opposite...

Well, Freicoin economics in general looks completely alien to me. I guess it works in mysterious ways... Good luck with that.


Yes, but nobody have offered anything on scale of $100k so far... If they did, we could actually hire people and get it done. Instead, we have people who work in their free time... As you can guess, progress is kinda slow.

However, colored coins require much less work than Freimarkets.

OK, this makes sense.

But I don't think that "binding" is the right word here. Perhaps you could describe such orders as 'autonomously executed' as they can be executed even if one who submitted them is offline. But "binding" implies that somebody is forced to stick to his order.

I guess you misunderstood me, it's not about buying Freicoins below market price, it is about bringing market price up to that level... One person cannot do that, but you bring investors' attention to it and explain how Freimarkets can make Freicoin much more useful than an average alt-coin, investors will be eager to invest into the next big thing...

Jorge mentioned that alt-coins can simply copy Freimarkets, but it's not so simple... It really matters which coin is endorsed by developers, as that one will, likely, get all the necessary maintenance, latest features, security fixes, etc.

Technically speaking, it could work without funding from Foundation, but we get a prisoners' dilemma-like situation. For each individual, it isn't rational to donate anything, even though if everybody donates a bit all would benefit from it. So you gotta depend on altruism... Or use a mechanism like Foundation, which you cannot use.

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.

I've updated the crowdfund goals in the OP to be denominated in fiat, since ultimately that is what we require (living expenses, etc.) and the wildly fluctuating price of bitcoin makes a bitcoin-denominated goal a moving target.

We are seeking $125k for the development of Freimarkets (including salaries of full-time developers, operational costs, and conference travel expenses), and an additional $50k for the development of private accounting services.

So far we have received about $4.5k in donations, which is enough to get started on the first components, but on its own not enough to make Freimarkets a priority over other our other projects we are currently working on.

reserved

It is true that the kinds of stuff you are hoping to develop would be nice to have, but since well-funded teams are already working on such stuff does it realyl make sense to blow antoher huge wad of money on funding yet another team to diverge from all the already funded projects that are already working on what to and end user presumably is much the same thing?

If the already funded teams fail somehow then maybe looking around for a different team might make sense, and if the specific implementation-details of how to build such a thing fails then again considering funding yet another different way of accomplishing the same goals might make sense.

Maybe if I had invested in one or more of the others and it was truning out to be massively lucrative i might consider investing sme of the loot I gained from the success of bitshares or Mastercoin or whatever into yet another similar project but as far as I can tell at that point I would already have these functionalities.

Meanwhile if it is really the case that this team needs money, maybe we can hope that they will take a job with one of the already-funded teams whereas if we throw money at them now that probably just makes them even less available to work on the projects we the people or we the community or whatever have already thrown huge amounts of money at toward the same goals...

In a way it seems not all that different from the "yet another altcoin" craze. How many more alternate distributed exchanges are we supposed to fund all at once fragmenting the resulting markets, or is some way of having them all work together on globally integrated orderbooks also part of the plan?

-MarkM-

I've been thinking about this (https://bitcointalk.org/index.php?topic=2910) long before Ripple.com even existed (https://bitcointalk.org/index.php?topic=3557).
Ripple.com itself has several important design flaws, but much of the p2p exchange noise has only come after them.
So I don't feel we're diverting resources as you @markm suggest. Maybe we should have tried to get funded before having a design we were fully comfortable with and should have rushed to promise people huge returns like the rest did, instead of asking for donations to implement free software anybody can benefit from, donors or not. But I believe the best design will prevail independently of the funding model.

Mastercoin (in its current form) is even less scalable than regular colored coins.
Bitshares document looked like a random mix of the latest fuzzy altcoin proposals coupled with a great deal of ideology and economic dogmatism. They got funded and then they create protoshares as another funding mechanism, also spreading myths like "anti-ASIC pow algorithms can exist and are better than SHA256".
Honestly, I'm not following that very closely because it's hard for me to take it very seriously, despite the funding they can have.
Mastercoin has also a great deal of funding, but as said their current design is not scalable.

Our design is there for any of those projects to implement if they want, we're happy to clarify and discuss any detail of the design.  
If they fund this campaign they will also be able to use the resulting code on their own projects, but that's for them to decide since is their funding.
I don't see how our design can obstruct these other projects in any way.
We believe that everything our design offers is necessary: off-chain assets, ripple-like transactions, interest-bearing assets, indivisible tokens, options...
And we also believe our design is the best for the task.
That's why we want to implement this design and not another one. If other projects are interested in helping us, that would be great, but we don't chose that part.

So the main contendors I've seen are Ripple, Mastercoin, BitShares, and the general category of non-forking coin coloring schemes. None of these provide the complete feature set of Freimarkets, even in combination.

Ripple is not as decentralized and trust-free as OpenCoin / Ripple Labs would have you believe. It also suffers from technical and arbitrary implementation limitations which prevent it from being used in higher level applications outside of the forex and payment applications its creators are pushing. It is hindered by using a ledger, a heavyweight account system, and a host currency which is awkwardly injected in such a way as to making using the system expensive, a phenominon I call "awkward monetization."

Mastercoin is a completely unscalable solution. It couldn't even meet bitcoin's current level of activity, let alone a future where a million user-ussed assets are traded daily. Its problems are fundamental, and unfixable without completely reworking the design from the ground up. It has many, many other issues ranging from trivially easy to pull off of double-spends to complicated self-balancing mechanisms which have not been peer reviewed and not proven to work as advertised. But the scaling issues are an unfixable non-starter.

BitShares suffers from numerous technical problems which artificially limit scalability, functionality, and security. In too many places it hops on the "me too!" alt coin bandwagon without adequatly considering the associated costs of these poorly thought out "improvements." It's proof-of-work system is broken. It's order book system is bloated and inflexible. Assets are very heavyweight and a limited number per-chain. When I last looked at it I was unable to figure out how to do transitive transactions.

Colored coins are the only alternative who's proponents have spent considerable time working out things like SPV modes of operation, a critical aspect of scalability. The first Freimarkets prototype designs were in fact colored coin proposals as we tried to find a way to implement distributed ripple protocol over vanila bitcoin. However we quickly discovered that this was/is an impossible task, and found ourselves forced to implement new validation rules to get that and other funcationality and security we desired.

Colored coins using ordinary non-forking bitcoin suffers from some serious limitations. The scripting language and transaction format is not powerful enough to do things like binding offers or granular redemption. These limitations plus the lack of new opcodes makes it difficult if not impossible to do higher level applications like auctions, cross-server trade, or derivatives/options. (Since the validation rules of bitcoin are not extended to be color aware, you can't be sure that an offer will be matched with the color you actually desire. Nodes have to stay online to participate and can drop out at any time, so now you start worrying about DoS costs and reputation systems...)

Now there are also things which Freimarkets does which no other proposal here does, even inadequately. We provide generalized mechanisms for KYC compliance & authority delegation. We provide an integrated off-chain solution and tooling for mutual coordination of multiple private servers. We provide a mechanism for binding partial transactions which allow participants to construct and sign just the portions of a transaction that concern them. And we do all of this in a carefully designed way that enables access by lightweight nodes and the same scalability properties as bitcoin.

So no, I don't think of this as "yet another altcoin" or something substitutable by any of the above mentioned proposals. I have been approached with employment offers by both BitShares and the Mastercoin foundation and declined, because what Jorge and I are doing here can't be replicated in those frameworks without starting over from scratch. Jorge and I both firmly believe that in the long term people will use the framework judged to be the best on technical grounds, even if it is not the first developed. Scaling issues, security failures, and limited functionality will drive people to the more advanced protocols, in time.

Am I frustrated by the lack of interest? Yes, of course. But the things that are really worth doing are rarely recognized in that way at first.

A big fan of your previous work (i.e. Freicoin).

What specifically is in the Mastercoin specification that makes it unscalable?

I agree that the Bitshares specifications are an incoherent mess.

Regarding Colored Coins,  why can't arbitrary data be placed in the scrypt block instead of refactoring the transaction format?

You need to scan almost the whole blockchain to validate Mastercoin transactions. Obviously, thin clients can't do that...

Are you serious?  I know that miners can't check the double spending that happens with Mastercoin, so that responsibility goes with the receiver of the coins?

With color coins, you have to traverse the address chain to see if it ends up at the colored coin genesis transaction.

With mastercoin,  which transactions does a client look at to verify this?  Is there a transaction chain anywhere?

With the Freimarkets proposal,  is there a need to traverse the the chain to the origin transaction?

Yes. Isn't it obvious?


Yes, one needs to scan transaction history for a particular color. Of course, it is possible that he needs only a fraction of the whole history, but in the worst case he needs all of it...

Which is why in the long term we either needs Freimarkets, or some alternative solution, possibly SCIP.


With Mastercoin, one needs a list of all Mastercoin transactions up to the transaction in question. The only way to obtain it is to scan blockchain from the first block which has transaction sent to exodus address to the block which includes the transaction in question.

Some people think that it's possible to obtain a list of Mastercoin transactions without scanning the blockchain, but, actually, it is impossible to make sure that it is the correct list: attacker can simple withhold information about some transactions to perform a double-spend. There is no way to check whether list is complete.

(Well, aside from magic SCIP.)


As far as I know, SPV clients do not need to check transaction history.

SCIP ?

http://www.scipr-lab.org/

For SPV proofs you need the history tracing colored coins back to their definition transaction. You do not need to store the history of every input back to genesis, so there isn't a combinatorial explosion of history, but it's still a large concern. When you first create a colored coin definition, proofs are problably about a kilobyte or two in size. Each time they change hands the proof grows by the size of the transaciton plus a few hundred bytes of metadata. So coins can change hands a few dozen or maybe up to a hundred times before the proofs start to get unweildy, although one's tolerance probably depends on many factors.

You could have an online issuer that every so often creates new colored coin definitions pegged 1:1 with the old coins, and operates an exchange to trade in old heavyweight coins for fresh new ones.  This works, barely. It's very much non-ideal, but it's also as far as I know the very best you can do without forking bitcoin. Tons of credit goes to Alex Mizrahi, Meni Rosenfeld, and others who have pushed this concept as far as it can go.


Alas, there is no real magic in this world. SNARK systems hold out the promise for a compact proof that doesn't require the entire block chain to validate. But the downside is that creating SNARK proofs is a very, very computaitonally intensive process. I think it's an open question in what way SNARKs will end up being useful in the bitcoin ecosystem, for this reason.


No, by incorporating coloring into the validation rules, Freimarkets is the same as bitcoin in this regard. If a transaction has made it into the chain, you can assume it and its attached coloring is valid with SPV level of security. If/when commitments of the utxo state are added to the coinbase, you could use those indices to check validity and coloring as well. So proof size remains small and relatively constant over time.

Curious,  what would be the minimum amount of changes to Bitcion (based on the Freimarkets proposal) to implement the functionality of Colored Coins?

Colored coins doesn't require any changes to bitcoin. That us rather the point.

What I meant was, what would be needed to incorporated into the bitcoin rules to ensure that colored coins are valid without the need to traverse back to the root transaction.

Well..

You have to put asset definitions on the chain, so that there is a deterministic process for figuring out which coins definitions exist. Then you construct a normative UTXO index with color annotations.

But if you're going to be making changes to bitcoin's validation rules, then you might as well solve other problems that colored coins have, such as a lack of binding signatures on orders. So you start making changes to support these as well since why not? you're forking anyway. Then you notice that there isn't good reason for many of these coins to be traded on the public chain. If you have a centralized issuer, it is nearly the same level of trust to have a centralized clearing house for transactions, and there are many positive benefits to that architecture. But then you need to add primitives for these off-chain private servers to coordinate via the public chain, 3rd party time stampers, or mutual observation. Etc.

If you've read the Freimarkets spec, this should be sounding familiar. It's exactly the thought experiment which led to where we are.

Freimarkets is a locally minimal set of changes to the bitcoin protocol to directly and efficiently support colored coins and their myriad applications. There are probably other possible designs that are equally minimal or perhaps even a little more so, but I think we're pretty close.

TL;DR The answer to your question is "Freimarkets".

The reason I ask for a 'minimal' spec is that the Freimarkets spec was proposed a couple of months ago and I am not sure if you made any progress implementing the spec (or receiving the required funding).  So I am wondering if there is a quick and dirty fix that does not require the development resources you requested, but is able to get say 80% of the final functionality.

Meaning,  if the scope of Freimarkets is reduced (say remove subtransactions),  what would be the smallest scope that can be defined such that it is easy to implement?

I'm afraid the minimal set of changes for in-chain-validated colored coins that Mark already explained here:


...wouldn't get you nowhere near 80% of the functionality, and it's not a "quick fix" neither.
Without sub-transactions you don't even have open signed orders so traders would need to connect directly during the execution of the trade, which is a big disadvantage.
Furthermore, we don't know the full potential functionality that sub-transactions add yet. When Satoshi designed bitcoin's scripting language he didn't knew what the current list of potential contracts (https://en.bitcoin.it/wiki/Contracts) would be like.
In the same way, nobody knows all the uses the freimarkets extension could have.
What we know is that from the about 10 use cases described in the example cases of our doc, 10 of them make use of sub-transactions, for example, and many of them also use validation scripts (another extension, a script that needs to be valid for the whole transaction apart from each input's script).
Indivisible tokens may seem optional at a first glance too, but they're the base for implementing inflatable assets and authorized assets, needed among other things to implement KYC compliance for those issuers who need it (that can include local currencies which operate with special custom rules defined by their respective communities).

Finally off-chain assets and their inter-operability is the best answer we have for ultimate scalability of the whole network of assets.
Hopefully Mark's work on a committed UTXO soft fork will greatly help improve the scalability of bitcoin itself and reduce the trust for SPV nodes.
But as Peter Todd and others have explained many times, there's a trade-off between in-chain scalability and centralization and there will always be a limit to the scale of in-chain validation if you don't want to compromise the p2p nature of the system.
So even if we separate private chains in a second phase, we really believe its development is of critical importance.

Given the current funding situation,  what is the ETA for a prototype of the Freimarkets proposal?

Are we talking a few months from now, a year or so, or never?

It isn't a problem. There are other ways to enable decentralized exchange.

It looks like your plan is to provide it all in a monolithic package, while we aim solve it outside of the scope of the core protocol, which gives a lots of room for different approaches.

If you implemented only "color" validation without the rest of changes, Freimarkets could be a drop-in upgrade to colored coins: if we'll be able to provide decentralized exchange capabilities for colored coins (and I'm confident we'll provide them in near future), one could simply replace transaction encoding without changing the rest of the protocol, and thus benefit from fast validation.

But if you're going to implement the whole thing or nothing, it might be late at the party... There are many developments in this area, so it is possible that in a year or two Freimarkets won't offer significant advantages over other approaches.

.
First, I am unconvinced that reputation-based systems can offer the same feature set or scale as well. Second, it would be a fundamental step backward philosophically. Bitcoin puts you in control of your coins; the type of system you are developing would leave you at the mercy of counterparty risk. I firmly believe that there is value in making contracts directly enforceable, on the other hand.

I do not know of any other proposal at this time which offers, for example, binding signatures on partial transactions.


We are not working on Freimarkets right now due to a lack of resources.

Prognosis not good then.  :-(

Killerstorm,  what is the ETA for colored coins?

I'd like to see more information about this: practical difference between Freimarkets and a hypothetical system without partial transactions (or however you call it). In what situations do we see this difference? What kind of guarantees Freimarkets will allow which alternative system can't?

I hope you understand that I'm not just wasting your time, I genuinely want to learn more about this. FYI I've just donated 5000 FRC to this project.


You're in control of your coins only after transaction is included in the blockchain. Before that, you can be subject to double-spends.

I see no difference in case with decentralized exchange: there is no certainty before transaction is included into the blockchain.

So, philosophically, it isn't different from Bitcoin.

Two weeks(tm). No, really, I believe we'll release a usable version in January.

Thank you for your contribution, Alex. It's also good to hear that we will have regular colored coins soon.
Even if we got all the funding from day 1 of the crowdfunding, our development estimates are around 1 year, so having simpler colored coins schemes working first was completely expected and nothing bad in my opinion.
Hopefully this create some usage and more understanding on the more generalized p2p accounting that colored coins represent.
Maybe some infrastructure or at least clients parts are reusable by freimarkets.

Now let me try to solve your doubts on the additional counterparty risks Mark means.
Say Alice wants to sell 10 AAA for 5 BTC, only in complete AAA units (doesn't make sells smaller than 1 AAA).
In Freimarkets, she would create a sub-transaction with 10 AAA as input, 5 BTC as output to an address under her control and granularity set to 10.
She broadcasts it to the network, turns her computer off, and goes to sleep.
Bob want's to buy 3 AAA for 1.5 BTC. If he has Alice's sub-transaction, he can just complete the transaction properly and broadcast it to be included in the chain.
Even if he hasn't seen Alice's sub-tx, Bob can create his own with 1.5 BTC as input, 3 AAA as output to an address under his control granularity to 1 (all or nothing), turn his computer off and go to bed too.
Any miner that has both transactions can form a complete transaction with both to claim any fees they have included or the difference between prices if there were any.
All this process was completely trust-less and Alice and Bob didn't needed to communicate directly with each other at any moment.

Now let's compare with the same trade with colored coins.
Alice publishes her offer (without signing anything) in some network created for this purpose.
She can't turn the computer off, because she's waiting for someone to connect with her to perform the trade.
Carol connects Alice sending "I will buy the 10 AAA for 5 BTC as you're requesting". Maybe she adds "I proof that I control and address containing 5 BTC" so that Alice can trust her more.
Alice says, "ok, this is the full transaction with my signature, when you add yours, the transaction will be valid and can be broadcasted to be included in the chain"
Carol disconnects.
Now Alice doesn't know whether Carol has received it and has intention to sign her part and broadcast or this was just a simple DoS attack.
After 3 blocks Alice is tired of waiting and decides she will look for another buyer. Maybe she double-spends the 10 AAA first to make the previous transaction invalid.
Maybe she downvotes Carol in a reputation system of some sort (maybe Carol actually lost her connection, who knows).
So Alice publishes a similar advertisement again.
Now Bob connects to her with his offer: "I want 3 AAA for 1.5 BTC".
Alice prepares the transaction, signs it and sends it to Bob.
Bob signs his part, broadcasts and the trade is done.

Carol's attack is not the end of the world at all, but there's more inconvenient differences.
If Alice was really tired and wanted to go to bed, some software could have taken these decisions for her, but she can't turn the computer off.
That won't be a problem for many people, there's even individuals that run their own mail servers at home.
But others will want to leave opened orders for when they are off-line, delegating that to an specialized service.
Alice would need to give them complete control of her 10 AAA to that service, that is, "deposit her 10 AAA in the service's web".
Bob could trust a different company and still make the trade, but trusting a service like this greatly reduces the "trustlessness" of the whole thing, as these services could just run with the money just like mail servers can read your unencrypted mails.
Of course holding your balances implies knowing your balances as well.

But this is only the most basic case and as stated earlier 10 of the 10 example use cases in the doc make use of sub-transactions.
Take, for example, the option contract. It may seem a little bit confusing, but 100% trust-less options isn't an easy problem.
As far as I know, there's no solution for them using order-based colored coins and I think all proposals I've seen for trust-less options required a new special option contract message with special structure and validation rules in the chain. Instead of just sub-tx and validation scripts (both generic primitives widely used by other use cases in the docs) like freimarkets.

Well, I hope this helps you see the advantages with sub-transactions, but don't hesitate to ask any further questions.

Thank you, Jorge. So, if we consider only simple trading (without options and such), difference is largely in ability to execute orders offline, right?

Well, I don't know whether this feature is important. It is certainly might be convenient to be able to execute orders offline, but I think decentralized exchange is usable (and useful) even if it functions only as long as all participants are online.

BTW some limited form of offline order execution is possible with colored coins. For example, using bitfield-tagging scheme proposed by Peter Todd: destination output(s) are specified in inputs. Thus it is possible to create a partial transaction which sends colored coin from input_0 to output_1, while output_0 has the requested payment. Input_0 is signed with "SIGHASH_SINGLE | SIGHASH_ANYONECANPAY" hashtype specified.

Buyer creates a complete transactions buy adding payment as input_1 (which he signs) and output_1 (which receives the colored coin).

Note that it is only possible to create sell offers ('asks') through this method.

As for options, it is trued that you can't do them with colored coins alone, but it is possible to do it using contracts ( https://en.bitcoin.it/wiki/Contracts ). Let's consider call option, for example:

1. We assume that Alice and Bob know each other's pubkeys and can communicate indefinitely long.
2. Alice creates a transaction which sends her colored coin to 2-of-2 multisig script, but doesn't sign this transaction. (Let's call it txA)
3. Bob creates a transaction which sends his bitcoins to 2-of-2 multisig script, doesn't sign it either. (Let's call it txB.)
4. Alice and Bob together create a call option contract transaction: it spends colored coin output from txA, sending it to Bob's address, it also spends txB's output, sending it to Alice. (Let's call it txC.)
5. Alice creates a transaction which spends output from txA to Alice's another address, and has nLockTime in future (e.g. a month from now). Let's call this transaction txA-out. Both Alice and Bob sign it.
7. Now Alice can sign txC.
8. Alice signs txA.

Three scenarios are possible:

1. Bob wants to exercise call option. To do this, he signs and published both txB and txC.
2. Bob wants to spend his money, he just double-spends txB's inputs.
3. When option expires, Alice can get her coins back by publishing txA-out.

I've left several niceties (premiums, early exit for Alice) as an exercise to the reader. :)

This is less than ideal because Bob's money is locked for as long as he wants an ability to exercise an option. It's possible to use the trick with SIGHASH_SINGLE I described above to avoid this problem, but it works only for CALL options.

Yes, if we consider only simple trading (without considering any of the other [more than 10] use cases described in the doc), the main difference is that sub-transactions open the door to orders that can be executed without you being online.
That also closes the door to potential (not unsolvable) DoS attacks like the one Carol does in the previous example: she does it once, but she could had done it ad nauseam as well.
But maybe being online all the time stops being the inconvenience we predict and people also start to run their own mail servers.
Not having to be online was, in any case, the main advantage of ripplecoin over 2PC distributed Ripple (at least for "IOU-trade-chain" use cases). Maybe that's why I give it that importance.
Another basic thing is granularity vs all or nothing.


I read something about an alternative approach to order-based
coloring with some advantages at bitcoinX mailing list. And although
it sounded interesting I didn't went into too much detail.
Where can I read more about this?
Is chromawallet opting for this approach or order-based coloring?


I guess you mean an "ask" in AAA/BTC, which is the same as a bid in
BTC/AAA.
Please, don't use that terminology as it is confusing.
What's the ask in AAA/BBB ?

If the trade were AAA/BBB, anyone could get the AAA for uncolored
satoshis instead of the wanted BBB.
So what you really want to say is that "it is limited to offers in
which colored coins are offered in exchange of the host currency (BTC)".

But back to the "basic freimarket without sub-txs" discussion, an
approach similar to this one could work generically without being
online and without sub-txs. The main difference being the absence of
granularity, which can be simulated by bloating the chain with N
smaller offers instead of a single sub-tx.
So I correct my answer to the first question: without considering off-chain interoperability, options or any of the other use cases, if we only consider only the most basic p2p trade, the main advantage of sub-txs is granularity in the orders.



The premium is a critical part of the option. There's no reason for
Alice to give that trade privilege to Bob if she's not getting a
premium in return.
Making the trade between the premium and the right to trade atomic is
the hardest part of the problem, not just a nice addition you can skip.
Early exit for Alice just means the option is worthless.


Again, a CALL in AAA/BBB is a put in BBB/AAA. So although I'm not
sure I understand this limitation, it seems to me you're not being
generic enough.


So the first transaction signed by both parties is txA-Out.
After that Alice can sign txA more or less safely (if we forget about
Bob "DoS-ing" Alice by always making her wait for the lock in vain).
txC can in fact be signed safely from the beginning (not in step 7)
since it depends on txA and txB, which don't exist in the chain yet.
I miss why txB has to be sent to a 2-of-2.
Once txA is in the chain, Bob can sign and broadcast txB at any moment,
followed by txC.
So I don't see the need for Bob to lock his funds.


There's the 4th option mentioned that Bob is not interested in
actually exercising the option, but only limiting Alice's capacity to
trade properly (and make her spend fees) by continuously making Alice
wait for the 3rd option. Until Alice gets bored and stops to try to
trade options.

So in summary, comparing my approach to yours:

1) It makes sense for Alice because she receives a premium in
   exchange of the trade privilege for Bob.
2) It is secure for Alice, who can't be "DoSed"
3) It allows the option contract to be in the form of "up to 100 AAA
   for 100 BBB" instead of "100 AAA for 100 BBB, all or nothing".
   That is, freimarket's options are more flexible.

This is forgetting your "Bob locks his funds" limitation, which as
said I don't really understand. Bob should never sign txB before
having txC signed txA in the chain unless he wants some extortion
from Alice, since there's no txB-Out.

First of all, let's note that the problem is actually not with fake exchange proposals, but with fake offers: we could simplify the protocol and require Alice to include her txins with the offer. In this case Carol would post a partially signed transaction, and will be left at mercy of Alice who can either make a fully-signed transaction, or ignore it.

Freimarkets kind of eliminate the problem with fake offers, as offers are sub-transactions and are already signed.

But Alice can still disrupt the exchange with double-spending: when she sees that somebody made a complete transaction out of her sub-transaction, she will double-spend her inputs, thus making exchange impossible. The effect is the same as with fake offers DoS attack described above: offers are seen, but cannot be executed. (I assume that Alice can perform this double-spending attack with high probability of success via network-level shenanigans.)

Thus if you want an exchange which has more stable behavior, you still might want some kind of reputation system or double-spend-prevention service even if you have sub-transactions.


I don't think that that it is a same thing... Smartphones are, essentially, online all the time, they can receive push notifications and such. Somehow it doesn't inconvenience people.

Although, more realistically, trader will keep his laptop open for 8+ hours a day (because he uses it), and execution of orders is possible during that time. 8 hours a day is good enough. In fact, that's how exchanges like NYSE work, they are not available 24h a day.

Having an ability to get your offers filled 24h a day might be better, but not always: some catastrophe might happen over night, when you're sleeping, and you'll buy some worthless securities.

So my point is, offline execution is a useful feature, but not critical.


I see, it might be really important for some use cases.


We haven't decided yet, I'll post more information about these two approaches on the bitcoinX mailing list in a couple of days.


Yes. I guess making Bitcoin a special kind of an asset is good for people who invested in Bitcoin, so this limitation might be seen as a feature. :)


Hmm, interesting... Well, you can partially address granularity problem by publishing many offers of different size which use same inputs, e.g. 100, 50, 25, 10, etc. This will reduce blockchain bloat, but isn't same thing as proper granularity, I guess.

By the way, did you consider the fact that extra complexity brought by advanced features like sub-transactions and such might lead to higher chances of having critical bugs in code? Many feature in Freimarkets proposal are far from trivial, so it is a serious concern, in my opinion.

Well, I just wanted to outline the general idea, not to describe a concrete recipe. Here's a protocol which fixes problems you mentioned:

1. txAB has inputs from both Alice and Bob, sends coins to 2-of-2 multisig, additionally pays premium to Alice
2. tx-call executes the call option, is signed only by Alice
3. tx-timeout returns coins to original owners after a timeout, is signed by both parties
4. tx-cancel returns coins to original owners, is signed only by Alice

Parties sign tx-call, tx-timeout and tx-cancel first, and after that both of them sign txAB. At that point Alice receives the premium.

If Bob cancels option early, Alice also receives her coins early, but she cannot do it on her own.

It is possible to provide partial execution/partial cancellation by signing many different versions of transactions, essentially a tree. For example, suppose Alice agreed to sell 100 AAA for 100 BTC. Bob might want to get 10 BTC out of this, so he publishes tx-cancel-10, and then other branch of transactions is in effect: tx-call-90, tx-timeout-90, tx-cancel-90.

This tree can be pretty big, but it is hardly a problem, as only part of it is included into blockchain, the rest is just shared between Bob and Alice. People routinely send each other 10 MB photos, and a lot of different options can fit into 10 MB of data.


I think I've addressed all issues, although #3 can be a bit of a problem.


Well, this kind of call contract I described requires concrete coins, so Bob has to provide some concrete coins, and avoid spending them until contract becomes irrelevant. He can always spend his coins, but in that case contract is canceled.

If contract is a partial transaction (SIGHASH_ANYONECANPAY), then there is no need to reference concrete coins of Bob, which is definitely better.

So my conclusion is:

1. we can do something useful with colored coins
2. Freimarkets-lite (i.e. Freimarkets without sub-transactions and other advanced features) can be significantly more useful
3. full implementation of Freimarkets is definitely even better, and it removes some complexity from the client-side implementation, but it makes cryptocurrency protocol more complex

Well, who can attack depends on the exact protocol. I was assuming
that Alice published the offer and also sent the partial transaction
to Carol for her to confirm.
If in your protocol is the counterparty and not the publisher of the
offer who sends the partial transaction, then the publisher is the
attacker: Alice would publish an offer and then collect a ton of
partial transactions that she never completes.
And by the way, including the txins with the non-binding offer
doesn't help.
You may need reputation, external PoW or something else to solve this DoS.


Double-spending the order is at all lights equivalent to a cancel
order button on a centralized exchange.
Are centralized exchanges that allow users to cancel their opened
orders flawed? I wouldn't say so.
Are centralized exchange that allow to place fake orders which produce
many fails when another user tries to fill them flawed?
Yes, I would say so.

If my fulfillment of Alice's order gets into the chain before Alice's
cancel, she cannot do anything. For some reason you're assuming that
Alice has greater capacity than me to broadcast her transaction to
miners.
Even if that's the case, you're not halting me from trading, that's
just how this system works: it takes some time to confirm
transactions.
I could even fulfill Alice's offer and another similar offer at the
same time with the same inputs. I would broadcast it and I know only
one of them can get into the chain, but maybe I don't care.
In that case, if Alice cancels her order and it arrives to miners
earlier (or with a higher fee) than my fulfillment would become
invalid and only my other fulfillment can get into the chain.
Similarly, Alice's order cancellation becomes invalid if my
fulfillment gets into the chain earlier, as she probably was
re-claiming all the funds in the input and now it only has what I
haven't buy.
If you donate to 2 different nonprofits with the same funds, only one
of them will get into the chain: that's not an attack to yourself, is
just how the system works.


That's what I'm saying maybe we're not predicting accurately. Maybe
we're wrong.
But you missed my analogy. Why do you think people don't run their
own mail servers on their smartphones despite "having them online all
the time"?


2PC Ripple is almost equivalent to Freimarket's private server in
which Ripple IOUs users can:

1) Run their own private server, like their own mail server, and have
   it always online.

2) Trust another private server.

Much of the value of doing the IOU accounting in-chain is precisely
to be able to go off-line without trusting anyone.
That's my main point rather than it being critical for
old-Ripple-like uses.
But as said sub-tx have many other uses.


Cool, thanks. Having binding orders, even with some limitations, is
my eyes a big improvement.


I will assume this is a joke.


Hmm, interesting... Well, you can partially address granularity problem by publishing many offers of different size which use same inputs, e.g. 100, 50, 25, 10, etc. This will reduce blockchain bloat, but isn't same thing as proper granularity, I guess.
[/quote]

Then if someone buys 10 out of the 100, you need to publish another
offer with 90, after another trade you publish another offer, etc.
This introduces sequencing in the execution.
To prevent this, you would prefer to publish 10 offers of 10 each,
just because is more convenient for you.
But someone who wants to buy 50 will complete 5 of those similar
orders instead of a single one with nQuantity=5

It is a minor optimization, so we would probably remove sub-txs if we
didn't need them for the rest of the cases.


We've tried hard to find new vulnerabilities in the protocol
introduces by our changes and we encourage everyone else to do the
same.
We haven't found fundamental flaws, but of course concrete
implementations could have their own flaws.
Should we sacrifice, for example, BIP32 because some people could
implement it wrong? I don't think so.

Stupid programmers can also have their user's bitcoins stolen by
using a flawed random number generation function in their clients,
but that's not a fundamental design flaw of the bitcoin protocol,
just a flawed implementation.

I have to think more about this, but I think this can work. At least I don't see any flaw so far.
#3 is the less important part and can be simulated with several smaller transactions, just like regular granularity.
Even all or nothing options would be very good for colored coins. Let me know if you write a more detailed design to review, it definitely looks promising.


Ok, I got it.
Not a fatal flaw I think.


Yes, if it doesn't break the contract, it would be definitely better.


I agree. But I don't think the more advanced features add that much complexity to the protocol validation itself.
As Mark explained, the big barrier that exists between 1 and 2 (a hard-fork) doesn't exist between 2 and 3 if you do it at once, so...why not?

Is there any code that actually *implements* ability to trade between multiple block chains in a very simple way?

I would like to take https://bitbucket.org/dahozer/7 or https://bitbucket.org/dahozer/-- and extend them to have a single binary that can run and have blockchains for 3 to 4 cryptocoins, say maybe Catcoin, Dogecoin, and Kittehcoin, just to go with a theme.

I've seen a lot of theory and talk all over the place about how this might be done, and a little bit of code ( https://github.com/PhantomPhreak/counterpartyd ), but nothing I can actually use.

I think I could have something that we can at least try out, but probably has some flaws that may be exploitable, but should easily be detectable in about 2 months for less than 25 BTC (~$20,000USD). Would this be worth applying for a grant to the freicoin foundation, or someone else?

I think the biggest real-world issue is going to be getting FINCEN and other regulatory agencies to understand how in the world to deal with a decentralized exchange. If I run the daemon am I then a money transmitter?

If I want to start a non-profit to accept Catcoins and convert them to dollars to give to local animal shelters, right now I have to use 2 different exchanges, and to start a *local* direct exchange seems like it would cost me about $1million USD in legal fees to file all the paperwork and filings. ( https://cryptostocks.com/securities/57 )

What are you talking about? As far as I know, Counterparty is NOT about "trade between muliple block chains". And neither is Freimarkets.

You need something like this:

https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains

But it depends on non-standard scripts, so won't work so well right now.

Is Freicoin / this project still actively developed?
Also is it tied in anyway to Cromawallet?

No.

Yes, and yes. However it is just the two of us, and unless we meet our donation goal our time is split among many, many different projects, so progress has been slow.

There's a way to implement cross-chain trades using Freimarkets, but it won't be deployed into Freicoin because it would be very risky for the Freicoin network. We explicitly discourage its use for trades between public chains, it is designed to be used for transactions that involve in-chain and off-chain assets. Read the "Extrospection opcodes" section of the specs:

"The following opcodes assume the maintenance of a discrete set of
observed chains by each chain. If a public chain observes another
public chain, it's validation and security become completely
dependent on the observed chain, and any reorg on the later can
trigger another reorg on the former.

Even assuming that a public chain only observes its own chain, the
opcodes may require full nodes to have more data than it's currently
on the utxo set, opening the door to new DoS attacks vectors.

For these reasons the opcodes are only recommended to be used in
private chains, and even in those cases configure them with caution,
potentially limiting more strictly the standard behavior described
here. For example, in Freicoin their behavior is modified as
described in section \ref{freiExtOpcodes}."
[...]
"In Freicoin, the only observed chain is Freicoin itself. The depth of
the introspection is restricted too. So only the more limited
OUTPUT_SPENT_IN and OUTPUT_EXISTS_IN opcodes are available. Any
use of the generic ones will result in abnormal termination of the
script."

There are better solutions for cross-chain trade:

https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains
https://bitcointalk.org/index.php?topic=321228


I don't think this is particularly interesting at this point, but that's just my opinion.
You can list any non-profit project related to complementary currencies, free software/knowledge, sustainable development or charities.
From the foundation web:

"Any non-profit organization can be listed to receive donations. If your organization or project is not legally a non-profit but fits the goals of the Freicoin Foundation (stated on the home page) you can still submit a request to receive funds issued by the Freicoin Foundation in proportion to the donations you receive through this web.
[...]
The foundation will complement Freicoin donations with the foundation's issuance funds, increasing the amount by 10%."
http://foundation.freicoin.org/#/donations/join

By the way, people donating Freicoins to Freimarkets should use this address (15xnKvBQVJHuqWbfUbPrTpTLmvEX3x7s6W) so that we get the match from the foundation:

http://foundation.freicoin.org/#/donations/detail/20

Interesting concept. Is IPO still available, or did I missed the boat?

This is free software, I didn't knew you could IPO forkable free software until I saw mastercoin, bitshares/protoshares/angelshares/next-name-to-get-more-money-shares and ethereum. It turns out that is possible if you target a greedy and stupid enough audience, but we don't plan to do it.
Maybe after some more mtgox-like fiascos people finally realize what we need and that simply donating to free software development may be a much better way to make the now old p2p market dream a reality than buying promises "while they're cheap".

If you're interested in a quick profit I suggest you "invest" in dogecoin or just pay attention to the next scamcoin release to get early on the zero-sum speculative lottery (actually negative sum since mining costs real resources that are burned forever). There will be more pump and dumps, I'm sure you're not late.

If you're interested in contributing to build something that everyone in the world will be able to use (donors or not) and will last forever (knowledge and code don't perish with time or use), we welcome your donation.

We of course accept Bitcoins, but If you donate Freicoins we will get 10% more than what you donate:

http://foundation.freicoin.org/#/donations/detail/20

Be careful, we don't want to call our potential donors greedy and stupid :)

Seriously, this should be an educational moment. The only way to make money directly off of a free, p2p, decentralized platform is to leverage the network effect to extract rent from the future economy and pay it back towards early adopters / investors. Unearned rent is evil, and extracting it to provide a return to investors is unethical behavior. We will have no part in that.

We thought this was obvious, but apparently it is not too obvious as other projects have gone on to do just that. In fact they have raised orders of magnitude more than we are humbly asking for, to implement poorly thought out and less capable platforms, in schemes where the anticipated return on investment doesn't make any sense at all. Why? Because any distributed, p2p network platform must be free and fair, or else it will fail. If someone is selling you an investment opportunity in a new open source decentralized platform, you should be very suspicious. Either they are scamming you or they are deluding themselves.

Let's compare the situation with bittorrent, Napster, and other companies of that era. How do you make money off of a free to use, open platform in order to provide a return on investment? You don't, as Napster and others found out. You can try to monetize it by extracting a rent, but then people will fork your code and remove your built-in advantage, or they will release a protocol which is free and fair and can't be competed against (bittorrent). Worse, when you try to make money from the protocol you inevitably introduce some level of centralization which can be exploited by those old industries you are seeking to eliminate. Look to the court cases which did in Napster, for example.

So how do you make money off of a new distributed, decentralized, free and fair p2p platform? You build new services on top of it, and monetize that. Freimarkets adds new capabilities which will be the foundation of hundreds of companies seeking to monetize asset issuance, smart contracts, and distributed exchanges. Many of these companies will go on to become worth hundreds of millions of dollars in separate industries, and the one thing they will have in common is that they will all use the same underlying free and fair, open-access network protocol, just as every bitcoin company today uses the bitcoin network without paying rent to Satoshi.

So here's a suggestion: donate some percentage of what you are willing to invest to the crowdfund address in the OP, then split the rest of your funds across various companies seeking to use the Freimarkets network once it is completed.

Yes, of course, probably I was too harsh or not enough clear. Investing to get profits is not greedy or stupid.
But as you explained very well, you cannot monetize it DIRECTLY.
At the same time there's hundreds of ways (and probably more we don't know yet) to monetize the network INDIRECTLY.

Says the man sitting on a huge pile of Freicoins he earned just as much as any pre-mined coin developer. Of course, this time it's different because charity is good and lending capital at great risk is evil. You're entitled to seigniorage because you hold a moral high ground - you're a better person than those evil Bitcoin speculators.

Gee where do I send my money.

Off topic but I'll address it. The foundation funds are only spent through community mechanisms, e.g. matching donations. Neither Jorge nor I have any significant control over the destination of those coins.

Of course he's not entitled to seignoriage. As explained many times, if we used that money to directly fund freimarkets or to pay for freicoin websites domains or hosting, it would be trivial for miners to deploy a softfork that impedes those coins to ever be moved again, thus the coins would become destined to be destroyed by demurrage, with the only side effect that it would take more than 3 years for inflation to disappear. Your opinion is that the seigniorage should be burned in mining subsidies and I respect that opinion, but you have to face that it is not shared by the majority of the freicoin community. Like I was told when I wanted Bitcoin itself to have demurrage: go ahead and fork freicoin to create an altcoin with demurrage and 100% issuance through mining subsidies.
Apparently we made a terrible choice with the name of this proposal. We hoped that "free markets" would be something appealing for the cryptocurrencies community, but people seem to interpret it as if the proposal were coupled with Freicoin, which is not. So, please, go to a freicoin thread or to the freicoin forums to criticize the freicoin foundation since as maaku says this is off-topic for this thread.

Going back on-topic, even if I considered that using the seigniorage of a new currency (it would have to be another one, not freicoin) to fund development (like mastercoin or etherum) as something reasonable, legit and moral; I would feel bad asking people to "invest" in something that I consider a terribly stupid business model.
Being free software, nothing prevents other people from forking ethereum from day 1 (maybe with some more sensible choices like changing the PoW to SHA256 to enable merged mining with Bitcoin), thus relying on currency speculation for profits is far more risky than most of these "investors" think and developers are not being clear about this (to be fair, maybe they don't understand this themselves).

Venture capitalists should look for more clever ways to monetize an open network like freimarkets: issuing gold deposits crypto-certificates, becoming a fiat or bitcoin gateway, selling smart locks or smart cars, creating a p2p lending site on top of freimarkets smart contracts, acting as an internet notary for legal contracts behind the issued assets, providing a secure storage service for windows users...
What I think is that these "investors" are in fact risk averse but they just don't understand the real risks of their "business model".
Freimarkets is not a business and thus lacks a business model, but there's many potential business models to be built on top of this infrastructure.

Whether or not there is matching is irrelevant - the foundation must decide either which charities are elligible, or who gets to vote on which charities are elligible. And the decisions to hold the coins pending a full plan, and to give them to charity, were both made without a vote.

Seigniorage is the difference between the cost to acquire a good and its market value. If Bitcoin has any seigniorage at all, it tends to zero just like mining profits. That's such a far cry from 80% seigniorage that when you first said this to me months ago, I was so disgusted that I remained silent until now.

There are two reasons I haven't forked:
1) I'm not skilled enough to maintain it properly.
2) I'm not convinced that demurrage is beneficial in the first place.
If anyone reading this does start a "equal rules for all" fork, please PM me and you'll have found your first speculator.

Apparently maaku thinks the "evil" of Bitcoin speculation IS on-topic since he brought it up. I've tried to bite my tongue, but this is so blantantly antagonistic that I just can't leave it be. So by all means, discuss the crowdfund/software and keep your moral judgements of the Bitcoin community to yourselves.

I answered to the rest here: https://bitcointalk.org/index.php?topic=89843.msg5512319#msg5512319


Maaku didn't talked about bitcoin speculation at any point, we were talking about mastercoin and ethereum speculators (among other similar projects) who seem to ignore that their code can be forked.
I feel part of the Bitcoin community (maaku is actually developing bitcoin core functionalities) and I think you just misinterpreted our claims.
We're NOT attacking Bitcoin and in fact I don't think anybody would have believed Freicoin was even possible at all. So I'm really thankful to Satoshi and the bitcoin community for making a demurrage p2p currency possible in the first place. If the community had accepted a demurrage hardfork for Bitcoin when I proposed it there would have been no need to create a new chain or a Freicoin Foundation at all. No bad feelings about that though, I respect the community decision (unlike you do with Freicoin's community decisions).

Just so I'm 100% clear - which assumption was incorrect?
A) Maaku was saying ALL unearned rent was evil, not just those projects
B) You and maaku think that the income one gains from deflation or increased adoption is unearned rent

I used to respect the Freicoin community's decisions while I felt I was a part of it. That ended with the beta, when you guys drastically changed the scope of the project. If the Bitcoin developers decided one day that everyone should start trusting them even though it wasn't absolutely necessary, how would you feel?

I said that unearned rent is evil, and I stand by that. You should be able to make money by lending money, for example, but not the excessive interest rates credit card companies require because of a government-enforced monopoly on banking. If the p2p lending market were deregulated then interest rates would be much lower, and there wouldn't be such a massive ongoing transfer of wealth from the indebted poor to these companies. That system is evil.

I'm not sure what "unearned income" means. It sounds like a Marxist concept I do not subscribe to, namely that any income not resulting from actual labor is somehow unearned. I don't think that is true - if I lend out money with some risk, I deserve to be compensated for that risk. (As an aside, with unperishable currency like bitcoin I do pull in an unearned rent here due to the power relationship of having coins, separate from the opportunity cost of lending them out. Fixing this is the reason for demurrage currencies like Freicoin.)

The problem is that in the construction of a free and fair, decentralized, distributed, p2p, merged mined side chain for asset issuance and smart contracts - like Freimarkets - there is no room for the people who created the side chain to profit from its use, short of intentionally limiting the system in such a way as to require use of your pre-mined currency (a la XRP), or mandating some sort of centralized transaction tax, either of which could be just as easily removed with a fork.

With pegging and gateways there is no need for another non-perishable, mined currency, and any sort of usage tax on a p2p network is unfair and users would rightfully revolt against. So your best hope is that the network effect of people using your software will prevent people from switching to an unencumbered fork. But given that you are providing no direct service to the people using your chain (or it wouldn't be p2p), that is the definition of an unearned rent, and something I would find unethical to take part in.

So, in summary, you misinterpreted what he meant by rent (http://en.wikipedia.org/wiki/Economic_rent) (Adam Smith divided incomes into profits, wages and rents).
Bitcoin early adopters, for example, are not receiving rents on bitcoin rises because anyone could have buy them too (in in fact they're talking a big risk by putting their money on a new technology that could fail). Those are profits, not rents.
Ripple Labs, Mastercoin or Ethereum business/funding models are basically rent-seeking on free software (something that intuitively shouldn't be possible).
In contrast we (or colored coins developers like @killerstorm) are just asking for donations to pay our wages.

It was a mistake I corrected a couple minutes after the post - I meant to type unearned rent.

Ok, so Bitcoin speculators aren't getting unearned rent, right?

Correct, but now that there are free and fair p2p issued currency anyone issuing a new one would be trying to collect a rent - forcing everyone to switch over to a currency which benefits you when free and fair alternatives exist.