Topic: [Crowdfund] User-issued assets, p2p exchange, off-chain transactions, and more - page 4. (Read 10382 times)

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.

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.

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

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.   

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.

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.

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.

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.

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.


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/

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.

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.

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 

(reserved)

(reserved)

Examples

English & Dutch auctions

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


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


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

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


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


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

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

Double auction (market/exchange)

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


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


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

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

Transitive trust relationships

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

Baskets currencies and gateways

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

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

Off-chain transactions

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

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

---

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

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

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

---

Summary:

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

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

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

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

The bitcoin/freicoin donation address for this project is:

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

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

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

Overview:

Herein we propose a new transaction format which enables hierarchies of independently verified sub-transactions, additional validation scripts and introspective opcodes, strict currency controls for user assets, as well as relaxation of the rules regarding coin generation via coinbase transactions for the purpose of supporting user-defined assets on the block-chain. We also introduce the concept of private centralized accounting servers to perform transactions of off-chain assets that cam interact with each other as well as with in-chain assets. Combined with suitable extensions to the peer-to-peer, JSON-RPC, RESTful, and wallet interfaces, these protocol changes complete bitcoin’s repertoire of low-level constructs, allowing the emulation of a wide variety of financial instruments.

Together this enables the following sorts of applications:

• Issuing new assets by means of asset definition transactions (coinbase transactions other than the usual first transaction of a block). Such assets are allowed to specify their own interest/demurrage rate, unit granularity, display scale, and contain a hash field referencing an external resource, possibly a legal or Ricardian contract that the chain itself doesn't validate.
• Issuing unique and indivisible assets that are transferred in sets instead of numeric amount, and allow fast look ups on their current ownership to enhance smart property use cases and manage some permissions of the regular custom assets.
• Atomic exchange of assets of differing types through inclusion of inputs and outputs of both types in a single transaction.
• Signing orders (partial-transactions giving up one asset in exchange for another) that are binding but not completed until they get into the chain as part of a balanced transaction, and have attached expiration dates or can be explicitly cancelled by double-spending the signed inputs.
• Executing an arbitrary number of these orders atomically by creating a complete valid transaction where the orders are included as nested sub-transactions, thereby executing an atomic trade without requiring each of the parties to be online or in direct communication with each other. Composing orders from separate markets into an atomic trade with intermediate assets enables payments based on transitive trust relationships.
• Destruction of coins, tokens, or assets when no longer needed by a special class of non-spendable, prunable output script.
• Restricting the conditions by which a transaction or sub-transaction may be selected for inclusion by specifying validation scripts, which are run when the enclosing block is validated. Introspection of the block chain from within the bitcoin scripting environment is enabled by the introduction of new opcodes.
• Running accounting servers as private chains with centralized rather than distributed consensus, in which off-chain assets can be issued, transferred and traded in the same way they are in the public chain, with the private block chain providing an audit log.
• Execute an arbitrary number of trades from different accounting servers and/or the public chain in an atomic transaction, using either the public chain or an agreed upon timestamping service for the commit phase.
• Public chains or private accounting servers configured to “observe” other chains to enable much faster but secure cross-chain trade, compared with the existing slow, multi-phase protocols involving revelation of hashed secrets. This requires the ability to extract proofs from the observed chain in order to validate conditional transactions.
• Restrict the usage of a custom asset by assigning to it rotatable signing keys which that must sign all transactions involving the restricted assets prior to inclusion (support for KYC regulatory compliance).

This proposal adds primitives to bitcoin necessary for implementing non-currency financial constructs, such as dividend-yielding bonds, asset ownership tokens, credit relationships, a variety of forms of smart contracts, and distributed marketplaces for exchanging all of the above. Private accounting servers provide a mechanism to support unlimited volume of off-chain transactions while being able to interact with in-chain assets through atomic cross-chain trade and an integrated peer-to-peer market.

User-issued assets:

Divisible currency and/or tokens representing user-issued assets may be minted in special coinbase transactions separate from the usual first transaction of a block (where bitcoins are currently, and continue to be minted). Coins created in such generating transactions are not bitcoins, but rather user-issued asset shares which represent fungible ownership of the underlying asset type, or asset tokens identified by per-asset unique bitstrings. Such coins and tokens can be included in transactions containing regular p2p-issued coins, which in this proposal is sometimes called the host currency or fee currency.

The creator of the new asset can define an interest/demurrage rate. The quantity issued may be fixed or he may define a list of issuance tokens that permit their owners issue new units of the asset being defined.

The creator of the asset definition transaction may also specify a list of authorizer tokens. The signature of an authorizer is required every time a transaction involves inputs or outputs of that asset. This allows issuers/gateways to manage closed list of “authorized accounts” of registered users if regulatory restrictions of their jurisdiction requires them to do so or if they desire whitelisting of participants (for example, local currencies or restricted stock sales). It also allows issuers to charge fees when the assets are traded or moved.

Using unique tokens to manage new issuance and authorizers allows the creator to follow his own key cycling policy or security protocols. By utilizing multisig or multiple signatures, it is possible for transactions to remain valid even across one or more key rotations.

These various properties of the asset, its interest/demurrage rate, unit granularity and display scale, and listings of issuer and authorizer tokens are set in the coinbase string of the asset definition transaction.

Partial transactions:

This proposal extends the transaction format with an optionally empty nested level of sub-transactions. Sub-transactions differ from regular, top-level transactions in that their inputs and outputs are not required to balance and they have associated with them a quantity and granularity allowing for fractional redemption.

Since validation of sub-transactions occurs separately from each other and the higher-level enclosing transaction, pre-signed, unbalanced transactions are able to act as offers on a distributed exchange: market participants sign offers adding coins of one asset type in exchange for an output of another type. These signed offers are broadcast through a side-channel and aggregated by miners. When a cross-over is detected (a bid higher than an ask), the miner combines the two pre-signed offers and claims the difference as a fee.

Other use cases are enabled. For example, when the underlying assets represent lines of credit, the exchange mechanism allows payments based on transitive trust relationships, in the style of the original Ripplepay application by Ryan Fugger.

Private ledgers:

Private accounting servers (the “accountant”) use a variant of the bitcoin code base that is stripped of the distributed consensus proof-of-work mechanism. Accountants are responsible for eliminating double-spending, reserving balances for pending transfers, and authorizing transactions, sometimes conditionally on external events. Accountants are able to prevent transactions from going through if the owner has already obligated funds elsewhere, by keeping track of the available balance (actual balance minus funds in various stages of commit). Accountants use various distributed consensus mechanisms for coordinating the transaction commitment with other private accounting servers or public block chains.

The level of privacy may vary from one server to another. Server operators are allowed freedom in choosing which parts of the block chain audit log to publish, with a sensible default being the block headers and coinbase transactions, allowing for validation of authenticated inclusion and index proofs used to notify users of their wallet balance, history and current activity, but not revealing other user’s balances.

By using newly added introspective opcodes to construct scripts dependent on external chains, it is possible for private transactions to be conditional on public block chain data or other private accounting servers.

Note that the opposite relation cannot apply at this time. Public chains could support transactions conditional to data on other chains to enhance cross-chain trade, but then the observing chain’s validation becomes dependent on the observed chain validation. This approach to cross-chain has been described several times elsewhere, and would be trivial to implement with this protocol extension.

About us:

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

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

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