Topic: colored bitcoin tech discussion - page 2. (Read 13199 times)

Centralized exchanges are, obviously, the weakest points, in many ways.

It is possible to construct rating agencies (we call them this way now) in such a way that it's pretty much impossible to attack them. You can operate one fully anonymously, simply signing messages like "After performing checks X, Y and Z, I believe that company ABC is trustworthy". How can they shut you down?

Of course, it is always possible to go after individual business. Ultimately, it will be the weakest part.

But if we remove these other weak parts (which were actually unnecessary), it's possible to focus on the actual problem: making it possible for companies to raise capital without violating laws.

It might be possible either through registering companies in jurisdictions which allow that, or using proxies/intermediaries. However, IANAL.

Checkout bittorrent and Tor.
Gateways and merchants have a bested interest in running their own validator node.

http://bitcoin.stackexchange.com/questions/7567/what-benefit-or-incentive-is-there-for-someone-to-run-their-own-ripple-client-or


This exposure is unnecessary.
This doesn't solve divisibility. If the represented assets ever go below their BTC underlying "reserves", the assets will never be redemed, as people would "cash the BTC out".


If you need to charge for the UTXO (and I don't think so), a flat demurrage fee would better than an arbitrary "reserve" or minimum output.


You need to separate the network of validator peers from the financial network inside ripple.
Every user can issue. Gateways are just "more official" issuers. http://bitcoin.stackexchange.com/questions/7620/how-does-a-gateway-iou-differ-from-any-other-iou-on-the-ripple-network

Gateways will usually be also validators, but it's not a requirement.
If ANY validator acts dishonestly according to the rules (for example, pretending it hasn't received certain transaction) the rest of the nodes will ignore him.

Yes. They can also do it for free, if they want.

Yes, every user can do mostly what gateways can do.
A gateway uses "Rippled" to more advanced things.
If they will do as they said, Rippled and Ripple server will be open source as the client is now.

I don't know, I'm a fan of the project but I'm not so deep in it
Anyway I can't see the reason so that a transaction won't be beneficial to it.

As it seems everyone can be a gateway and chose which fee to add (or not) to transactions.
It should be a completely free market.

Anyway if you want you can try it now, just register an account and deposit some XRP from Bitstamp or someone else.

Thanks.

If I understand correctly, using a gateway costs you non-negligible amount of money.

Is it possible to use Ripple without using gateways? Like, issue your own IOUs etc.

Is it possible for gateways to ignore transactions which aren't beneficial to gateways?

I see two possibilities:

1. Either people are forced to use gateways so that in the end they pay more.
2. Or these almost-free transactions are not good for gateways and they'll try to curb them.

https://ripple.com/wiki/Gateway_Integration_Manual#Gateway_Revenue
https://ripple.com/wiki/Transit_Fees

Every gateway will probably want to be also a server.

From here: https://ripple.com/wiki/Introduction_to_Ripple_for_Bitcoiners#Ripple_is_a_payment_system


Well... It can work that way if Bitstamp agrees to have some exposure to BTC. E.g. suppose Bitstamp gets 5 BTC, colors them as USDcoins and sells USDcoins for $10000. Bitstamp now has $10000 in reserves. Time passes and users redeem USDcoins. Bitstamp gets 5 BTC back.


Problem is definitely bigger, I think nobody doubts that. But solution is complex, if exists at all.

No, but an issuer could issue IOUs in both networks. For example, Bitstamp could issue bitstampUSD as colored coins, to be traded atomically for BTC just as they issue bitstampUSD in Ripple to be traded for bitstampBTC or XRP.


It has near zero cost in Ripple and could perfectly have near zero cost in Bitcoin.


I don't think Bitstamp are scammers. In the other hand, I want to be able to buy 110.5 bitstampUSD for 110.5 usd instead of 110.5 + (price of bitcoin in usd/ dust_constant) usd. And then be able to buy 1 BTC for 110.5 bitstampUSD. Or 0.89 btc for whatever its price is at the moment in bitstampUSD with 4 decimals for USD precision.
With this new "soft-rule" that just saves miners the hurdle of paging the UTXO efficiently instead of want it all in RAM, what I think will happen is that Bitstamp will just not issue usd IOUs as colored coins, and save their users the pain of dealing with non-divisible digital numbers.

I think 5000 satoshis reserve for an atomic indivisible unit is too much, and I think 1 satoshi is too much too, we don't need underlying satoshis if we change the protocol.

If you pay your fees you can use the chain; you don't pay fees, you don't.

That should be enough.
If fees are not enough, the problem is bigger than what can be "solved" with this patch.

retep wrote a comment in github discussion of anti-dust patch ( https://github.com/bitcoin/bitcoin/pull/2577 ):



I want to comment on this...

First, I don't think that anti-dust patch causes problem for colored coins... People should just accept that creating units has non-zero cost.

Suppose you want to issue USDcoins (a pegged currency). You can make a unit such that 50000 satoshi = 1 USDcoin.

Then to create 1 USDcoin you need $0.065 worth of Bitcoins at current exchange rate. E.g. to issue $10000 in USDcoins you need $650 worth of Bitcoins. Is it a problem?

It might be a problem if you're 12 year old scammer who doesn't get enough money from parents, but if you're a honest issuer getting Bitcoins upfront won't be a problem.

Then, Gavin's patch would ban sending less than $0.11, while retep's patch would require to send at least $1 in USDcoins.

Is that a problem? I don't think so... If you need to send something on $1 scale, fees will bite you anyway... At such scales off-blockchain transactions can be useful.

Divisibility might be desired for some uses, such as issuing shares which might fluctuate in value (e.g. see what happened to Berkshire Hathaway), but I don't think it is a crucial issue. If anything, there is a mechanism for issuer to re-issue shares and exchange old shares for new shares.

---

Another question is why we don't use retep's coloring mechanism... Well, there are several reasons for that.

First of all, we considered something similar (color tags in value or in scriptPubKey), but:

1. Odd/even trick works only for one color in transaction, which rules out plenty of interesting things, such as, for example, exchanging GOLDcoins for USDcoins, Ripple-like multiparty transactions, multiple issues and assets with multiple issuers.

2. There are two problems with tags in scriptPubKey: they add to blockchain bloat, and they need a specific scriptPubKey format.

So, basically, we need to define how output is color-tagged for each scriptPubKey form... Which is a bad thing, I think.

Only fixed number of script forms can be used, and adding more will require a colored coin analog of hard-fork, i.e. an upgrade for all colored coin clients.

On the other hand, order-based coloring does not require any particular form of script. You can use P2SH, not use P2SH, use multi-signature transactions, any contracts... It just works (tm), and requires no hard forks, ever.

So the reason to use order-based coloring instead of color tagging is minimal overhead and maximum flexibility w.r.t. advanced scripts.

Another reason is complexity... Order-based coloring requires just a couple hundred lines of code to implement, and so does modification of wallet. p2ptrade implementation is just 500 lines of code in Python. (It is pretty much trivial to compose multi-party transactions, see here: http://i.imgur.com/UIFfvr8.png)

On the other hand, implementing retep's contracts would require like 10000 lines of code... It's not only a problem to write such code, it is a problem that there will be a shitload of corner cases and, thus, bugs. (There is a reason why we have colored coin implementations (I think we now have something like four of them), but no fidelity bond implementations, right?)

Even contract value accounting is a problem:


To implement this exactly, you need infinite precision rational numbers (SUM(vout) can be anything, right?)... and this is not what I want to see in finance software, let alone crypto software...

One could require SUM(vout) to be in form 10^i for some integer i. But even then you need bignums to work with these numbers... Suppose somebody clever will divide shares into 0.1 and 0.00000000000000000000000000001, and will add them together. How much memory do you need to store this value?

So, to summarize, retep's contract mechanism offers small advantages, but big disadvantages, and we aren't going to use it.

(Also there is a desire to get shit done without spending years on discussion. Even if that accounting mechanism was clearly superior, solution which is "good enough" shouldn't be replaced with something better just because it is better.)

This may be a dumb question but could Ripple and its 'exchange' features be used for coloured coins if there was a trusted Gateway for coloured coins?

Okay, so far so good. I'm really liking the idea of colored coins (vs. what I originally had planned for my own purposes) more and more.  This way is a hell of a lot more work, but if it follows a clear standard that can then be improved upon by the community, I'm ALL for it!  However, I want to make sure I'm following the "correct" protocols that you've defined (or have been agreed upon). I'm getting lost in the amount of threads on this subject and find myself making multiple circles just looking for up-to-date information. Is there a static page or a wiki that has everything clearly defined (and is up-to-date)?

To make sense of all the information I created an index of relevant links as well as a faq.  These are for my own purposes, but I'd like to be able to read and contribute to a community page (if one exists).

thanks,
s.

ArmoryX colored coin client already uses there atomic transactions for p2ptrade.

Generally speaking, Bitcoin transactions have multiple inputs and multiple outputs from the start, so it was always possible to use them for atomic transfers. The only diffculty is construction and signing of such transaction.


Yeah, I've heard about it, but I'm not a big fan of Java and RDBMS stuff. Perhaps we might use it when we'll do something enterprisey

interesting. thanks for the answers. still so much to learn.

also, i think you mentioned that its possible to have transaction atomicity in bitcoin's current implementation. is that true or is it planned for a future release?

FYI - i originally found your thread in a search for bitcoinjs. it's a wonderful library and so far i've been really happy with the results. i've been able to successfully customize its database logic (something i just couldn't manage with bitcoind or bitcoinj) to suit my specific needs. this may overlap with your coloring project so I'll be keeping on close eye on your implementations as well as where i can contribute.

Also, have you looked at https://github.com/bitsofproof/supernode. its a modular implementation of bitcoind written in java. i love the api and the fact that it can run over a rdbms (although i haven't gotten that to work yet). the SQL capability "may" give you better performance for your blockchain queries (although i admit that i don't quite fully understand your protocols yet). i have some ideas that i'd like to share once i have a better understanding and i'll certainly keep your needs in mind during my own coding efforts.

cheers!

Yes.


Yes.

Basically they get uncolored only if transaction violates order-based coloring rules, i.e. it was created by nonconformant software (e.g. by client which knows nothing about coloring).

@killerstorm - i've been following the various threads for this colored coin project and there is one thing that is really confusing to me. you've mentioned quite often that combining different colors into the same transaction would in fact make them "uncolored". but then you talk about using ordered inputs and outputs with various coin colors in the same transaction.

so is it possible to have multiple inputs, delivered to multiple outputs for the SAME destination address ? so then the uncoloring would only happen, when several colored inputs where delivered to the SAME output? (this comes from my still elementary understanding of the anatomy of a transaction)

thanks.

We haven't settled on this yet, there are several proposals and no implementation. (There is a lot of discussion in bitcoinx google group.) Proposals:

1.Issuing address: All coins sent from a certain address are colored. So company's officers which have access to private key, they can create new shares. You have to trust the company anyway, otherwise shares are worthless. So you can trust that they issue correct amount. The problem is that private key might be stolen and thief will issue and and try to sell unlimited amount of shares.

Possible ways to mitigate the problem:

• Cool-off period: coins are not considered valid for, say, first 144 blocks, and so people have time to react to new issuance. If issuance is not authorized, they will freeze all trade and find a way to fix this, e.g. replacing color
• Limit total number of coins in color definition, then client will consider freshly issued coins only if it sees that some shares were destroyed
• Better protection for private key: use multiple signatures, offline storage etc.

2. Color definition replacement: Company creates a new color definition, signs it and uploads it into color directory. Client software periodically checks for updates. If definition is updated, client software asks user whether he trusts new definition, and user might do some out-of-band check before he makes color definition active. Meanwhile, if you haven't updated your color definition and others did, you won't be able to trade these coins on market as colorid is different. So you cannot accidentally purchase newly issued coins on market if you haven't activated color definition replacement.

3. Color definitions embedded into blockchain. I'm not sure if anybody is advocating that right now, so I won't go into details.

(I'm personally for color definition replacements... Color definition is like a contract, and contracts are meant to be amendable.)


ArmoryX creates a list of all colored transaction outputs, I think it won't be hard to calculate total amount, but it doesn't do it now.


Well, if we are talking about shares, I don't think they were destroyed...

On a fundamental level, we track ownership of an asset through a chain of digital signatures, each signing the transfer.

If coins were mixed then transfer did not happen (analogy: a garbled message was signed), so previous owner still technically owns them.

From this point of view, person who signed that color-mixing transaction still owns shares, but he cannot transfer them because of limitations of the protocol. So his shares are effectively frozen, and issuer's action is needed to unblock them.

But that's how we humans look at it... Client software will simply show 0 balance on both ends, as it shows only what can be transferred. So human is supposed to check blockchain to see what happened and fix the situation. (Of course, it can be automatized, but I doubt it will happen so often that it makes sense...)

By the way, while we are here, dividends should be paid to addresses which hold shares by a certain block. And same thing applies to voting. If dividends are paid at block 210000, software should create a list of owning addresses and their shares at that time. If somebody transfers shares in block 210001, he won't receive block-210000 dividends. (All this stuff with votes and dividends isn't implemented yet, but I think that's how it is supposed to work.)

I think the key is that color destruction is provable, and issuer-mediation can fix it.  But, when 10% of the shares of a company are destroyed, how do other 90% owners of that company know what the new issuance will be?  Is it a subscription service that the color definitions can be updated?  Do clients try to track all related coins and know what the total amount is?  Without new color definitions other users may believe that their own shares popped up in value by 11% when those 10% shares were destroyed. 

Well, if we are dealing with cryptocurrency shares of a company can go *poof* in many ways. Wallet lost, sent to wrong (particularly, non-existing) address.

We can assume that if coins got mixed it's also likely that they went to a wrong address.

What's the sensible reaction here? I'd say destruction is a feature, not a bug. Original owner can prove that he owned that shares and he can ask for replacement from issuer. Issuer can investigate the situation, and if shares were indeed destroyed he can issue some new ones and give them to this shareholder free of charge.

However, if coins are not destroyed, they might end up in a wallet of a person who isn't supposed to own them, and you cannot fix that if that person does not cooperate.

So I think it's better to destroy color label in case of a dubious transaction and rely on manual resolution.


Considerably more complex implementation: each transaction output now has a spectrum rather than a single color, and value for each color is represented by infinite precision fraction. I.e. you can end up owning 230918409134/21332840932904832984 of a company.

But, importantly, it doesn't really address the problem: if coins were diluted due to some software problem, we can't be sure that, diluted or not, output went to a correct address.

Also, you can't undilute coins, if they are mixed, they are mixed forever.

Note that with my approach towards mixing, automatic un-mixing  is possible, it just needs to be issuer-mediated.

For example, issuer publishes unmix-this-please address. If there is a fuck-up, person sends his mixed coins to that address, issuer transfers them internally and returns some part of coins via his issuing address, thus making them colored again. The rest is returned via a normal address, which leaves them uncolored.

If several colors are mixed, issuers can use deterministic satoshi tracking algo to verify correctness. (The idea is to assign an unique number to each coinbase satoshi, tracking it through transactions and fees. Then color of satoshi is preserved under all transformations.)


Eh, what? If you more than one color together it ALWAYS get diluted?

Then there is no way to implement decentralized exchange via atomic coin swapping, for example. Not to mention that even sending coins is problematic (i.e. you cannot pay a fee and get change in same transaction, you'll have to prepare utxos with exact change value in advance).

IMHO decentralized exchange is colored coins raison d'être, so any implementation which doesn't allow that is largely useless.


People mentioned dilution as an alternative to destruction in case of mixing, but not as a coloring algorithm on its own.

Other proposed alternatives are deterministic satoshi tracking (order-based) and color tagging.

EDIT: etotheipi, never mind, I can't read... (took mixing as talking about divisibility)

I think you need to first ask the question "What does an SPV client need to validate a colored coin?"

The coin in it's present form will be in the txout set, but the history won't be, so the client needs to get a set of merkle transactions - a tx + the merkle branches back to the block header - linking the current txout representing the coin to the transaction that issued the coin in the first place.

But once you have that, why does divisibility matter anyway? Just have a standard to distinguish colored and non-colored txouts in a transaction - odd/even number of satoshi's works fine - and as you walk the transaction history dag back to the issuing transaction compute the percentage of total colored value that each txout leading to you represented. If divisibility is ever a problem in one of the transactions just add some value in the txin that isn't returned in change. Here's a concrete example:

Alice issues her "Alice Mining Bonds" and manages to sell %10 of the initial issue immediately to Bob and another %10 to Charlie: (for simplicity I'll leave off the odd-even satoshi's trick)

Charlie then turns around and sells a quarter of his share to David, and keeps the rest:


Now David has a txout worth 0.0025, and the merkle tx from Charlie and finally the initial issuing tx. He knows that he got 25% of the value of the tx Charlie gave him, and Charlie got %10 of the value of the issuing tx; %25 * %10 = %2.5 of the initial bond issue. This technique makes paying for mining fees easy, doesn't force you to tie up Bitcoins just for bonds, allows whatever divisibility is required, and having the merkle tx's available makes implementing bonds on SPV clients easy anyway.

FWIW I'm planning on having my Fidelity Bonds idea work this way.

Incidentally this also suggests a better hashing algorithm for transactions: hash the transactions themselves as some sort of merkle tree. It'd work really nicely if the intermediate hash values included the sum of the tx values under that node in the tree, so the fact that the tx was accepted into the blockchain was proof of the total txout and txin value, without having to actually have copies of any particular txin or txout. Specifically for a tx looking like this:


The hash of the txin's would be calculated as H(0.6 | (H(H(txinC) | H(0.3 | H(H(txinA) | H(txinB))))), the txouts similarly, and the final tx hash H(txin_root_hash | txout_root_hash | locktime etc). (obviously extend this with HMACs and what-not as required to deal with non-ideal hash functions)

Now for a really big issue transaction the merkle branches within the transaction itself are enough to prove the ratio of your bond vs. the issue as a whole. If the issue was for a few thousand bond-holders this is a big deal.

Also this idea can be extended to the transaction values within a block to make it harder for miners to get away with inflating the number of bitcoins to SPV clients, who now just have to pick random parts of the transaction tree to probabilisticly audit for inflation fraud via detecting non-existent transactions. Similarly SPV clients can just add the the total txin and txout values and check that the change in total number of coins from the previous block header is equal to the current block reward. Fraud due to a non-existent transaction can be broadcast by broadcasting the merkle branch suspected of not actually existing, and the broadcast can be quenched by anyone broadcasting a matching transaction. If any SPV node sees an unquenched fraud notice, they don't mine to extend that block further.

Of course, none of the above is implemented yet, but it can be implemented as a merge-mined soft-fork, the same way all the "hash of the txout set" proposals work.

EDIT: cleaned up the stuff above and posted under it's own topic: https://bitcointalksearch.org/topic/inflation-proofing-via-fraud-notices-137933

Sorry, joining this discussion kinda late.  I just read through this thread and didn't see a few things that I was hoping to comprehend.  Maybe someone can link me to where this was discussed.

At least in terms of smart property, the idea that mixing color is destroyed seems dangerous.  Mainly because a subtle client bug that still creates valid transactions could end up destroying property.  When you say that mixing colors destroys coins, that means shares of a company can go *poof*.  Not likely to happen by accident, but I bet it will happen at some point.  To someone, somewhere (wrong color ordering, fee subtracted from the wrong place, colored accidentally ending up in the tx fee).  It could possibly even happen maliciously.   I'd really like to see that coloring is preserved, and that mixing 1 satoshi into your 10 BTC of colored coins does not destroy it.

So what is wrong with diluted colors?  i.e. what is wrong with this scenario?

• I create a 200 BTC genesis tx for "green".  Let's say that green represents shares in a company worth $200,000
• I distribute 10 BTC to each of 20 people who now own 5% of that company.  So that 10 BTC is worth (10*MtGoxRate + 5%*CompanyValue).  At the current price of $16.70/BTC, that means those 10 BTC are worth $10,000 + $167 = $10,167
• I send someone a 100 BTC transaction, using 90 BTC of uncolored inputs and this 10 BTC green input. That person now owns 5% of the company contained in 100 BTC.  (100*BTC + 5%CompanyValue)
• That person can now sell someone 40 BTC from that 100 for (40*MtGoxRate + 2%*CompanyValue).

This seems deterministic, unambiguous, and retains the transparency.  There is no ordering, or need to understand specific color rules.  Obviously the more that coins are diluted, the more annoying it is to handle/sell them, so users would be naturally avoid mixing them, but there may be valid reasons for doing so.  At some point the dilution can be so much that there's no point, anymore, and the color is effectively destroyed (perhaps below 1% density).  But it wouldn't result in a loss of property without them passing through a lot of oblivious clients.

I'm sure I'm not the first person to think of it.  Can someone explain the drawbacks to this method or link me to where it's discussed?