Here's my idea how to make something conceptually similar to CoinWitness for colored coins, without SCIP and without protocol changes: (SCIP is optional) I thought that my understanding of colored coins is more or less complete, but today I found that I had more to learn... I've been looking through a very naive (and broken) proposal to have Mastercoin in multiple blockchains at once, which prompted me to think: Is it even possible to do things like that? What is possible? It's worth noting that I've been thinking about multi-blockchain interactions since 2011, and all potential solutions I'm aware of are quite a bit cumbersome. (I'm not talking about cross-blockchain trade here, but about representing the same asset in multiple systems at once.) I'll skip some details for now, the basic idea is that if it is possible to embed a compact cryptographic proofs of off-chain transfer into a colored coin transaction (which colored coin agents will be able to verify when necessary), then it is possible to integrate colored coins with off-chain systems in a consistent, trustless way. The problem with off-chain transfers is that situations with ambiguity/lack of consensus are possible. But cryptocurrency transactions must be unambiguous. The current solution is to have a trusted party (potentially, some distributed entity, "d.a.c.") to work as an interface between an off-chain transfer system and a blockchain-based cryptocurrency (incl. colored coins). But as I found today, it's also possible to do it the other way around: embed a reference to proof into colored coin transaction and let participants to verify the proof. There is no longer a need for a trusted party: when reference to a proof is embedded into a transaction, all potential ambiguities are eliminated. To make it even better, we should re-think how we see colored coins. I think majority of people (at least, non-cryptographers) understand cryptocurrency as a ledger-based consensus: that is, there is a ledger which shows how much money each one has. But a more general approach is to see it as a system based on proofs... Say, "Alice has 50 coins" means that Alice is able to prove that she has 50 coins. "Alice transfers 50 coins to Bob" means that Alice performed an action which now allows Bob to prove that he has 50 coins. The difference is that we don't need to make sure that we know balance of each account; Alice and Bob are concerned only about their own balances. Switching to this model would make off-chain transfers I've outlined above feasible in practice. Also it mitigates problems with consensus/hard forks: if we assume that an interactive proof protocol is used when payment is made, it's possible to make sure that hard forks can't result in permanent monetary loss. Now the only problem which remains is compactness of proofs... I.e. a performance problem. Ultimately it can be addressed through SCIP or other compact proof system, I think. But at least this framework lets users to choose level of assuredness they are comfortable with. It's worth noting that it is somewhat similar to Gregory Maxwell's CoinWitness idea: https://bitcointalk.org/index.php?topic=277389.0The difference is that in my case neither SCIP nor changes to Bitcoin protocol are required. So it's feasible to implement it right now, and it's not terribly complex... In terms of complexity, it is what a bunch of undergrad CS students could do. EDIT: Users who run thin clients and thus are unable to verify proofs themselves can outsource verification to a network of validators à la Ripple consensus ( https://ripple.com/wiki/Consensus#Not_colluding). Of course, it is possible that these validators would collude and try to fool users. Such collusion can be detected by any entity which runs verification independently, and a cryptographic proof of wrongdoing can be produced. Due to the nature of colored coins, damage from this collusion will be limited to users who: 1) trusted validators; 2) accepted payments when collusion was in effect. Others will be unaffected. Thus robustness of colored coins w.r.t. erroneous transactions might allow us to replace a complex approach like SCIP with simpler one (but less reliable). |
|
|
|
|
The main problem with this proposal is that you learned about inner workings of cryptocurrencies via block explorer sites... These sites show information in the convenient way, and certainly you can learn from them, but they don't show you the whole picture.
The most important thing about cryptocurrency is consensus, and your proposal completely sidesteps that... You really need to think in terms of information available to client software, not in terms of what is available on block explorer web sites.
That said, something like this is theoretically possible... But you need one blockchain to be authoritative. Also, there is a problem with amount of information you need to include into that blockchain.
EDIT: Within the Mastercoin model it is possible only if each client follows all blockchains, and even then it's kinda problematic.
|
|
|
|
Did I get that correct? Yes. Further, why does the whitepaper alternative coloring mechanisms? Is there a preferred one? We haven't settled on the best one, so we need to consider several alternatives. However, the point of this theoretic model is that multiple mechanisms can co-exist. For the start we are most interested in one which simply follows the rule of conservation, as it has many uses. But there are other interesting applications, which will require custom color kernels. (One example is prediction/derivatives market.) Are we at this time saying that coloring will be preserved only if we use a compatible client? It's always the case... But, in practice, special 'color addresses' prevent potential incompatibility problems: each color has an identifier, hash of that identifier is embedded into the address in such a way that client can check if identifier matches. This means that if your client doesn't support color "green", you won't be able to produce an address for color "green", and thus nobody will send you "green" coins. |
|
|
|
What I don't understand is, which actor executes the color kernel? Well, the point of executing color kernel is to find colorvalues... So each actor which is interested in finding colorvalues need to execute it, unless it can get colorvalues from trusted source. (E.g. via a cryptographic proof of some sort.) Do you envision the miners executing the color kernel? No, I see colored coins as an alternative to protocol changes. Having something on protocol level definitely has benefits, e.g. SPV (thin clients need very little information to verify payment), but it might be problematic: 1. hard fork is required (likely) 2. a problem in additional features might lead to consensus problems 3. changes are not compartmentalized 4. it's hard to add features, upgrade over time, etc. (again, hard fork is required) But that's the theory... In practice, if you care about things like user currencies, securities and so on, they aren't that hard to implement, so a Bitcoin protocol upgrade (such as Freimarkets) is desirable. Would that need an upgrade of the entire bitcoin network? Yes... It is known as 'hard fork'. Will wallets with the recepient address execute the color kernel? Yes... Basically, when you see an incoming UTXO, you want to know its colorvalue, so you run the computation... But there are several different computation strategies, like pre-computing everything, or computing on demand only. |
|
|
|
So how does Mastercoin ensure that the data in the Mastercoin packet matches the balance available from the sender? It doesn't need to. Each Mastercoin client scans Bitcoin blockchain, tracking balance of each address. Transaction which tries to send wrong amount of mastercoins is not a problem, as clients will take available balance into account when calculating the amount being transferred. Particularly, if you have 1 msc and try to send two 1 msc transactions, only the first payment will be considered valid. This solves double-spending problem. If the miners don't know of mastercoin data, then what is the entity that ensures that money that is transferred is correct? Every client processes same data using same rules, so they all arrive to the same state, thus there is a consensus. |
|
|
|
I think the reason why most people here do not like colored coin is simple. They cannot invest on it. Colored coin is just like a traditional open source project, where people earn reputation but no money. Actually pretty much everybody who worked on colored coins were paid nicely, in one way or another. Currently people who work on ChromaWallet are paid $50/hour + bonuses. That said, it make sense to say that msc may have better chance to succeed because the developers have more incentives. Colored coin has been developed for a long period and the slow progress Could be explained by its volunteer nature. I'm not so sure about that...Just like in case with Mastercoin we started in September and got decentralized exchange by January. I mean, a year ago. We did it with much fewer resources, though. The difference is that we didn't recommend people to start using a half-baked thing; the goal was to make a secure lightweight wallet (which is nearly impossible in case with Mastercoin), and that takes time... |
|
|
|
Mastercoin - doubtful how this approach of protocol layering prevents double spending.
NXT - Closed source implementation. Does anyone have any idea of how this actually works? How fair is the distribution when all coins were bought for a mere 21 BTC.
Colored Coins - Fortunately, they don't have a ridiculous buy in vehicle to support their work.
Bitshares - So these folks use a bitcoin like clone to raise funds. They are redoing everything from scratch. Anybody's guess that this even works out.
eMunie - I heard about it 6 months ago, not certain if their multiple simultaneous block chain forks really work.
Anyway, my plan for iXcoin (The Internet eXchange Coin) is dirt simple.
Stick with tried and proven Satoshi Nakamoto bitcoin technology and layer on top of it Colored Coins. You forgot about Friemarkets. The proposal is very solid, they are going to develop it as a Bitcoin protocol upgrade (which is superior to colored coins in many ways, but requires much more work), and add it to Freicoin, the alt-coin. They have a competent team... The only problem is that they are looking for $200k in donations to make this happen. |
|
|
|
How do you "import" and reissue a security that was previously issued in one of those closed exchanges like btct.co etc? We'll probably write some kind of script for that when software will be ready to run on mainnet (I hope in January) and IF there is interest in this. I think it can be some kind of a web site where user enters his colored coin address, signed with his public address on btct.co. Then once a list of colored coin addresses are obtained, script will send them colored coins according to data from btct.co. |
|
|
|
So, when are we going to have a lightweight version of the wallet? If it requires Bitcoin-qt it will be a big challenge to get users to use it.
Indeed. We plan to include this option (run without local bitcoind) into the beta release. (Probably in January.) We have already implemented a very basic version of backward scan in coloredcoinlib: https://github.com/bitcoinx/ngcccbase/blob/master/coloredcoinlib/colordata.py#L76But it needs some improvements... Also it isn't recommended for use with OBC. |
|
|
|
Just in case, what is available now is a preview, alpha version, meant only to run on the testnet. It's still possible that we'll change some substantial aspect, I don't want to be tied to this old release. Will you also add support for tagging-based or per-satoshi coloring? Yes. In fact we already implemented some form of tagging: https://github.com/bitcoinx/ngcccbase/issues/27#issuecomment-29735370but it's less than perfect... I have some improvements in mind which could make it satisfactory, but I'm waiting for comments from Vitalik Buterin who writes "BitcoinX whitepaper": ideally we would use same kind of coloring scheme in BitcoinX and chromatoken versions. Also I'd like to get comments from Peter Todd (bitfield-tagged color kernel mentioned above is based on his ideas). He now works for Mastercoin, but I don't know whether that preclude him from helping us with coloring schemes. In simple terms, I know a way to make both padding and scaling parametrizable on transaction level, which will let us to achieve nearly-optimal satoshi efficiency. Also transactions will have unique signature, which is important for backward-scan traversal strategy. I'm not sure whether we should use nSequence or OP_RETURN. nSequence is more efficient, but seems kinda hackish. Also any scheme with padding or scaling creates some accounting problems, but we can probably take them into account in p2ptrade with some effort.
We won't implement per-satoshi tracking. I actually implemented it for a different project (twice!), but I'm not going to add it to coloredcoinlib because it's not compatible with thin clients (if colored satoshi can be paid as a fee), and hard to deal with anyway. |
|
|
|
So far, using colored coins seems to be my best bet, but I'm wondering if certain things are possible: It's worth noting that colored coins concept is fairly general, it can be customized for a specific application. It's not just "what chromawallet can do". ChromaWallet is just one of applications. 1. Can an issuer color coins that don't belong to him? Yes. Color exists only as a client-side configuration, so you can just add a new definition. (This isn't true for all implementations of colored coins, say, BitcoinX specification requires a particular format of a genesis transaction. But chromawallet/chromatoken implementation is very flexible.) It would be very inconvenient for the other person to have to return the coal to me in order for me to light it on fire. Well, that can be implemented as a special kind of transaction, similar to how p2ptrade works. But you gotta pay a fee for that. If you're talking about cheap-ass assets, it's better to avoid fees... 2. How long can a moniker be, Monikers exist only on client simply for convenience. They can be arbitrarily long, but you probably want a custom asset definition format, there is no need to stuff all the information into the moniker. and do I need to worry about spamming the blockchain if I make 10,000 different colors? Each particular colored coin is a separate transaction output. 10000 doesn't sound like a large number... and it might potentially mean a separate color for each and every of the 10,000 different pieces of coal in my application. People usually call this approach (separate color for each individual thing) it 'smart property' or 'transferable virtual property'. See here: https://en.bitcoin.it/wiki/Contracts3. Is it possible for me to determine the order that colors were added to a satoshi? Depends on how you introduce these colors... Additionally, bitcoin's transaction fee is currently way too expensive for my application. I can't justify selling pieces of coal that only have uses inside my application at 0.0001 btc each when the transaction fee is another 0.0001 btc. This would be easily fixed by my using a cryptocurrency with a cheaper fee. Are there any plans to develop a version of ChromaWallet that can work with other cryptocurrencies? Yes, but you should consider other options, like something not based on blockchains... OpenTransactions, maybe? You'll have to run your own server, but transactions can be free, I think. I have no idea how hard is it to customize it, though. |
|
|
|
I think this is a bad idea Insane fees might actually create a problem for consensus: when fee exceeds X/p where X is an average block payoff and p is a probability that a miner will mine the next block (aka the percentage of hash rate), it makes sense to mine a block which includes a transaction with this obscene fee instead of mining a block on top of the longest chain. Hypothetically, a software bug which sends a huge sum to a fee could destabilize the whole network if miners were game-theoretically rational. For example, suppose somebody who has has 100,000 BTC in one wallet uses custom software to make a transaction (he absolutely needs to do it on a highly secure, air-gapped system; standard software doesn't cut), and fucks up signing a transaction with a 100,000 BTC fee. This kills the Bitcoin. Why? I don't know about you, but if I was a mining pool operator, I'd rush to keyboard and try to patch bitcoind to make it mine that transaction no matter what. Perhaps the opportunity cost is on scale of 50 BTC, but it doesn't matter when 100,000 BTC is on table (and sometimes pools have bad luck/orphans/outages, it isn't unheard of). Now suppose there is an IsStandard rules against insane fees, it will prevent propagation, and perhaps a rich guy who has 100,000 BTC would double-check it. Catastrophe averted. Good idea, jl2012! |
|
|
|
When I try to run "ngccc-cli setval testnet true" (after creating bitcoin.conf and opening bitcoin-qt on testnet) I get these errors in the console:
Exception: Unable to connect to electrum.cafebitcoin.com:50001
I think I know why this happens... Well, next release will fix this and other problems. |
|
|
|
You mean NGCCC will support Matchmaking Tradeoff eventually ? Sorry, I'm not familiar with this concept, but I can say that this part is very flexible, so we can implement pretty much any matching strategy if there is a need for it. |
|
|
|
I'm not sure when does it happen.It doesn't always occur,I think it has nothing to do with my operation. Nevermind, we already fixed it in code (it isn't yet in the build). I have tried the P2P trade,I found I can only make deal with somebody who offered the same amount and the same price.
Yes. Basically, we didn't bother with partial fills yet. Can I buy some assets from others who sell lower price than my offered and higher amount than mine? Eventually. Another question,what does atom and unit mean when issuing a asset . That dialog is rather confusing, we'll change it in new version. Basically, "atoms" is number of satoshi in one unit. "units" means how many units you want to issue, i.e. quantity of units. Where does the colored btc go and colored BTCs can be uncolored and used again? NGCCC just tracks which addresses are colored and which aren't. If you no longer need colored coins it could just sent them to uncolored address, but it isn't implemented yet. |
|
|
|
It's very nice of you guys,Killerstorm and NuclearReactor.Thank you for your helps and I have built my windows version and I can see the NGCCC test client GUI. I am so excited.
I had some test bitcoins and I tried issuing some new assets but I don't know how can I get the new assets balance? It's a known bug, you need to restart the client to see it. And I received the followiing message,I don't know if it has any help. Hmm, haven't seen this one yet: when does it happen? |
|
|
|
Oh crap, wallet.db which I used for testing got into zip file. So, basically, we all share same wallet.  Please delete wallet.db file before starting, it will generate a new one. |
|
|
|
What is the dependency for the windows version.Should I install bitcoind and sip,pyqt4 etc.Anybody can give me a guide,thank you.
You need to have bitcoind or bitcoin-qt with enabled RPC running on the local computer. http://bitcoin.org/en/downloadYou need to create bitcoin.conf with rpcuser/rpcpassword (it should be put into %APPDATA%\Bitcoin), then run bitcoin-qt -testnet -txindex -server There are no other dependencies, it is all in one package. Run ngccc-cli setval testnet true to set it to testnet mode, then you can just run ngccc-gui. However, I should note that sharing "asset definition" isn't very convenient now, maybe it's better to wait till we make a better version later this week. |
|
|
|
|
Show Posts
