Not at this time.  It is possible that somebody might create a bitcoin-firstrun.exe application, separate from bitcoin, that torrents the blockchain.

For most users the initial blockchain download will be a one-time event, so there is little interest in directly adding bittorrent code to the bitcoin client.

The import-bootstrap.dat feature was added so that bitcoin does not have to care about the source of the data.  As long as you have the file, it will import it.  Maybe you downloaded the file via torrent... or maybe HTTP.  The point is, from the bitcoin client's perspective, it is agnostic to the download method.

The difference between 0.7 and 0.7.1 is that 0.7.1 automatically runs "-loadblock=bootstrap.dat" at startup.

The torrent will probably be a faster download...  but if you have an ultrafast network peer, the regular download will be just as fast.  This torrent is just adding option for users; it is not the New Official Recommends Means for getting the blockchain.  As the OP emphasizes, this is an experiment.

Quoted for emphasis.

You are welcome to become a member, and have a voice in how to best use the funds.

The focus on Gavin is simply prioritization:  if there are enough funds to pay a full time developer, they should go first to Gavin (IMNSHO).  It is better for the project if Gavin is working full time on bitcoin, rather than full time on $SomethingElse and scrambling for whatever remaining bitcoin time there is.  If there are Foundation funds left over, they should probably go Q/A, infrastructure, other full time devs, as the members decide.

As to myself, I already have a job I love, so I have self-selected myself out of any direct salary (as previously stated in this thread).  Like Pieter, I work on what I like to work on, and have the freedom to ignore boring stuff.  Obligation-free beer money donations are always welcome of course (hence the sig).

The most important concept to remember is that colored coins are like rules of the road:  they only work because everybody agrees on what side of the road to drive.  There is no law of physics preventing cars from driving in the opposing lane of traffic.  There is no software rule preventing you from using your colored coins to buy Alpaca socks at a web shop.

The basic process works like this:

1. Publicly declare a list of coins in the existing blockchain as colored.
2. Transfer the colored coins to their new owners.  These new owners may freely transfer them to other owners.
3. If the colored coin transfer follows the Colored Coin Rules(tm), software may search the blockchain, and precisely identify the list of colored coin holders.
4. If the colored coin transfer does not follow the Colored Coin Rules(tm), then that person is essentially "burning the money", by making it impossible to track the colored coin beyond a certain point.

It is up to each colored coin owner to keep track of their own public keys.  All other information is stored in the public blockchain.

There is only one blockchain, the public blockchain.

Let me try to draw an analogy:

Every US dollar has a serial number on it.  The US dollar version of colored coins would be analogous to: "the holder of $20 bill with serial number ABCD1234 owns Chevrolet Corvette VIN 137YA9031WE239523"

Colored coins says "bitcoin ABCD1234", whatever its value, is somehow more special than regular bitcoins.

This requires special software for the bond issuer and the bond holder, both, that recognizes bitcoin ABCD1234 as special.  This is simply an agreement enforced (or not) by running special software.

The bond issuer runs software that searches for the current public key holding ABCD1234, and pays dividends to that public key.  The bond issuer does not know or care who is the owner.

The bond holder runs software that stores ABCD1234 in a special wallet, separate from other bitcoin wallets.  This guarantees that the bond holder does not accidentally spend their "special" coin accidentally -- analogous to accidentally giving a rare coin to a vending machine for soda.

Yes.  The issuer may determine what public key currently controls a colored coin.  That is the only information present in the public blockchain data.

It is obvious that voting is possible:  a colored coin holder may use the 'signmessage' feature to sign any arbitrary text using their bitcoin ECDSA keys.

Let us assume that a colored coin has been sent to bitcoin address 1ABCD1234ABCD1234.

1. A public notice of voting is posted <somewhere>, of a vote.  This notice includes a sample ballot, a simple text message format.
2. The owner of 1ABCD1234ABCD1234 downloads the sample ballot, edits it to reflect their vote, and then uses the 'signmessage' RPC to add a cryptographic signature.
3. The owner of 1ABCD1234ABCD1234 emails the signed ballot to voting@mycompany.com, or maybe, voting@thirdpartyballotservice.com.
4. The bond issuer, or 3rd party vote tabulation service, looks at the blockchain to verify that the email just received is signed by the holder of public key 1ABCD1234ABCD1234, and that 1ABCD1234ABCD1234 does indeed still control the colored coin.

The .bitcoin directory is for a different app.

pynode is a full bitcoin client, separate from bitcoind.  The script mkbootstrap.py requires access to the pynode database, after you have downloaded all the blocks.

Sadly you do need to be a bit of a programmer to generate a bootstrap.dat file.

Quoted for emphasis.

Blockchain.info data is wrong on deepbit, so it either skips that work, credits other categories with deepbit's work (because deepbit's blocks are first seen by blockchain.info from other sources).

It works for cars...  as long as the car's security system is keyed to anyone who can prove they are the holder of the smartcoin.  Your mobile phone can easily generate an ECDSA-signed message proving this, given the proper key.  And Wired articles like this one show that it is feasible near-term for a mobile phone to be your car key.

It should be straightforward to trace a 1-satoshi output through the chain, to prove to the car's bitcoin API that the mobile phone is last holder of that coin, following standard colored coin rules.

Frankly, multiple colors of coin are not that interesting to me.  The main point is simply proving that (a) a given txout represents car ownership, traceable back to the "root property," and (b) you have the key associated with that txout.

To me, the basics are fairly simple: Within a single bitcoin transaction, you must distinguish between a smart property transfer and payment transfer, and ensure the two don't mix.  You must also ensure smart property transfers don't mix.

Correct.  A small bit of transaction metadata has been proposed, however:  https://github.com/bitcoin/bitcoin/pull/1809

This has the disadvantage of not being a standard transaction right now, and additional chain bloat.  But it is very useful to atomically attach a signed hash (metadata) to the transaction.  It is potentially more reliable than entirely depending on an external entity to assign meaning to the smartcoin/bond.  And it makes third party verification of bond holder claimers more reliable, as bond activity is easier to publicly track.

A purely colored coin solution does not have any external linkages.  This has the advantage of being a standard transaction right now, and does not carry metadata that might be accidentally or maliciously corrupted/lost.  The disadvantage is you miss any value obtained by atomically attaching signed metadata to the transaction.


Correct.  It is in the bond issuers interests to accurately track this -- they do not want to pay interest to everybody who inserts a "BONDHASH<abcd1234>" into the blockchain ;-)


Correct.


This is true, and it will typically be agreed beforehand who is paying fees.  An atomic coin swap involves two parties, but only one will likely pay fees.  If it is the smartcoin transferee, they will need to keep some small change for fees, yes.

(warning: highly biased answer from smart property dev follows )

It would be nice... but I think this first round of Bitcoin Foundation funding should focus more closely on higher priority issues, like getting Gavin paid or getting some basic Q/A resources in place.

There are many urgent issues facing bitcoin-the-currency, as outlined earlier in this thread.  After those are all solved, some attention to smart property and other advanced bitcoin uses (escrow, smart contracts) would be great.

The GUI is already decoupled from the "engine" as demonstrated by how bitcoind and bitcoin-qt are built from the same source code.  bitcoind is the base, built with zero GUI libraries.  bitcoin-qt is simply "bitcoind + GUI"

In general, there is wide agreement that separation should be improved, along similar lines like ones you suggest:

• core class libraries
• blockchain engine
• wallet handling
• graphical user interface

Separating out the class libraries would enable more applications to share the core code.
Separating out wallet handling into a separate process (and executable) will greatly increase security, ensuring that any bug in the P2P network triggered by a remote attacker would never overflow or corrupt the wallet process.
etc.

But as >90% of the full nodes are the reference implementation -- which remains the most complete and secure implementation to date -- keeping the network running securely has to take priority over these other things.

If you know C++... help!  Unlike what the tinfoil hats would have you believe, the dev team is still volunteers working on our own time (hopefully Gavin will be funded by BF real soon now, easing the pressure a bit).  It is easy to join the dev team, too:  just submit a useful pull request.  No forms to sign or anything

So file this under...   we agree with you, but need more developer resources and bandwidth to make that happen.

pybond has been renamed to smartcoin, as it will support more smart property and colored coins, than just bonds.  Github URL: https://github.com/jgarzik/smartcoin

That is all.

A couple pybond implementation notes:

1) pybond will add a "<BOND+hash><OP_DROP>" for tracking purposes, so I'm not doing much in terms of color tracking for now.

2) pybond / smartcoin will use two RPC endpoints:  one for smartcoins (colored coins), and one for bitcoin payments.  Thus, two wallets.  This seems safer than mixing smartcoins and regular bitcoins.  This "firewall" prevents any client from accidentally spending the wrong coins.

The best place to watch is probably this thread, though I am open to other suggestions.

Yes, leveldb is a pre-requisite for ultraprune.

It depends on your definition of "share"... locally or remotely?

A single torrent is simply a hash-of-hashes.  Each stream is a different torrent, with different hashes, even if torrent A is a strict subset of torrent B.

Your client may be modified to share streams which are multiple versions of the same file.  Would probably only need some small mods to existing clients, and would not break the network protocol.  So from that perspective: "yes"

Remote clients will see different hashes, and assume that each stream is separate and independent of each other.  So from that perspective: "no"

This thread was created as a meta-thread, intended to help collect various bitcoin "recipes."  What is recipe?  It is a concrete example with step-by-step instructions, understandable to programmers, that describes how to execute a specific type of bitcoin-enabled transaction.

Everyone understands the simple, popular send-bitcoins-to-pubkey transaction, but bitcoin offers so much more.  This cookbook, it is hoped, will showcase some of the less common, advanced uses of bitcoin.

If you would like to contribute a recipe, please start your own thread, and then post a link in this thread.  The OP will be updated as needed.  It would be great if these recipes were copied to / linked in the wiki, but since discussion facilities on the forum are better, this seemed like a better home for the cookbook.

Another goal is to eventually have a set of scripts which demonstrate these features.


Recipe:  2-of-2 escrow, using multisig

Link: https://people.xiph.org/~greg/escrowexample.txt

Bob wants to pay Alice 50tnbtc but prevent Alice from cheating him.  A good example of using multisig from start to finish.


Recipe: Trading between two bitcoin-like chains

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

Currencies that implement the same ideas as Bitcoin can be traded freely against each other without trust.


Recipe:  Atomic Coin Swapping

Link: https://bitcointalk.org/index.php?topic=112007.0

Two parties negotiate to swap bitcoins between themselves.   This is presented in the context of atomically exchanging payment for smartcoins (colored coins), but is not limited to that use case.  P2P mixing was another example use case someone suggested.

Hopefully version 0.8, with "ultraprune" will reduce the costs associated with running a full node.  Ultraprune is vastly more efficient, and can be run on slightly older/slower machines than current versions.