I see no fairness issue either way, as long as you are open about it. It's more an issue of whether the value proposition you are making to both early adopters and the general public is sufficiently attractive to win them over. Fairness doesn't enter into it.

Personally, I would try to avoid a split from Bitcoin, and of course I still need to be persuaded the whole thing would work. Additionally, I don't think you could manage to compete against a fork that didn't split from Bitcoin.

So, if ordering is all the miners are doing, then validation isn't even necessary, because individual clients could do it. Double spends could silently bounce, as I understand they do in the Ripple ledger. I hadn't thought about flooding / spamming, which is an important point.

How much crypto-USD and other crypto-fiat could the system support relative to the market cap of the underlying cybercurrency? I'm assuming always strictly less. What would happen if we approached that limit? What would happen if the value of the underlying currency dropped to nearly zero, say because it was supplanted by a different cybercurrency without a proof-of-burn transition path?

OK, let's try it another way, maybe that will help clear up the confusion.

Do we agree you could create a crypto-USD that acts much like Ripple IOUs if we had a central party (it could still be a commercial venture, it doesn't have to be a central bank) issuing crypto-USD and redeeming it at face value (minus some small fee). To the degree the central party was considered credit-worthy and reliable, the crypto-USD would then indeed track the real USD.

The disadvantage of this is that you are now reliant on a central party and it is this you want to remedy?

Can you explain the nature and details of the differences between your proposal and what I just described?

I'm not sure I understand the shorting terminology. The person creating the Q "out of thin air" is figuratively borrowing the Q from a non-existent central bank and has to post a collateral that helps ensure he can eventually buy them back for the still non-existent central bank to destroy?


I thought it was the collateral that was backing the value of Q, with the interest rate differential somehow causing the exchange rate to remain near parity with the USD. I still don't understand the latter part, and like nomailing I think I'm seeing some circular reasoning.


Does this mean that in your scheme there is no way to destroy the Q again?

I have to ponder the rest of your post.

In general, I can see you could have a currency tracking the USD inside a BTC-based system, provided the crypto-USD is always automatically redeemable for BTC from the collateral and the total amount of crypto-USD outstanding equals the USD value of the BTC collateral. I generally understand how differing interest rates could induce people to convert between BTC and crypto-USD, but not how your present proposal does this. And because of the fact that the system doesn't know about exchange rates, I'm skeptical it could even work in principle.

What are the mechanics of redeeming Q? I won't call it crypto-USD, because I'm not yet persuaded it will track the USD. Is the initial amount of bitshare put up really a collateral, so that you get back your original amount, or do you get a prorated amount of the total amount backing Q? Under what circumstances is the original owner permitted to redeem Q he bought back on the internal market?

Hmm, come to think of it, not even the fees need to be in the block, as long as the miner has seen the actual transactions.

Sure, but what if I buy a EUR IOU from them? If it's backed by USD, there is currency risk when I redeem it.

Interesting. We could do this for all transactions, and keep only transaction hashes in the block chain. The availibility of individual transactions doesn't have to be less than in block form, does it? Only the fees would need to stay in the block chain itself.

Does that mean it is insured by the FDIC?

They do convert all fiat money that is deposited into their accounts into dollars, but I don't know where those dollars are held. I don't understand why they do this though, because they do issue EUR and JPY IOUs and that seems to entail unnecessary exchange rate risk.

That would depress the value of BTC, which could lead to a lot of resistance, perhaps in the form of a fork that did use proof of burn.

Yeah, I was thinking about not making any promises about transactions conducted off the block chain. But on reflection even that probably doesn't work, because while you have succeeded in getting the hash into the block chain, dishonest miners can still keep the revealing transaction off. Maybe there is a way to signal that a transaction has been censored, and then blocking validation until a block that includes the revealing transaction is found, but I haven't been able to think of one.

But then I wonder how your solution actually prevents miners from censoring revealing transactions. In part it is because people will accept peer to peer off-chain revealing transactions provided they have seen the commitment in the block chain. But what if dishonest miners still reject these revealing transactions when they're published eventually, rewriting recent history for those blocks produced by honest miners that contain them? Wallets would become longer and longer. Wouldn't this eventually become impractical?

The change to the hashing algorithm is orthogonal to the banking and exchange functionality, isn't it?

I'm having a hard time seeing why the crypto-USD would track the USD while crypto-EUR would track the euro. From the perspective of the block chain, what difference is there? We could just as well call them P and Q, and what remaining link with fiat would there then be?

Is the intended behaviour of a blind commit followed by a conflicting unblinded transaction that the latter should be rejected as a double spend? I can see why you would want this if you want to chain blinded transactions off the block chain as you described previously, but wouldn't it be useful already if the reveal of the first transaction were rejected instead? That by itself would thwart censorship by miners, wouldn't it?

I'm not against including addresses, I'm just trying to figure out if they are necessary, and if so, why. Suppose I hold a bunch of BTC and when I check with blockchain.info I see that they are tainted. Let's say that 30% of it indirectly came from the Mt Gox heist and I'm worried that the forces of evil will try to censor future transactions I might want to make with those coins. Let's say I gather all UTXOs in my wallet, both tainted and untainted, and divide them into a set of convenient denominations in a single transaction. Before I send the transaction, I commit to the hash of this transaction. Are you saying the bad guys could guess that my transaction, once unblinded, will reveal itself as involving tainted coins?

There is some support for HashCash in existing spam filters already. I think BTC postage would be a great addition to traditional spam filters because it could allow a sort of permission-based mass mailing. For instance, a user could specify that anyone who spends a specific amount of BTC to an address held by that user would be allowed to send an email with a prescribed hash specified in the postage transaction.

But the hash also includes the destination addresses (or scripts), which could be previously unknown, and at any rate are basically arbitrary. I don't see how guessing this is feasible.

For me that is the killer application for Ripple.