If one is technically inclined (as in developer type technical), this blog post is a great read. Ahh well a year+ of lessons learned the very hard way ... this should have made front page of ycombinator etc IMO.

Apart from this, which was a big mistake IMO:

Assign IDs rather than using UUIDs

This meant there was no way to hold onto a reference of a sent transaction until it hit the blockchain, which caused all kinds of problems.

Totally agree with this^^

No one cares about proof of whatever... as long as it's secure, which most cryptos have already proved to be.

Most crypto's haven't come under attack because their market caps are insufficient to present a sizeable enough reward. Do not mistake what has happened for what could happen. This is why we have white papers and proofs.

If the above is true, what about allowing people to extinguish the USD Smartcoin debt by paying in BTS.  The price feed always determines the USD Smartcoin/BTS price every hour.  In this scenario Bob can take $4,000,000 he has in his bank, purchase BTS and extinguish the debt and prevent any global settlement from occurring.

Doesn't this mess with the fungibility of long USD? I had thought the reason you had to settle in USD is because USD needs to be purchased from the spot market to get out of the contract, otherwise if the system borrowed it from BTS, you'd be back to square one?

@monsterer I understand that, but the problem is I dont have receiver's private key, so can I get it through API call or is there any other method which do not require private key for decrypting memo?

What is your use case? Why do you need to try and decrypt memos which don't belong to you?

It would obviously be good if the providers of secondary BTC tokens (not sure the correct name for these) like OPENBTC, METAEX.BTC and TRADE.BTC maintained more liquidity for their backed versions of BTC and other assets

METAEX.BTC has 9,999,991 BTC of buy side liquidity. The sell side just represents how many METAEX.BTC are in the wild.

scratch this - I was being a muppet

I think this is wrong question. I suggesting looking at how nuBits handles their liquidity provision and emulating them as closely as possible.

IMO the CER is a broken idea - having to specify a value for your asset when there is already a market for it is a bit mad. If there are no bids/asks, the system should just apply the base transaction fee in BTS.

Letting the fee pool run out is a better idea than raising the fee on cancels because you'll price liquidity out of the system like that.