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

While MtGox's problems are of their own making, the current situation has nevertheless thrown the spotlight on malleability issues which do need fixing. Malleable transactions are a significant pain point for many wallet implementations. And malleability precludes use of interesting advanced protocols which involve the construction of a series of off-chain transactions, which is not safe to do.

You may know me as the guy working on authenticated validation and address indiceas, a peer-to-peer CoinJoin implementation, and various other protocol extensions. Since Monday the 10th of February I've put that work on hold as I help address the most pressing malleability issues. I've implemented an improved serialization format for Pieter Wuille's "normative transaction ID" (ntxid), which is visually distinctive from hex identifiers, includes error correction codes, and is specially tailored to over-the-phone or handwritten usage. It can also be more generally applied to protection of encrypted private keys in paper wallets, and other cases where humans interact with long serialization strings. You can read more about my work here:

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

I also would like to work on making mutant transactions are non-standard (and therefore not relayed), and eventually encoding these rules as a soft-fork protocol rule. There's a good skeleton of a BIP describing the necessary changes here:

https://gist.github.com/sipa/8907691

This will require a bit of time, however, to implement, test, push through the standardization process, and get 3rd party wallets to support before deployment. So far I've worked on malleability issues without pay, but I can't afford to do that much longer. If you think these issues are important, please consider making a donation. Funds sent to this address will be used specifically for work on malleability fixes:

1DeZqzJ2f472VaGG6qAVzw5FNq5v4eL7pb

If you have questions or there is another pressing malleability issue you think needs to be address, please post here.
-----BEGIN PGP SIGNATURE-----

iQIcBAEBAgAGBQJTAmwGAAoJECsa1YSJj/UDSPIP/RMHh5/GEZyBvhy9LtALicxK
uvbTPUj0c4IsbiQYgB7vc88iPUtgfgytvsMtbq2LHg3j5f0blij46UWHcuydKid6
sDakrcu6k3XxlHArG57cOQQ7GFlPeOi4HQOkiHjSpnkx+yEUThHc/hFJAeDd0WIW
V6HR7NPYr+OAEfj5+moYv7pwdAMGh6M91/mgwzuiAUWpPQJqbvH3rovUStOpdjy0
xIqiGHSgDHYXMX580umNi8CZ8QDvujdjo2MUo18p2caMoV7srMmm4EUm4XbdQTXD
zhiY1CIOd947UF13xmRvG+wrkRK+1mmJkQv9C+5SJSPErXknyZYEvWR0mtNG4/mb
Xnxo26pF9Oma4lZ30C0B2/t/rMV6zBkg2NQ9lZSP03/jrllpTwbdM2Mw7n69HINQ
MG9jFvyoFKNSyRAL9rJfMeai8VOwnjayqQASJniOR0oen+WMtrkXyQYWRZvcEwac
5Cn0fwK8K45+WM5DhdHfArvC9iUMuE/6PTt5b+PJwZn+3HVc+FFfAmdISMteKr9S
8MJbu4hYYY6NHz2/xbNk+Swq8JzxZDD5Dc1G8vCJ86N4cTUZ/pADJCuyOhI1tro3
fy/ar+jMzfCXLCZvcn3pQea+0CSmRaL633QJUSNInaJ+Cv+7NT6HGneODDgwCz6m
xivKJdhS9squJ3SKynl1
=WTsU
-----END PGP SIGNATURE-----

[1DeZqzJ2f472VaGG6qAVzw5FNq5v4eL7pb]

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

Pieter Wuille proposed a "normative transaction ID" (ntxid)[1] -- a hash covering the same data which is signed in the standard transaction types. A transaction cannot be changed in such a way as to alter this ntxid without also invalidating a the SIGHASH_ALL signatures typically used by wallet software in the standard transaction types.

Having some experience in running a front-line customer service helpdesk, I know that a significant amount of time and therefore money can be wasted transmitting long strings of information over the phone (e.g. a 64-character hash string), or from handwriting which can be worse. Also since we already have a notion of a 32-byte transaction hash encoded as a 64-digit hex string, it could be very confusing for users who do not understand the difference.

I proposed and have implemented[2] an alternative encoding format for these normative transaction identifiers. It is also available as a patch against bitcoind itself[3] (I wasn't sure if I should open a separate pull request from sipa's). It differs from the presumptive default 64-character hex encoding in the following ways:

1. Always starts with the two characters: "tx".
2. 64-digit base32 instead of base16, and therefore is visually distinctive in that it includes the full range of alphanumeric digits.
3. Automatic correction of up to 2-characters of input data, and highly probable detection of further non-recoverable errors (approximately 1:1,000,000 chance of a false positive).
4. Uses Phil Zimmermann's z-base-32 encoding alphabet[4], which provides better resistance to transcriptive errors than the RFC 3548 standard.

The encoding format is in fact entirely general. It is able to transform any power-of-two sized string (>= 16 bytes in length) into a base32 string a multiple of 31 digits in length, with each 31 digit grouping containing error correcting codes capable of recovering from a single-digit error in the base32 input. It uses CRC polynomials for the error correction capability[5], which requires 5 error correction digits per 26 digits of input, instead of the theoretically optimal 4, but is much, much easier to implement correctly then available non-patented error correction codes.

The encoding format should be applicable to other uses as well, such as exporting private keys. It has additional features to support this sort of application: the encoding of a few extra bits of information in the padding structure, such as whether the private key is encrypted, and whether the public-key should be compressed.

Aside: if you like this work, please consider donating a few coins to 1DeZqzJ2f472VaGG6qAVzw5FNq5v4eL7pb. I work full-time on core bitcoin improvements, funding myself entirely through community donations. Any donations received to this address will be used to further address malleability concerns, such as an eventual soft-fork to eliminate known forms of malleability entirely.

[1] https://github.com/bitcoin/bitcoin/pull/3656
[2] https://gist.github.com/maaku/8996338
[3] https://github.com/maaku/bitcoin/tree/normtxid
[4] http://philzimmermann.com/docs/human-oriented-base-32-encoding.txt
[5] http://www.drdobbs.com/article/print?articleId=184401662&siteSectionName=
-----BEGIN PGP SIGNATURE-----

iQIcBAEBAgAGBQJTAlzpAAoJECsa1YSJj/UD2EMP/RXBPu9hTaWKBi2Lg3YQ8WIv
IdonshPAFq6YDx/dREPJZqIK/DXTORxcc0sNkmL7wfHSssz8A6cXzlQne+kqX2sf
g5+6W7Vn0WOTAbWYKNufnktbcm/5teH0yvXBfNoVpei76Z5NIjWbE9HVS0Ib8tys
Xr8d69+ufKB2TdM5NLRVmxtdyVXvSlo7706m1lNbTEDVZ5qM/Biv8YZsLqXVJN4j
pPdTxQ4jQrOOklUEWLGQ18EnGj5fAggSG0+ijdkxdFFYmmjlq/D3ucmSmRlBTeJE
aCdokV8ZFqmalvHMfjmawLB0faGtYDRnDIcKwlNHAES1XCRS4vVWGPHmXP12SjjA
PItuirf7G14UHEcKzFLqaF3j/XP4y0BZd9/J38VbvTEumwsMw6+UVMSFIytTkKIL
raS1zRVLf+r/Xkq7X4NFSIQx+N9Svzs03/iIxCF8eafC4vEQNZaSqwkXqmbLWmrQ
byRlE459BaPM0Bh+aykxMTfFcguZbK/7t0NuXawcJBJCrBvApvzCQfyDQXOM4LDr
8T7uvRcoFnOOnLr5zjXKREmVhtEKgl3Zl5rRbGW0EfJbiyX03U6OmDxwsw4EIh72
ToHEBNSAsq6lDvMT/bTitA5+yqx8k0E3ztYsgn6DkfFGXr2m8dKBYTDF5jh6HAS1
Fu+7gMV5ZfQ+3T/MLGvb
=xmVG
-----END PGP SIGNATURE-----

Gregory Maxwell has outlined a protocol for constructing shared transactions which obscure linking of inputs to outputs and thereby increase privacy (by 'mixing' coins to disassociate taint), or enable join transactions such as a matched donation (“I'll contribute 10btc to cause XYZ if someone else does too”) or colored coin exchange. All of this is possible without a single change to bitcoin. Even though the transaction is constructed in public, ownership of the outputs is masked using chaum blind signatures.

As a weekend project I have started an implementation of CoinJoin using the JSON-RPC API, Bitmessage for distributed, p2p communication, and a SQL storage layer. I have posted the initial framework to Github, here:

https://github.com/maaku/coinjoin

Now that the scope of the project has been explored, it is unfortunately too large an undertaking to accomplish as a side project. I am therefore asking for donations so I can spend a significant portion of my working time devoted to it over the next couple of months.

For $12.5k I intend to write a command line program which can be daemonized (run in the background), and which collects incoming transactions and change outputs from a running instance of Bitcoin-Qt, organizes mixing transactions with other users anonymously over Bitmessage to achieve the desired level of privacy, and finally returns the anonymized coins to your wallet. It will be usable, though not user-friendly (no graphical tools, yet). Most importantly, it will implement a cryptographic protocol for privacy enhancing distributed mixing of coins which could eventually become a standard part of wallet applications.

If you would like to contribute to this project, please consider sending some coins to the following signed address. I will “bill” my time hourly up to the donation amount received, and post all source code to github (MIT license).

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

Donation address for implementing
"CoinJoin" mixing daemon.

1CJRGzzZzjYbubXzmJERCoWqxNxgbjf5XG
-----BEGIN PGP SIGNATURE-----

iQIcBAEBAgAGBQJSLlNHAAoJECsa1YSJj/UDxI8P/3EBzwuCxjLzm/vxfQGnQDRR
rdcn6vHZGNDbxjuuLxDXUgPlAWSQ4/Cl+mYfzlDy3TtPX7tOTnEIZK3G5VPPuGuW
pEIl7r2FGQlKFxzyVFx0aYQ3f1VlHgvDhZM60DbhhHfm+uzgBYvIGVTXPWKHZTZ6
4KsV5Y8Y9jOA1C7KqAsI7rLuI59R3A/ovq7ItDpi5DsJb8KqZnKlVjcRWrrBd5Om
74h4WnI9dkaCFqY+alqb7uuGeEPld6eMPwCt7CneAdNu7AG21nW3Q4BR9Un/j861
Yxr9udod2uFzI7ULhj4MmbD20XSKVTUkFXo1BBzxa01yK9v/3JzRj97mT30kfY4h
QHn+pKmGTbVMJy+aiyLW+wX6UswKfF6krHeVa1BhEeQXSjhdNIp1y+2n1cbCqo5y
53MsxPD3pVMTf88uf4O7Eh7Srw1St1x4dXz5nBIdFQHm0IZ7dwrA3fojrLdrGjKP
DOnuH1Fr2NFDWnemwiJlab4AVS5F5/5Cm1jaYBWdl9LcKLr5O15M8OtZDNrcdRjJ
GupnNmn85E4Y6TLMUIqppwfqClLeVlaeam0DvChuRFy4QUAa521HBIpYQhUr8cq0
0O2tw0jnTZf/nMo+9Tk3vNPADQn26utUNCJdGQZTGfschxHWYijoEmTSG77KZRok
E/tYjHxnbnmL8l+5UMem
=ioqh
-----END PGP SIGNATURE-----

[Overview]

Off-and-on for the past couple years, Jorge Timón (jtimon) and Mark Friedenbach (maaku) have been developing an extension of the Bitcoin and (pre-OpenCoin) Ripple distributed protocols which enable user-specified bearer instruments, off-chain accounting, atomic trades, peer-to-peer auctions/exchange, derivatives and transitive transactions, and the multitude of financial contracts these primitives would make possible. The specification is now reasonably complete enough that we would like to receive input from the community.

(The full specification is available for download as a PDF document - what follows is a high level summary. Furthermore, we have a crowd-fund in progress to help pay for the necessary development to implement this. Any feedback from the technical people here would be especially welcome.)

Overview:

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

Here are some example applications we've worked out in detail:

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

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

User-issued assets:

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

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

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

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

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

Partial transactions:

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

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

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

Private ledgers:

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

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

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

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


For more details, check out the PDF:

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

[UPDATE]

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.

deleted

"In 2012, under threat from fundamentalist rebels, a team of archivists, librarians, and couriers evacuated an irreplaceable trove of manuscripts from Timbuktu at great personal risk. The manuscripts have been saved from immediate destruction, but the danger is not over. A massive archival effort is needed to protect this immense global heritage from loss.

"Though removed from immediate threat, the manuscripts are still jam packed in footlockers used for their evacuation and the current environment of this precious world heritage is significantly more humid than Timbuktu. There are already signs of damage and exposure to moisture. 

"The purpose of this campaign is to fund the preservation effort required to store the manuscripts in an archival, moisture-resistant manner during their exile from Timbuktu.  If physical harm from the current packing situation continues and if mold and mildew  spread in the corpus due to increased humidity, the damage will be devastating."

You can read more about the project on their Indiegogo campaign:

http://www.indiegogo.com/projects/timbuktu-libraries-in-exile/x/761158?c=home

...and after prodding they are accepting bitcoin for donations:

1KFNd93GHyNWy36UfqGtTriv733Xs7eXMV

Please look at their funding campaign, their video, and consider sending some bitcoin. This is a written literary tradition that is in danger of being destroyed by short-sighted fundamentalists. It's not every day that a few bit-cents can make a difference to the repertoire of human traditions.

At the developer round-table it was asked if the payment protocol would support alt-chains, and Gavin noted that it has a UTF-8 encoded string identifying the network ("main" or "test"). As someone with two proposals in the works which also require chain/coin identification (one for merged mining, one for colored coins), I am opinionated on this. I believe that we need a standard mechanism for identifying chains, and one which avoids the trap of maintaining a standard registry of string-to-chain mappings.

Any chain can be uniquely identified by its genesis block, 122 random bits is more than sufficient for uniquely tagging chains/colored assets, and the low-order 16-bytes of the block's hash are effectively random. With these facts in mind, I propose that we identify chains by UUID.

So as to remain reasonably compliant with RFC 4122, I recommend that we use Version 4 (random) UUIDs, with the random bits extracted from the double-SHA256 hash of the genesis block of the chain. (For colored coins, the colored coin definition transaction would be used instead, but I will address that in a separate proposal and will say just one thing about it: adopting this method for identifying chains/coins will greatly assist in adopting the payment protocol to colored coins.)

The following Python code illustrates how to construct the chain identifier from the serialized genesis block:

Code:

    from hashlib import sha256
    from uuid import UUID
    def chain_uuid(serialized_genesis_block):
        h = sha256(serialized_genesis_block).digest()
        h = sha256(h).digest()
        h = h[:16]
        h = ''.join([
            h[:6],
            chr(0x40 | ord(h[6]) & 0x0f),
            h[7],
            chr(0x80 | ord(h[8]) & 0x3f),
            h[9:]
        ])
        return UUID(bytes=h)

And some example chain identifiers:

Code:

    mainnet:  UUID('6fe28c0a-b6f1-4372-81a6-a246ae63f74f')
    testnet3: UUID('43497fd7-f826-4571-88f4-a30fd9cec3ae')
    namecoin: UUID('70c7a9f0-a2fb-4d48-a635-a70d5b157c80')

As for encoding the chain identifier, the simplest method is to give "network" the "bytes" type, but defining a "UUID" message type is also possible. In either case bitcoin mainnet would be the default, so the extra 12 bytes (vs: "main" or "test") would only be an issue for alt-chains or colored coins.

[Update]

Update: Please read the latest news here:

https://bitcointalk.org/index.php?topic=204283.msg3117454#msg3117454

I have approx two weeks left on the first round of funding the members of this forum have so generously provided. I will use that time finish and push the pruning and proof generation code, and time permitting expand the utxosync.py script into a small Django web API for querying the UTXO indicies. This could be used for prototyping wallet software that uses the new proofs. However this will provide no increase in security until bitcoin is soft-forked to include UTXO index commitments, or a merged-mined meta-chain is implemented.

This brings me to the next round funding. I am requesting a final 3 months of time to implement the final revision of the index structure in C++ and using LevelDB, optimize it to achieve sub-second update times (or as close to that performance goal as possible), and either (1) submit a documented pull request adding coinbase UTXO hash commitments to the Satoshi client, or (2) write a proxy server for miners to do their own commitments on a merged-mined meta chain. Which outcome depends on whether acceptance of a coinbase commitment pull request is likely to happen, which in turn depends on the achievable performance metrics which we do not know for certainty at this time.

Because of unexpected costs (insurance) and volatility, I'm forced to increase my monthly cost to 65btc, and will fully cash it out on receipt. I am therefore requesting a total of 195btc to finish the implementation as described above. If this is received by the end of the month, then I can promise the deliverable by the end of the year. Otherwise I will continue work, but at a rate in proportion to funds received, as funds are received ("billing" my time hourly). Please send donations to the same address:

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

Donation address for implementing phase 2
of "Ultimate blockchain compression"

13snZ4ZyCzaL7358SmgvHGC9AxskqumNxP
-----BEGIN PGP SIGNATURE-----

iQIcBAEBAgAGBQJSLkT7AAoJECsa1YSJj/UDJ0IP/26oyR1COsLs/f+rEvz33kFP
0HtGvsjbEoF+7cetJpIV0eyFomngOWpafr0uhy+uO6mGguPHbXPJlmcgywFdKDwB
pQrRVYcT2DQx+Hfwnhn51QNIJoB6LhnykUi9KrDar8FwbNfYOgLaSUDGqKShtDOC
lc/qVkP56cCvalcqs6a6Q8O0D69BLO+TwifMPJmtdzdnn/2Fs9ONdgXpnnNLGwpJ
g/LWPy9Zdjspq7qoH/p3kFWo2S8TmX5EShsMDM8C4oUTnMjXbBvodJQwm6AzC0KY
XWdg+/W82YpMpmAmhSxqw43/VzUrODw9WAn7cXrCA86/IwhihZnNhLsELYP7Cd77
kgBWR9HE+NILWTRn+x8CONfi6+gk8ZqYsKmcj+PcYbf1u2BAknKb1EVpTwNp2ehD
8y6oNFj99vkDfZz8hSmt8HLn7YbU9jnmJcFqXwCwDFZD+nvWi1dHFeqnJppH3lWX
HaIF3V+psYQuMpglk+fFVrbmF+omCzsd7dArCXk4n+txA8rGIVBD2nWz4MUUxB9e
TLIeVr4EkH+yjvEK00VzjryfINE6mG58hetm1/y4Y/1EvoDATOyZhR91UFB6x/21
+pCagBDSVquc7DVYk7e275PnKSxjM4miAcf88jkO6TvcdiUaiYnYGxZQRCBY89/6
WgWf1x6CQvknPrYT6sZv
=hg1Y
-----END PGP SIGNATURE-----

As always, I welcome questions and comments regarding this proposal and my work towards implementing it, particularly from funders or developers of lightweight clients that might use it.


TL;DR: I plan to implement the Ultimate blockchain compression w/ trust-free lite nodes proposal by @etotheipi. Please help me acquire funding work full-time on it by pledging coins to 13snZ4ZyCzaL7358SmgvHGC9AxskqumNxP.

After a startup misadventure, I have recently found myself back on the job market. Rather than take a soul-crushing 8-5 job, I have taken inspiration from @etotheipi and would like to try my hand at full-time open-source development.

In my mind the most critical barrier to the widespread adoption of Bitcoin is the initial block download. Requiring the user to spend days downloading and processing gigabytes of data before getting started is unacceptable, and SPV clients do not provide enough security to be an acceptable alternative for many purposes. We can have our cake and eat it too, but it will require a heck of a lot of grunt-work.

I reject bounties as being inappropriate for a task of this scale. The likely length of the project prevents me from doing this as pay-on-delivery as I would be receiving no income for living expenses between now and then, and I have a wife and daughter to support. It would also force me to develop in secret and take on a hostile stance with possible competing developers who may “scoop” my ideas or code to claim the bounty before me. The rules of the bounty may also prevent me from having the flexibility to alter the scope or structure of the project due to unforeseen considerations and unavoidable complications. I do not believe such an outcome would be good for the community.

Rather, I promise to develop in an open fashion. I will implement the UBC proposal directly in the Satoshi bitcoind daemon/Bitcoin-Qt client, with my changes periodically pushed to a github repository. I will make weekly status reports on a blog, cross-posted to this forum. I will engage with the developer community to get peer review on design choices and address concerns as they come up. The general plan for development would be:

* Implement the PATRICIA trie index of the UTXO set, using LevelDB as the storage backend. Implement p2p messages and rpc commands for querying this index.
* Add support for tracking multiple chains to bitcoind, and implement the merged-mined UTXO meta-chain.
* Restructure bitcoind to allow retrieval of wallet transactions from a UTXO peer, and construction of the pruned block/transaction database from the UTXO set.
* Implement bittorrent distribution of blockchain data, offloading IBD and full UTXO set retrieval from the bitcoin protocol.
* Switch the default Bitcoin-Qt behavior to perform IBD in the following manner:

1. Download bitcoin block headers and verify proof-of-work.
2. Download coinbase transactions for most recent X bitcoin blocks.
3. Determine head of UTXO meta-chain, retrieve meta-chain block header, and extract UTXO root hash.
4. Fetch wallet transactions from peer, with UTXO proof.
5. Download UTXO set (fast) and construct full transaction validation database.
6. Begin operation as a validating transaction processing node (total time elapsed: minutes).
7. Download entire block chain history (slow) and verify blocks.
8. (Potentially) begin operation as a mining node (total time elapsed: hours/days).

(Update: please read this blog post for my current views regarding SPV+ support in the Satoshi client, in view of the fact that the Satoshi client is no longer the officially recommended wallet app. Implementation of SPV+ mode in lightweight clients such as MultiBit or Electrum has taken priority, although recent changes to the Satoshi client make SPV+ mode more plausible.)

I expect that full implementation of this proposal would take 4-6 months. It might take longer. I am requesting 150 BTC (or equivalent fiat) to cover rent, food, insurance, medical bills, etc. for the first 3 months in lieu of taking a job to support my family. Obviously this will not be sufficient time to complete the project, but I am expecting to make significant progress and certainly have a better idea of how much follow-on work would be required. You may then evaluate whether a further donation is a worthwhile investment for you.

I have started a blockchain.info wallet for this purpose.

13snZ4ZyCzaL7358SmgvHGC9AxskqumNxP

If it does not reach 150BTC, I will return all contributions. Please reply in this thread or PM me if you have any questions, and I will be happy to answer them. I will also be a panelist at Bitcoin 2013 and would be happy to meet with anyone in person.

CREDENTIALS

I implemented Freicoin, which adds interest/demurrage to the bitcoin blockchain. This required considerably more design and simulation than one might naïvely expect, as interest obviously depends on timing, transactions lack timestamps, and block time is untrustworthy. The solution developed for Freicoin is original and works well in practice.

More recently I have implemented an improved difficulty adjustment algorithm for bitcoin protocol currencies, replacing the 2016-block average with an optimal Parks-McClellan filter co-designed by @galambo and tweaked to give very quick response response times (adjustments every 9 blocks) while maintaining accuracy and avoiding instability.

I have also co-designed with @jtimon a colored coin proposal that adds interest-bearing assets and a distributed, peer-to-peer exchange. I will shortly be posting this as a separate bounty / work proposal.

Outside of bitcoin, I have worked for several years at NASA-Ames Research Center, doing various web development & data analysis & visualization tasks for the planetary science and astrobiology institutes.

EDIT: After less than a day, the funding goal has been achieved. Thank you! As there are still contributions coming in, I will treat it as a rolling fundraiser for continued development after the 3 months have elapsed. This is a project that will take at least 4-6 months, and possibly more. The project will officially start June 1st, after I have wrapped up some other obligations.

As the primary developer behind Freicoin, I've made modificaitons to Satoshi client such as implementing interest/demurrage, and adding a budgetary mechniasm for enforcing coinbase outputs. I am a Python web developer by trade, proficient in the skills necessary to implement Bitcoin services or applications.

My current rate is $50usd/hr, but payment is preferred in bitcoins (at an agreed upon exchange rate). Post here or PM me if you're interested in hiring me for a project.proficient

I will be representing Freicoin on the Alt Chain panel at the “Bitcoin 2013: The Future of Payments” conference in San José, California on May 17-19, 2013. I haven't been told yet the structure of the panel so I'm not sure if I'm given a chance to talk or if it's straight Q&A.

Nevertheless, I'm curious what the community here would expect/desire to see discussed at the Alt Chain panel.

I've written up on the Freicoin github wiki an article explaining how to properly handle demurrage in your own applications:

https://github.com/freicoin/freicoin/wiki/How-to-properly-handle-demurrage-in-applications

And a specific example of how to handle demurrage on an exchange:

https://github.com/freicoin/freicoin/wiki/How-to-implement-a-Freicoin-exchange

This is an idea that I've been thinking about for a while but do not and surely never will have the time to properly implement. I'm posting it here in the hopes that someone else will, as I believe it is a service greatly needed by the bitcoin community. Especially in light of what's happened recently with Bitcoinica and now Bitfloor.

What I advocate would most accurately be called a bitcoin insurance company, but probably not what you think of when you hear those words. It is a security company that assumes the risk of theft or destruction of its clients bitcoins, in exchange for a premium and a contractual obligation to implement what the company determines to be minimally adequate security measures.

Should a theft/destruction occur, the company immediately pays out the value of the lost coins to the client, in exchange for ownership of the stolen/destroyed coins--the premium being an on-going option for the insurance company to buy the coins at face value. This is where it differs from a traditional insurance company: the company takes off its actuary hat and becomes a policing organization. The company has become the legal owner of the stolen or destroyed property, and it uses whatever legal means available to find the one responsible and extract restitution (NB: restitution, not retribution--I'm talking principal + interest + collection fees, etc.).

If Bitcoinica had such insurance, it never would have gone permanently offline in the first place. Instead the insurance company would have gotten some bridge financing to cover the rather large payout, then launched a well-funded white-hat and black-hat operation to identify those responsible and extract restitution. Bitcoinica would have been back up and running within a week, and one more scammer would have learned not to mess with the bitcoin police.

The bitcoin economy is very fragile, and we need policing organizations to keep the scammers and con artists at bay. And there's really no reason this can't be a service provided by the community itself--and paid for through the mechanism of insurance.

[15]

I have three Radeon 5850's (2x Sapphire, 1x HIS) and one single-slot Radeon 5770 I bought second-hand for a mining rig I have not had time to put together. They are tested and working. The 5850's I'll sell for 15BTC and the 5770 I'll part with for 8BTC, shipping included for destinations within the U.S. (at-cost shipping for international destinations or non-standard addresses).

I'll post pictures later, when I get home.

I'm posting here because some people may find it useful, and not everyone reads the development list. I've pushed pull-request #1597, which adds a makefile with commands to build out a VirtualBox VM capable of doing deterministic gitian builds from any machine that can run VirtualBox. Simply do a "cd contrib/vagrant && make".

https://github.com/bitcoin/bitcoin/pull/1597

[Donation address:]

We're asking for your help in creating a new crypto-currency, once with real value and lasting benefits. The idea of a demurrage currency has been raised before on this forum, but for those unfamiliar the idea is simple: apply a continuously-assessed fee to all accounts (4.4% APR, in this case), and distribute the proceeds from that collection to the miners.

Why on Earth would anyone want their money to lose value? The rationale is to separate money-as-a-store-of-value, a purpose Bitcoin serves very well, from money-as-the-medium-of-exchange, for which inflation/demurrage has significant benefits. These two functions are inherently at odds with each other, and there exists a rational economic theory put forth by Silvio Gesell a century ago which says that separating the two will cause (through economic self-interest) a lot of the ills of the current financial system and its effects on society to be fixed.

We're putting forth a proposal for a new crypto-currency with integrated demurrage and a few key improvements to the client (including trust-less block-chain pruning), which will be back-ported to Bitcoin as well. You can read the full details below.

To be clear, this is not a competitor to Bitcoin. Should Freicoin be successful, Bitcoin will retain its critically important role as a long-term digital store of wealth. Should it fail, that would only validate arguments for a deflationary rather than an inflationary/demurrage currency.

We've been working on prototypes and proof-of-concepts for these and other features over the past year, but unfortunately the demands of full-time jobs, family, and other commitments has meant progress occurring at a relatively glacial pace. We're seeking your help to make this currency and associated Bitcoin improvements happen A.S.A.P. We've created an Indiegogo campaign, and are of course accepting bitcoin donations as well, at the following receiving address:

Donation address: 1HzH4YtFwBQXyF2NCCwyY2qFCCsBsmdN3j
Contribute with fiat: Indiegogo Campaign

GOAL: $28,000 USD

Here's the text of the campaign (geared towards those who may not have heard of Bitcoin), followed by the pledge rewards and a FAQ:


Freicoin is a decentralized, distributed electronic currency designed to address the grievances of the 99% movement and correct the excesses of the 1%. Whereas inflationary currency like the U.S. Dollar or Euro are controlled by central bankers under rules that benefit the establishment, Freicoin would be completely decentralized and self-regulating, with fees on stagnant or hoarded money (demurrage) paid in proportion to those community members who contribute work to secure the currency. It is an opt-in alternative currency to be used first by Occupy-supporting businesses and supply chains, then spread to the surrounding community across the globe. It includes a downloadable client for Mac OS X, Windows, and Linux, and an electronic network for transferring funds denominated in Freicoin world-wide.

Why

Demurrage currencies like Freicoin align incentives of bankers and financiers with the priorities of working class, forcing the wealthy through their own self-interest to invest in growth, jobs, and ventures with long-term thinking. An economy based on demurrage currency would not fall victim to to the same greed, excess, and short-term thinking that led to the 2008 crisis and financial collapse. Freicoin would instead continuously stimulate global growth through reinvestment, and dis-incentivize the hoarding by the 1% that caused the “credit crunch”.

The current systems of money, including the U.S. Dollar or Euro, are and always have been used to store value--money seen from the point of view of the holders, the wealthy. Freicoin emphasizes instead the view to that of the producer, the proletariat, the 99%: money as a means of buying the goods and services necessary to sustain life. These are contrary purposes--money cannot function properly as, nor should it ever be both a means of saving and exchange; it cannot be both accelerator and brake at the same time. Indeed, this confusion and conflict over the purpose of money is what led to the financial collapse of 2008 and the extended recession that followed.

Demurrage forces the entire stock of money to circulate irrespective of the desire of the wealthy to accumulate and store; banks, financiers, and corporations can no longer hoard money waiting for higher interest rates or a more favorable investment climate as the demurrage acts as a tax on stagnant money. Money is eternally losing value, so the incentive is to spend it as quickly as possible on the necessities of life or to invest in longer-term ventures that also provide stimulus for a growing economy, typically creating real jobs in the process. Real money becomes a sort of “hot potato” that is passed around as quickly as possible, in a virtuous cycle of investment. No longer are there incentives for financiers to withhold credit from those in need simply to what for fairer economic winds.

For the 99% who live paycheck-to-paycheck, the loss from demurrage is minimal and would be compensated for in wages and pricing. For those who manage to accumulate some savings and for the 1% who receive much more income than they reasonably spend, they can either save real wealth (gold, silver, Bitcoins, real estate, artwork and fine wine, for example) and accept the obvious limitations of wealth saving (loss, storage, rot, fire, etc.), or they can loan it out to borrowers at what ends up being near-zero basic interest. With sustainable near-0% interest loans the order of the day, businesses will boom and the economy will grow in a virtuous cycle.

How

For the past year we have been working in our free time to produce a proof-of-concept prototype based on improved and expanded Bitcoin technology. The prototype is a re-implementation of a generalized form of the Bitcoin protocol which makes possible advanced features like demurrage, multiple currencies existing side-by-side (Bitcoin and Freicoin), and other improvements for future scalability. Extensive unit tests demonstrate the validity of this core component.

• What is Bitcoin? Bitcoin is a decentralized, peer-to-peer internet currency secured by strong cryptography and an open-source development process, and the foundational technology underlying Freicoin. Bitcoin enables anyone in the world to send funds to anyone else with minimal, fair fees on both consumers and merchants. Bitcoin is democratic in that everyone who uses the currency takes part in securing it (making sure the rules are followed and there is no fraud) by running a software program on their computers; they are proportionally compensated for this effort by collecting transaction fees, and in the case of Freicoin, demurrage. For more information about the benefits that come from basing Freicoin on Bitcoin technology, see the Bitcoin advocacy site We Use Coins.

What remains to be done, and what this campaign will fund is the following:

• Implementation of a block-chain pruning technology, reducing storage requirements and startup time and eliminating a major impediment to wide scale adoption of Freicon (and Bitcoin, for that matter).
• Re-purposing of Armory, the most advanced and user-friendly Bitcoin client, to work with Freicoin in addition to Bitcoin.
• Public-facing website and always-on “seed node” to help new users download the combined Armory/Freicoin core software and get connected for the first time.
• Initial “merged mining pool”--a service for Freicoin users to help secure the currency and receive rewards/compensation for that service.
• A Bitcoin/Freicoin exchange to enable supporters to convert existing funds into Freicoin (by first buying Bitcoin and then Freicoin).
• An animated film explaining what Freicoin is, what it does to fix the problems of the financial system, and how people can get involved in using and promoting it.

Once the above objectives are reached, Freicoin will be ready for adoption by Occupy groups and supporters, and other like-minded groups. The work can then begin to get Freicoin adopted as the first “global community currency”. As a peer-to-peer application, once completed Freicoin can be used by anyone in perpetuity without any required ongoing maintenance.

At the completion of this project Freicoin will be ready for individual communities to adopt, for businesses to accept as payment and for consumers to use. The initial freicoins will be in the process of being generated and fairly distributed to community members who participate in securing the network.

This campaign will directly pay for hardware and server time cover the first year of operations, materials used in the logo, branding, film, and initial marketing, and to keep the basic necessities of life as we decline contracting work to focus on Freicoin.

Join us and be a part of the reformation of global finance!

GOAL: $28,000 USD

Fiat donations: Indiegogo Campaign
Bitcoin address: 1HzH4YtFwBQXyF2NCCwyY2qFCCsBsmdN3j

$1
BACKER
Everyone gets access to the project upon public release, and a chance to participate in the creation of a new global economy.

$10
SUPPORTER
Our heartfelt thanks and your name in the credits of the official client.

$30
PHILATELIST
Receive a custom post card designed by the developers and sent from Silicon Valley with a personalized message of gratitude.

$80
T-SHIRT!
A beautiful silk-screened “Occupy Freicoin” T-shirt (add extra $10 shipping to Canada and $15 to other non-U.S. destinations).

$150
IMMORTAL
You will be immortalized in the genesis block of the Freicoin block chain, where your name or short message will be preserved forever in the historical record.

$500
FOODIE
Dinner with the developers, their family, and other backers in the Silicon Valley/S.F. south bay-area (transferable if you know someone who lives or will be in the area at the appropriate time).

$750
ACTOR
Cameo appearance in the animated film introducing, explaining the Freicoin project and how to get involved.

$1,500
VISIONARY
Membership in our advisory circle--a group of visionaries that will meet (virtually) approximately once a month to be informed of our current efforts and from which we seek ideas and inspiration.

$3,500
SPONSOR
Membership in our advisory circle as well as recognition as official sponsor of the Freicoin project. Your logo, business name, or other mark belonging to you will be featured prominently on the official public-facing Freicon website.

What is “Freicoin”, and how does it work, really?

Freicoin--literally “free money” in German--is based on the principles of economist Silvio Gesell's Natural Economic Order. Freicoin is an electronic currency managed through a self-regulating, distributed electronic network based on Bitcoin technology. The network enforces a continuously assessed 4.4% APR fee on all account holders. This fee acts as a tax on stagnant money, driving up the rate at which money flows through the economy and acting as an economic stimulus, and discouraging unproductive hoarding by the 1%. The proceeds of the demurrage tax are repayed transparently and proportionally to the community members who donate computer time to running software that regulates and enforces the rules of the network.

Besides providing a virtuous cycle of rewarding positive long-term investments, demurrage currencies also reduce interest rates to near-zero (hence the “free money”), providing further job-creating stimulus and helping to reduce the magnitude of the boom-bust business cycle.

Where can I learn more?

Here are some resources:

• Silvio Gesell's Natural Economic Order is the definitive work explaining the value and utility of demurrage currency, or what Gesell calls “Freigeld” (“free money” in the English translation) in fixing the ills of the financial/monetary system.
• The Political Economy of Silvio Gesell: A Century of Activism by Werner Onken is an academic article published in the American Journal of Economics and Sociology gives an overview of Gesell's work and it's influence over the 20th century.
• Aberrations of an interest-based economy: An excursion through the covert by Jürgen Probst is a more recent (translated) pamphlet predicting the excesses which led to the 2008 financial crisis, and showing how demurrage currency, among other things could have prevented it.

You've based it on Bitcoin technology. Is this a competitor to Bitcoin?

Absolutely not! The two serve quite different purposes. The properties of Bitcoin make it analogous to precious commodities like gold or silver, and it will always function as a useful store of value. Freicoin, on the other hand, is meant to be used as a medium of exchange only, kept on hand just long enough to provide a cash-flow buffer. The demurrage fee encourages recipients of Freicoin to put their money to use as soon as possible in an exchange (even by buying bitcoins, for example), whereas the deflationary nature of Bitcoin rewards hoarding and serves a different purpose as a long-term store of value.

How is this different from that other Occupy currency?

There have been a couple of monetary reform ideas floated by members of the Occupy movement, but most likely you are referring to “OCCCU”, another demurrage currency created by students at the Vorarlberg University of Applied Sciences and presented to members of the Occupy movement at Davos in January, 2012.

OCCCU's provision of “basic income” and the assessing of demurrage fees is accomplished by means of centralized regulators, the currently faceless OCCCU “general assembly”. This is hardly an improvement over the current system of centralized banking; as the great poet Pete Townshend once said: “meet the new boss, same as the old boss”. It is our firm belief that real monetary reform will only come when the system does not require trust in any individual or organization, and when all operations are made transparent. Freicoin accomplishes these goals with distributed self-regulation and automatic distribution of the demurrage pool on a fair and proportional basis.

Who are you?

There are three of us that have come together to make this possible: engineer Mark Friedenbach, designer Aaron Blumenshine, and project manager Matt Everingham.

In his day job, Mark is a application developer at NASA. He builds large data visualization applications as well as web and database backends. Aaron is an accomplished and award-winning photographer and graphic designer. Matt is an aerospace engineer and project manager, also at NASA, who has designed and built a series of low-cost exploration rovers controlled over the internet.

We became aware of Silvio Gesell and demurrage currency through our research into Bitcoin, and for the past year we have been developing the prototype and proof-of-concept mentioned above in our free time.

Will it be open-source?

Absolutely. In fact, the transparency provided by an open-source client is essential to the basic ideals of Freicoin and the Occupy movement. That said, it will certainly be possible to build closed-source software and businesses on top of the open-source Freicoin core.

...when Obama signs the Jumpstart Our Business Startups Act. Anyone will be allowed to buy stock in early-stage startups, up to a certain limit. It will also ease a bunch of other restrictions, including letting companies advertise online that they are seeking investment.

Needless to say, this will help a lot of early-stage Bitcoin startups.

Bitcoin uses a simple arithmetic mean for its retargeting algorithm. But since it's adapting to a change in rate, shouldn't it be using a harmonic mean instead? Of course it is probably way too late to change the algorithm, but wouldn't an arithmetic mean give mine pool operators who fudge timestamps a disproportionate effect?

EDIT: As gmaxwell and Meni Rosenfeld point out, bitcoin is actually measuring the rate parameter of an exponential distribution, for which the arithmetic mean is the proper choice. Also, the harmonic mean could be manipulated by miners via acausal blocks or very short timestamp differences.

My understanding is that p2pool operates an alternative blockchain with a 10-second target interval, where each found block constitutes 1 share. Somewhat coincidentally I have previously looked at the properties of an altchain with 10-second intervals, and what I found was that the network latency/p2p propagation time was a significant factor. On bitcoin proper it takes about 1.9 seconds for a newly minted block to find its way to all the bitcoin peers. Assuming you're solo mining with long-poll enabled, that means you're working on a stale block 0.15% of the time, on average (since you can assume the time it takes a block to reach just you is half the latency). But on a 10-second round, that likelihood is now 9%, a couple of multiples larger than even the most ostentatious pool operator fees.

Is this accurate, or am I doing something wrong with my math?

EDIT: I can't find any reorglog statistics for p2pool online, which we could use to determine p2pool's network latency... if someone has kept track of this, let me know.

EDIT2: P2Pool is safe to use! My analysis above, while not incorrect, is incomplete and only half of the story. The amount paid per share that *does* make it into the share chain is also approximately increased by a corresponding amount, negating the effect due to stale work.

[you're doing it wrong]

Ok, seriously folks: what's the point? About once a week we see a “new” coin crop up--or rather, a new fork of bitcoind with minor cosmetic changes. Congratulations, you can follow directions and change a few magic bytes! So what does this new *coin bring to the table?

“Our coin is GPU-hostile!” Ok... and why is that beneficial?

“Our coin continues to reward miners indefinitely!” Great... and what economic impact does that have?

“Our coin has fast[er] transactions!” Sure... just wake me up when it's instantaneous. Anything slower than that is of no practical consequence.

“Our coin ...”

You know what, f--k it. If you're differentiating yourself from bitcoin by some technical difference, you're doing it wrong. Hell, if you're having to explicitly differentiate yourself at all, you're doing it wrong.

But you know what, I'm going to be heretical and say this: if you're creating yet another currency, you're doing it wrong. Because ultimately, you're competing with the 800lb gorilla, and even if this decentralized currency thing takes off, you're still going to have a snowball's chance in hell of being the last one standing when the dust settles.

Let me tell you a little secret: crypto-token systems were *not* invented to create digital cash. It was much later that someone came along and dreamt up that application. So what other applications can you think of, hmm? Think of namecoin--that's pretty innovative (and useful), right? Maybe there is something cool and innovative you can do with bitcoin's codebase, that isn't a currency?

Ok, fine. You insist on doing a currency. So how about one with demurrage, eh? Ok maybe you're not so fond of Silvio Gesell, and John Keynes is more your style--so give us a coin with a fixed inflation. Or maybe one based on LETS/ripple? Or whatever--but make sure you a real economic theory to back up your experiment; otherwise your shitcoin is snake oil and you should be ashamed of yourself.

You know what, let this be an open challenge to the altcoin community: show us something innovative, new, and useful, 'cause you're making us all look bad.