The problem is that the vast majority of offerings on your exchange (same for BTC.CO and LTC-GLobal) actually change value more in line with fiat than with crypto currencies.  All mining shares for starters.  All currency exchanging systems where funds are tied up in USD post-sale.  ANy company whose stock and prices are set in USD.  PM funds.

BTC-denominated securities are largely a pretence - they're USD-valued securities being sold priced in BTC with artifical attempts to try to maintain a stable price in BTC.  There ARE exceptions - but those are a small minority.

Having to place orders in BTC for something which has a value that will change mainly in synch with USD forces the spread to be wider - and liquidity to be lower.

Guess the solution will be to use a bot and the API to maintain orders.

I'll clarify - as I'm pretty certain Sukrim is referring to a feature I'd find massively useful.

A lot of securities are effectively denominated in different currencies to BTC - generally USD.  But at present all orders have to placed in BTC - leading to securities with face values fixed in BTC when that doesn't reflect the reality of the security value.

What would be useful is to be able to place a bid/ask at $X - and it would be displayed in the order book (in BTC) at whatever the current BTC value of $X was (and automatically maintained at that value).

Consider if I issued a security that had a face value of $1.

At present I'd have to manually calculate what $1 was worth in BTC - and could never leave orders up unattended as if the exchange-rate moved unfavourably I'd end up not receiving or spending the BTC equivalent of $1.

What would be good, instead, is to be able to place them for sale at $1 - then the exchange maintain the BTC price based on latest exchange-rates.  It's not actually quite as useful as it may sound - as unless funds are promptly converted there's still exchange-rate risk.  But it would allow the placement of unattended orders knowing that any loss due to exchange-rate would be because of moves AFTER your orders had been filled, not to people filling your orders after an unfavourable exchange-rate move.  It would allow more liquidity on securities with heavy fiat exposure in particular.

EDIT: I see sukrim responded whilst I was typing my post - it's same point anyway.

I'll sign up for the beta test - nice to see some originality for once.

I do, however, see a few issues with the proposal.  Some (hopefully all) are probably addressed.

1.  Transactions.  If the network grows to any decent size then there will frequently be multiple transactions created at the same time.  This poses a massive problem as:
a) If transactions don't have to be ordered in the ledger then it allows the back-insertion of double-spends (i.e. spend something legitimately then, using 2 of your own hatching nodes, spend it again later but with an earlier time-stamp).
b) If transactions have to be ordered - i.e. once one is accepted any others must be after it - then that is surely going to lead to lots of orphaned transactions and ones which have to be reprocessed to get back in sequence.  That would then allow anyone to grind the network to a halt by broadcasting a fairly modest quantity of transactions.

2.  Voting to create new EMUs.  This talks about voting on a random node.  How is this randomness enforced?  Clearly it can't be implemented by use of a RND function in the client - or people could change the code, create lots of semi-clients (i.e. lightweight ones with nothing much other than voting mechanism) and vote yes to a seed node they run themselves.

Yeah it's who I thought it was.  You'll find a thread in scammers section about him.  Basically he ran a bond promising fixed interest then when GLBSE vanished defaulted on it.  Not necessarily a scam itself (though still a default) except that the assets he claimed to have on GLBSE weren't enough to cover the bond anyway - and there was no sign of the mining assets he'd claimed to have covering part of the bond.

When someone turned out not to have mining assets they said they had and defaults on a bond it's not surprising that their mining bonds then get valued much cheaper than anyone else's.  I'd guess he never intended to scam - just tried to make money the easy way by selling supposedly safe bonds and then putting most of it into ponzis like pirate/obsi.  But end result is the same - that he can't be trusted to be doing what he claims to be doing with money he gets from investors.

1.  Who issued ASIC.COOP?  When I look at its profile there's no information on who issued it.  It could be some known scammer for all I know.  There's no link to any forum thread for discussion.  Maybe there's a thread somewhere - maybe not.  If I want to burn money I'd rather set fire to bank notes than send it to someone who won't even provide a forum name for contact.
2.  They have BFLs on order - some discount for that should be expected to reflect the chance of another year of delays.
3.  Investors don't do math.  For most, valuing a company means looking at what price shares are being sold at and has absolutely nothing to do with making even a token effort to determine whether it'll ever make a profit or how it compares to similar offerings.

Some mix of the above.

EDIT:  On reflection I think I recall that it's run by a known scammer - some romanian guy called ciuciu oir similar who defaulted on a bond he issued after lieing about what the funds would be used for.  Apologies to the actual issuer if I'm wrong in my recollection.  If I'm right it was a GLBSE asset that was transferred.  As he failed to keep his promises on his bond noone can expect him to keep his word this time.

Well that's what happens when you fuck around with a non-transparent selling policy and price manipulation to try to sell more shares in the short-term.  You attract short-term sales at the price of long-term credibility/sales.  I've seen it plenty of times and it's never ended up working well for the issuer.

The problem many issuers face is that they try to sell more shares than there's actually demand for.  The policy of early-bird shares followed by a sharp price rise hits problems as soon as the sharp price-rsie occurs - as the initial investors then get to profit-take, undermining further sales.  And why wouldn't they do that - as there'll surely be more IPOs along shortly where they can make a 50%+ profit in a few weeks by flipping early-bird shares rather than holding on long-term with much greater risk for a massively lower APR.

Where AML varies from other ones burned by messing with this stupid sales policy (e.g. BitPride, ZigGap, BTCQuick on Bitfunder) is that it didn't even manage to sell all the early-bird shares.  The three listed sold all those - but then ran into undercutters cashing out profit when trying to sell the rest at much higher prices.  Guess every IPO has to learn the same lessons the hard way - specifically :

1.  Fucking with your own share price to raise it will only attract short-term speculative investment - a higher price will NOT attract new long-term investment that wouldn't invest at the lower price.
2.  If you sell some shares cheap then other identical shares at a higher price EXPECT a lot of of the ones who bought cheap to undercut you.

The exception to this is when a rise in price follows ACTUAL decent profits (see S.DICE - where higher priced tiers did sell out after months of steady real, not projected, profit).  That's profits that have been made - not fantasy projected ones based on being able to add hashpower (that has't even been built) to the network without changing the network's hashpower and without anyone else buying/building/deploying any ASICs at all.

From having seen plenty of other attempts at the same thing I'd expect the price to move around for a bit then slowly fall back towards the initial price as people who bought thinking they could cash out at the next price tier realise it isn't actually going to get there any time soon.  The drop can be delayed - but made sharper when it happens - by continued attempts to manipulate market prices.  The price CAN be kept high if sufficient capital is used to maintain bid-walls - but quite possibly at the cost of actual sold shares dropping and the retained capital/share falling as it gets thrown away buying back shares at a price higher than they were sold at.

Disclosure : I regularly buy/sell during IPOs - there's generally more profit (and much less risk) flipping during IPOs than holding the shares for any length of time.  I currently hold 0 AMC but HAVE bought and sold a small amount (profitably) for my fund.

Two things about that statement by him :

1.  It was just part of what he copied/pasted from namworld's contract - as with all copy/pastes there can be no certainty to what extent the person using someone else's contract actually understands/means what it says.
2.  Not tied to the success of any business means that what he pays you doesn't change based on how well his businesses do.  It doesn't mean that he doesn't have businesses that he expects to make the profit.

What's missing is an unambiguous statement that the funds will be used and kept predominantly BTC-denominated.  The two most risky forms of loans are:

1.  Ones that are taken to invest in someone else's higher-rate paying investment (see pirate).  These ones default if/when the underlying investment turns out to be a scam.  That is NOT the case here.
2.  Ones that are taken to be converted into a different currency for use.  The usual culprit here is loans taken denominated in BTC that are then converted for use into USD.  These default when BTC rises sharply vs USD - as even if the USD-denominated business is very profitable it still can't support the debt at the higher rate.  Examples of this include Bakewell, loads of loans on BTCjam, various other mining outfits (e.g. BTC-Mining in my view) and failed businesses that believe or claim to be BTC-denomnated whilst actually having high USD exposure (e.g. Ziggap).

There's no assurance that 2. isn't the case here.  The funds are for use in some of his businesses - but are they going to remain BTC-denominated?  If not (or if the businesses aren't already profitable) then some assurance should really be provided that he has BTC-denominated assets sufficient to repay the principal in the event the businesses do badly and/or BTC rises sharply vs USD (or whatever currency the loans will be converted to).

I'm only aware of three other ongoing offers comparable to this one:

Namworld's one - which pays a lower rate, isn't currently looking to raise more funds and provides a spreadsheet showing current BTC-denominated assets well in excess of the bond capital.
TradeFortress' loans service - a higher rate than this and used for BTC-denominated loans.
My own bond (which you won't know about as although it's denominated in BTC it's traded in LTC so in the alt section) - which pays a higher rate, is NOT currently selling more and is backed by BTC-denominated assets exceeding loan capital AND by LTC-denominated assets exceeding loan capital.

The key point is that all three hold (or at least claim to hold - outside viewers can't be certain) BTC-denominated assets matching or exceeding the owed capital.  I don't know how much TF's one has in debt - but I know Namworld and mine are both significantly smaller (mine's paused at 250 BTC for now).

If the capital is being used for speculative purposes (e.g. to develop businesses that currently show little/no profit) then that is NOT a problem - so long as he has BTC-denominated assets able to be realised to cover the debt if necessary,  Some assurance on that point would be good.

Well if it takes off I'd do it via a bot anyway.  Bot would just look for transfers in on my account then do the correct transfers out (been meaning to write this for a while as part of my long-delayed trading bot update from the old GLBSE one I wrote).

Problem with doing initial sales off-site are two-fold:

1.  Extra risk for investors (that my code is buggy, that my wallet gets hacked etc)
2.  Reduced transparency (can't immediately verify total balance in one place) and ability to be audited.

That's pretty much what security 3 is - and how I'd be doing it anyway in the 2 security model.  In the 2 security model I'd sell some security 2s then sell however many security 1s they backed (which would change over time as difficulty rose).  I'd buy a bunch of 2s myself at start so as to be able to immediately sell some security 1s.

Security 3 represents placing cash on deposit allowing you to sell your own no-hardware PMB - you'd get some each of security 1 and 2 (numbers don't matter - but have to be a fixed ratio based on current difficulty and the denomination of sec 1) then would presumably want to hold your secuiryt 2s and sell your security 1s (though if prices moved too far in one direction the opposite COULD actually make sense).  Your secuirty 1s represent the PMBs you are entitled to sell and your security 2s your right to the remaining capital after the security 1s have been bought back (and to dividends in the meantime if the obligation to security 1 falls so as to make capital available which can't be used by selling more Sec 1s at a good price).

From a purist perspective I like the 3-security model as the market completely gets to set the prices of both meaningful securities (sec 3 is just a mechanism needed because exchanges don't allow me to sell a bundle of 2 different securities).

I'd be looking to sell sec 1s at just under whatever price hardware-backed PMBs were selling at (unless I believed it to be unprofitablt to sell at that price) were the 2-sec model used.

Issuing once is inefficient in terms of listing fees and management time. 

It's also not good for investors (in 2 especially) - the rate of sale of 1 and 2 needs to be managed so as to ensure that at all times there's sufficient cash to back security 1 but not a ton of cash sitting idle (as that would mean I'd sold too many security 2 and so was diluting profit for no benefit).  So there wouldn't be a huge wall of both placed up at once anyway (security 1 couldn't - because of lack of backing capital until 2 sold and 2 wouldn't as it would be bad for investors if security 1 sold slowly).

It seems there's still demand for fixed-rate mining bonds.  There's also plenty of people who believe those are generally sold at prices where they make no sense for investors (I fall in this latter group).

Is there interest in a set of investments that allow investing/betting on BOTH sides of this argument?  This would allow those on both sides of the discussion to put their money where their mouth is - and would also allow the market to define what it considered a fair price for fixed-rate mining bonds.

I'd do this by issuing either TWO or THREE securities - all from the same issuing account and with a shared wallet.  I'm not going into the detailed math or specific numbers here - just the principles.

Security 1 : Acts pretty much like a fixed-rate mining bond.  Weekly pays out based on current difficulty.  Has a buy-back clause giving right to repurchase at 100 times current weekly payment.
Security 2 : Is betting against security 1.  Retains the wallet contents after repurchase of security 1.  May also receive dividends prior to that IF the wallet contents exceed 100 weeks' payment by a large margin.  Has a monthly vote on whether to exercise the buy-back clause (so investors get to choose).

In the two security model I'd sell both securities.  So investors in security 2 would be trusting my judgment on what a profitable (for them) price-point was for security 1 - but would get to choose when to close out security 1 and either take a loss or collect profit.

In the three security model there'd be a third security.  More sophisticated investors would buy that on the market then transfer the share(s) back to me and receive in return shares of BOTH securities 1 and 2 (in a fixed ratio).  They could then sell whichever they chose on the market.  Those who wanted to bet/invest only on one side would be buying from these investors - so the prices of both sides would entirely be set by the market (I'd buy some myself at start to give some initial liquidity).

Note that I CAN'T list all three securities AND directly provide shares for sale in 1/2 - as that would destroy the value for investors in security 3 (which comes from them being able to bet on their own judgment being better than the market's).

In the two-security model my fee would be a percentage of PROFIT made by investors in security 2 - i.e. unless they received back more than they invested I'd get nothing.  So I'd be gambling myself that I could sell security 1 at a price unfavourable to investors in it - which is what most mining bonds/shares do anyway.  As the terms of security 1 would be absolutely fixed there'd be nothing I could change for investors to create a conflict of interest.

In the three-security model I'd take a small fee on ALL dividends (as I'd also be subject to the pricing judgment of investors in 3 and would also have a bunch more work to do transferring shares).

There's a whole bunch of checks and balances that would need to be in place (in terms of when shares could be issued and dividends paid to investors in 2 etc) but that's minor detail that I already know the answers to.  Is there any interest in the concept to make it worthwhile for me to flesh out the contracts and front up the listing fees?

Advantages for investors in 1 over 'traditional' fixed-rate mining bonds:

No CP risk to third parties such as manufacturers.
Immediate dividend payment - no waiting for hardware to arrive.
Investing doesn't itself increase network hash-power - investing here rather than in a normal FMB means lower difficulty and more profit.
No possibility of default because of events such as fire, theft of hardware, massive hardware failures etc.
Cash backing the bonds always present and verifiable.
If redemption happens it would be immediate and in cash - no waiting for buyers of hardware.
Likely to be cheaper than bonds backed by actual hardware.

Disadvantages for investors in 1 over 'traditional' fixed-rate mining bonds:

CP exposure to the exchange on which the funds sit idle.
Not actually contributing to securing the Bitcoin network.
Maximum receivable limited to wallet contents - meaning if bitcoin disastrously fails for some reason you'd get a lot less (albeit near worthless) BTC back.

Of the 100% of shares.

20% are held by AMC for growth/reinvestment (a horrible way to do things but sadly common - shares should represent ownership not be a crude way to determine the percentage of profits dividended),
40% are potentially for sale to the public - with unsold ones the same as the first 20%
The other 40% would be the founder's own shares.

There's thus three ways to look at it:

If you look at divdends then the founder receives 40% of all dividends regardless of how many shares are sold.
If you look at distributed profits (i.e. the dividends that end up NOT going back to AMC) then before any shares were sold he received 100% (obviously) and when all 40% public ones are sold he receives 50%.
If you look at actual ownership then he owns 100% initially falling to 60% if all public shares are sold.

Right now if any profits were made he'd be entitled to the vast majority of that portion of them that was destined to end anywhere other than in AMC itself - as his personal 40% outweigh the portion actually sold.

How well the shares do depend mainly on how profits are calculated - which is where you have to hope he's generous as that largely depends on how VMC decides to define its cost price that it charges to AMC.  And of course VMC isn't responsible to investors so doesn't have to make any disclosure in respect of that.

Bottomline is that he DOES own more than 60% - dropping to exactly 60% if/when all 40% of public shares are sold.  Reason for that is the ownership the shares owned by AMC.  Those are owned by whoever owns AMC.  Shareholders do NOT own AMC (that's explicit in the contract) so do not any part of those shares.  In practical terms, assuming good faith, the actual effective owned percentage of profits is 50% if all public shares are sold.

Quick update as the NAV/U has changed quite a bit.

Exchange-rate : .0024
Adjusted NAV/U : 51.698
Bid at : 50.5

We've had a very profitable few days, with growth of nearly 6.5% (pre projected management fee) nearly all from trading.  The bulk of profit this week so far has come from two places:

1.  LTC-GLOBAL shares.  A week ago the ask-wall at 100 LTC got attacked.  I bought the last 12 from the wall.  We've been the seller in most LTC-GLobal this week - with 2/3 the shares we bought selling at 173-175 (for 70%+ profit) and the rest in the 115-150 range.  The high price might stick - or it may drop back down to the lower range.  We have our profit safely locked up whichever way it gos.
2.  I just filled a bid on our S.DICE pass-through for 11k+ shares (it was actually 2 orders on same price).  There wasn't enough on sale on MPEx at prices that would fill the order - but luckily we held a bunch at start of week and had picked up 4k more cheap yesterday.  Those plus another 4.6k I was able to buy on MPEx allowed filling the order with a 20%+ profit for us (compared to the price we bought at - mainly from cheap ones we already held).  The buyer didn't get a bad deal either - the lowest ask on MPEx is now about 10-15% over the price he paid (and if he'd bought from MPEx asks even before I cleared the low asks he'd have ended up paying more).

Distribution through a mining (or similar) system would be FAR worse than what they're currently doing.  It's about the most inefficient and restrictive way to encourage use.

Ignoring issues with the implementation of things like debt-exchange, the single biggest problem I see ripple facing is the distribution of XRP.  It has to try to solve two diametrically opposed objectives:

1.  Make XRP freely available to legitimate users.
2.  Prevent spammers, hoarders and speculators gaining large quantities of free XRP.

Achieving ONE of those objectives is easy - achieving both VERY hard without making the process of obtaining them prohibitively time-consuming and intrusive.

Mining manages to fail to meet both criteria AND is costly plus slow.  It specifically totally fails on point 1 due to restricting access to only those with appropriate hardware, the willingness to use the mining software AND the readiness to wait until they've successfully mined before using the system.  That would  leave ripple as only usable for 'free' by a small group of people - whilst what (I assume) OpenCoin want is for people unfamiliar with BTC to be able to use it just by signing up with a gateway and getting their handout of XRP (in practice the order may well be reversed - with them getting the free XRP before looking for a gateway).

In short, mining XRP would add complexity, cost and restrictions for no benefit (other than to those who wanted to mine for profit - which there's a never-ending stream of pump and dump altcoins for).

What's wrong with the current XRP system (in my view) is two things:

1.  A lack of clarity on how XRP will be distributed.  This is reminiscent of freicoin and solidcoin with their putative distribution/use of premined coins by some committee with a total lack of detail provided.  This isn't needed just for curiosity - but because without confidence that widespread distribution WILL occur it's hard to see any serious effort/money being put into development of ripple-facing applications.
2.  As mentioned in an earlier post by me, an unnecessary focus on the sale of premined and retained XRP as the source of profit for OpenCoin rather than their reward coming from adoption of ripple itself.  Yes - there's obviously some correlation between the success of the two, but also scope for a conflict of interest.  Whilst OpenCoin will claim (and may well be doing so honestly) that they're not focussed on the sale of XRP at the expense of the 'main' project they've deliberately created that potential conflict of interest.  An alternative approach (simplified) would be to premine, give out ALL the XRP but then have ones that are currently destroyed in transactions instead returned to them as a fee.  Then to make a profit they'd HAVE to get ripple adopted and widely used.

Think you accidentally said the truth there - whilst trying to be sarcastic.

Apple's primary objective is to make profit for their shareholders - building iphones etc is what they do to do that.  Their shares reflect their success in that.

With OpenCoin the value of XRP reflects how well they're doing - as they've defined that as the means by which they'll extract profit from ripple.  Increasing the value of XRP is thus their primary objective (as the means by which they'll make profit).  I have no problem at all with a for-profit organisation trying to make money.  What's unfortunate is that tieing their profit to XRP rather than to the success of ripple itself (and the two are NOT necessarily the same) leads to the situation where the decision of whether to implement a change that makes the platform stronger but lowers the price of XRP becomes a difficult one for them.  

Life would be far simpler if they'd picked a profit-making strategy that rewarded them based on the success of otherwise of ripple (XRP can succeed or fail as a currency in its own right largely independently of how well ripple as a whole succeeds).  But then they wouldn't be able to make a decent profit if ripple itself never really takes off.  So now when deciding how to distribute XRP they can no longer focus on what the most efficient methods are - but have to factor in (to a very significant extent) the likely impact of any particular distribution method on their ability to get cash out of XRP.  That specifically means making distribution inefficient so that some people are forced to buy XRP.  Every legitimate user getting enough free XRP to use ripple would be ideal for ripple - but a total disaster for OpenCoin.  And that's the conflict of interest they've created for themselves.  The distribution of XRP is, in any event. the big unsolved problem with using it as spam-prevention - my money is very much on it mainly stopping legitimate users : attackers have other vectors and those wanting to use transactions for information aren't likely to be priced out of it.

Actually there's two seperate things being discussed in the IRC conversation which MP conflated.

namworld was talking about selling XRPs to someone else.  That has nothing to do with IOUs - XRPs are an alt-currency and there are people who are DELIBERATELY buying them despite them being given away free.  namworld sold his free XRPs to someone for a few BTC - that person wanted to buy XRPs, knew they were buying XRPs and there's no flaw in ripple involved or misunderstanding by either party (of what was being traded).

This topic and the flaws in ripple are entirely seperate and have nothing to do with XRP as a currency in its own right or people voluntarily exchanging BTC for them.

No.

The person wasn't given any XRP.  The only movement of XRP that occurred in the process was the destruction of a tiny amount. 

XRP is entirely seperate to the conversion of debt from one issuer to another (other than some being destroyed during transactions).  The only time XRP gets exchanged for a different currency is if two parties intentionally exchange it - which DOES require both parties to agree to a change in the currency they hold (though they can't necessarily control the issuer from whom the currency comes if they have more than one line of trust open in the currency).

XRP, in general, is seperate from the IOU system - it exists alongside it as an 'actual' currency like Bitcoin.  It's official purpose is to be used to prevent spam by anyone creating a transaction having to destroy some.

BTCs/yuan/USD/whatever in ripple, on the hand, can be created from nothing by anyone (as IOUs) - with ripple treating them as of equal value to ones of the same denomination created by anyone else.

This is a common area of confusion with ripple (IOUs/XRP) - in part because the official function of ripple is rippling IOUs but the only part that works properly/is easily usable is XRPs.  So all the talk/trading is of XRPs despite them being officially just a minor feature to control spamming (in reality the main aim of OpenCoin is to extract value from the 1 billion XRPs they printed - the IOU trading etc is just a necessary evil for them in making the XRPs have some semblance of use/value).

How is the floor .0005?  That's more like the ceiling - any time any significant volume of orders are above that the issuer is going to sell into it (not least because if he doesn't then those with shares will sell and put up bids at .005 themselves to get their shares back cheaper next time issuer dumps a load).

That's why opaque selling policies are horrible.  There's nothing wrong with changing the price (and it SHOULD be changing - downwards as it happens - due to effectively being a USD-denominated security) but any price changes and/or new sales should be announced in advance.  Not least to prevent any suspicion of insider trading (Issuer or someone he knows can fill bids over .0005 and buy back with certainty if they know, and noone else does, that another batch will be dumped on the market).

In fairness to ripple, MP appears to not totally understand ripple.  He seems to be confusing XRP with IOUs/debt on occasion (in the IRC conversation) and also making the mistake many have made of believing if you trust someone and they then trust someone else that causes a problem.  It doesn't - at least not one related to ripple specifically, just the general risk that they lose money to someone else and can't pay their debt to you.  The big problem comes where you trust two different parties and that trust is then treated by ripple as being identical in value and fungible if it has the same denomination.

Specifically this is incorrect:

"Well… that’s not how Ripple works. As long as you trust both Lou Jiwei and some random Chinese dude any people who trust you can trade LJ’s yuans straight for the random dude’s."

The emboldened part should read "any people who trust LJ and hold random dude's yuan can exchange random dude's yuan for any of LJ's yuan that YOU hold".

They don't need to trust you at all - or even know you exist.  And if they do trust you it wouldn't make any difference - as it isn't YOUR (as in ones issued by you) yuan being traded.  They need to hold random dude's yuan (they can have zeroed trust to him) to send you and trust LJ sufficiently to accept whichever of his yuan you hold.  Then they can exchange the junk for good stuff with you - limited by the extent to which you trust random guy.

A lot of people arguing about this don't really understand this - so describe a problem which doesn't actually exist, giving ripple an easy way out (by letting them focus on addressing factually incorrect assertions about how ripple works whilst ignoring the real problem).

The general issues pointed out by MP at the start ARE real problems of course - particularly the whole system being based on a requirement that users willingly accept CP risk (I might not get my money back) and opportunity cost (my money isn't earning anything) without remuneration.  If the software is amended to fix the specific issue discussed in this thread (which effectively blind-sides people into providing general liquifity when they thought they were holding specific debt) then it's hard to see where liquidity will come from - as providing liquidity at significant risk but with no benefit isn't going to appeal to too many people (not ones who still have significant funds that is - the ones willing to do that should mostly have lost their money by now doing the same stupid thing before).

All of that said, if I can figure out some way to pay interest on Ripple I'd seriously considering offering bonds on it.  If there's people willing to provide liquidity for no cost then I'm guessing I wouldn't have to pay a very high rate - making it a cheaper way to fund-raise than I currently use.

Even IF you trust two parties the same amount you still should NOT allow their debts to be exchanged without your specific consent.  If you can't see why then you need to consider what the scenarios are where such exchanges would be requested - then realise that some of those scenarios have a cost/risk to you (specifically one where the party requesting the exchange has information you don't).  Which means you need to charge a premium for any exchange that you believe to be of equal value.  Apparently some sort of system to allow this does exist - but as it isn't open-source that can't be verified and it isn't available to the public anyway.  And I wouldn't be surprised if it was flawed (for example by insisting on using the same relative values for trades in both directions).