colored bitcoin tech discussion

[jgarzik]

Only the issuer needs to have any block chain bulk, so the Asset Issuer ID, the Bitcoin Address -  are the same thing.

Each smart property token has its own separate block chain storage, just like individual bitcoins.

Additionally, if you want a fully auditable system -- we do -- then you need a commonly agreed way to make payments to token holders (asset owners) viewable and traceable in the block chain.

That way, you can see which issuers are paying as they claim.

[etotheipi]

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?

[Peter Todd]

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)

Code:

txInA 0.115 BTC -> Bob     0.0010
                -> Charlie 0.0010
                -> Alice   0.0090
                -> Change  0.1050
                -> Fee     0.0001

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

Code:

Charlie's Bond 0.001  -> Charlie 0.0075
another txin   0.1426 -> David   0.0025
                      -> Change  0.1324
                      -> Fee     0.0001

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:

Code:

txinA 0.1
txinB 0.2
txinC 0.3

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://bitcointalk.org/index.php?topic=137933

[killerstorm]

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.

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.

So what is wrong with diluted colors?

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.)

There is no ordering, or need to understand specific color rules.

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.

I'm sure I'm not the first person to think of it.

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.

[etotheipi]

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.

...

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.)

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. 

[killerstorm]

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?

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.)

Do clients try to track all related coins and know what the total amount is?

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.

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 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.)

[nyusternie]

@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.

[killerstorm]

so is it possible to have multiple inputs, delivered to multiple outputs for the SAME destination address ?

Yes.

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)

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).

[nyusternie]

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!

[killerstorm]

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?

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.

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.

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

[nyusternie]

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.

[matthewh3]

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?

[killerstorm]

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

You know, if the colored coin people can't figure out how to make colored coin systems work with this patch, screw them. I've told them how to do it right multiple times and they don't listen, which is plenty enough evidence that they're amateurs who don't understand what they're doing. So why let their lack of imagination threaten Bitcoin?

Sure: https://github.com/petertodd/trustbits/blob/master/fidelitybond.md#contracts It's from my fidelity bonds stuff, but the mechanism is just a way of doing colored coins really. The advantage is that because value isn't a fixed ratio of shared to satoshi's you can divide however much you want and still avoid dust rules, and it's friendly to SPV nodes. Now if your bond value is smaller than a tx fee, well, use a off-chain tx system that's compatible with Bitcoin transactions, basically a blockchain who's contents is guaranteed by a third party.

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: https://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:

Code:

 Vout_n = SUM(Vin) * vout_n/SUM(vout) 

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.)

[jtimon]

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?

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.

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.

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

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.

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.

[killerstorm]

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

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

Ripple has no mining or direct monetary reward for running a Ripple server

Well... It might be zero cost if people run servers for free, but I don't see how it can be sustainable. Of course, OpenCoin is interested to keep their servers running to create demand for XRP and sell those XRP for profit.

But how is this decentralized?

Seriously, it sounds like a scam...

In Bitcoin, fees are honest: processing a transaction and running a node requires resources, and people who want to send their money pay...

But if you get some service for "free", there must be a gotcha...

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.

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.

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

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

[HostFat]

Well... It might be zero cost if people run servers for free, but I don't see how it can be sustainable. Of course, OpenCoin is interested to keep their servers running to create demand for XRP and sell those XRP for profit.

But how is this decentralized?

Seriously, it sounds like a scam...

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.

[killerstorm]

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.

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.

[HostFat]

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

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

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

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.

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

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.

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.

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.

[jtimon]

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

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

Ripple has no mining or direct monetary reward for running a Ripple server

Well... It might be zero cost if people run servers for free, but I don't see how it can be sustainable. Of course, OpenCoin is interested to keep their servers running to create demand for XRP and sell those XRP for profit.

But how is this decentralized?

Seriously, it sounds like a scam...

In Bitcoin, fees are honest: processing a transaction and running a node requires resources, and people who want to send their money pay...

But if you get some service for "free", there must be a gotcha...

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

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.

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.

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 fees are not enough, the problem is bigger than what can be "solved" with this patch.

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

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.

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?

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.

[ThickAsThieves]

When colored coins come up I always hear the example of shares / stock. But when it comes to securities, determining ownership and decentralizing the exchange is simply not an interesting problem, compared to the bigger problem of ensuring that the issuing company is trustworthy (which is more of a social problem rather than a technological one).

I believe there is a demand for a secure trading platform which doesn't try to be an investment bank.

You probably know that Goat was delisted from GLBSE. Maybe he shouldn't have been there in the first place, but now this delisting creates problem for Goat and for people who bought something from him.

Or imagine a situation where GLBSE will suffer from catastrophic data failure, it it will be hacked. Do people have a backup plan?

Suppose they even have a list of owners (this features is offered by MPex), can they continue trading after being delisted or after some problem with exchange?

With a trading platform based on colored coins ownership data is encoded in a blockchain, it cannot be lost, it cannot be hacked in realistic scenarios. You cannot be delisted. You will be able to trade no matter what.

Maybe this problem is not interesting to you because you haven't considered catastrophic failure scenarios yet.

But things like that happened to currency exchanges and wallet services, why do you think stock exchange would be immune?

Anyway, I'm a programmer, not a lawyer. I cannot help you with non-trustworthy exchanges, but I can help to develop a secure trading platform.

By the way, it might help with trustworthiness checks indirectly: since smartcoin based trading platform won't do any checks at all, this would create a market for trustworthiness checks.

GLBSE wants to be everything at once, they offer some verification, sort of, but it is really half-assed, and its bundled with their trading platform. So people have no choice but to use it, and they don't think that 3rd party rating agency is needed.

But when trading platform is open to anybody, amount of bullshit assets will be so high that companies will have no option but to go to 3rd party rating agency. As many such agencies can co-exist, there will be a market, and so they'll compete to provide best services. I.e. you'll be able to check rating agency's track record.

The best way to solve social problem is to provide economic incentive, I think.

Digging up this comment, as it is a very sane and important one. The issues described are attributed to an immature market. No stock exchange has fully attempted "legitimization", and to my knowledge, I'm part of the only effort to separate the investment bank role from the exchange role. For a while now, I have explained that exchange operators should not be running their own securities, and that an investment bank's role helps to align interests between the Exchange, Investor, and listed Business.

In context, I don't see how decentralized concepts fix any of these problems. People will always need familiar/popular sources to provide (likely) trustworthy/valuable securities. IBs and the businesses they underwrite will always need reliable core audiences to sell to. If you break all these things into pieces, it places everything into the "wild", and arguably leaves us with a less useful system, with more, smaller, points of trust required.

Ultimately what is the core problem being solved, and is that problem actually solved, or simply moved to another point. For example, the stock exchanges close due to fear of SEC enforcement. Decentralized solutions then remove need for an exchange, but does now the SEC simply focus on bitcoin IBs, or the privately listing businesses instead?