Updated post to reflect current funding targets in USD, not bitcoin since the price has drifted drastically since initial posting.

I'm working on an update to the message structures which should be posted soon, based on feedback from gmaxwell and other developers.

Those are technically stale blocks, not orphans.

/nitpick

hanwong, his wife is not a U.S. person, correct? So he has to file "Married, filing separately", and his wife is not required to do anything, correct? I understand why his wife needs a taxpayer identification number (to list on his filing), but why does she need to pay U.S. taxes too?

It's done based on local information.

You'll get more responses if you post in the right forum. This section is for bitcoin development.

You don't need to add it to the protocol, CoinJoin operates just fine at a strictly higher level. But I suppose you mean adding support to the reference wallet for CoinJoin transactions? I would not be surprised to see that happen, but someone needs to write the code first.

This wiki says that you can now change your chosen cost-basis method for investment assets:

http://www.bogleheads.org/wiki/Cost_basis_methods

Is this true?

I'll probably get an accountant to look this over (anyone know a good one in the SF bay area?), but this is how I'm going to proceed to get an estimate of what I owe and prep the documentation for the c.p.a:

I'm going to do specific identification using the block chain ledger. The block chain records which coins were used in a transaction, and so I can use that to determine the cost basis of coins sent to an exchange or used in a purchase. I did not think ahead enough to plan which coins I used, but I would like that capability in the future and therefore need to establish the specific identification method now. Within an exchange I'm not sure whether to use FIFO accounting or a weighted average since the coins are no longer distinguished. This distinction doesn't really affect me much as I tend not to leave coins on exchanges, but I'd be interested to know what approach is best for the future.

This will probably require a number of custom scripts to gather this information from the blockchain and generate CSV outputs, I'll publish that when it's ready.

I assume that I'll have to start paying quarterly income taxes now that most of my income is not from W-2's...

What's the point of having it if you're never going to use it?

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

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


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

The answer to your question as stated is that if you connect directly to a miner which accepts that transaction type, then you can get those transactions in their blocks. Just because some nodes won't relay doesn't mean other nodes won't include it in their blocks.

We have an altcoin forum for this.

Well..

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

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

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

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

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

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

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

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


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


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

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

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

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

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

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

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

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

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

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

You didn't say you wanted the entire unspent transaction output set

There is no way that I know of to do this from the command line / JSON-RPC, although that information is in your local database. You could write your own JSON-RPC handler to do it.

genjix, your wiki is incorrect. LevelDB is a log-structured merge tree which is an append-only data structure periodically compacted into new files. I just took a cursory glance, but mmht looks like it would have similar performance characteristics. Have you benchmarked HyperLevelDB? I would expect that the difference in performance is probably mostly due to *LevelDB's compaction and durability features (which aren't something you can hand-wave away.. I don't want my server to suddenly go down for 24 hours because the db got corrupted and it has to resync the block chain).

We're not on the topic of prohibited changes. Please create a new thread if you want to discuss that.