Am I correct, that mechanisms like colored coins, would not work with this kind of chain?

Why do you think that GPU/CPU would be more energy efficient compared to ASIC's?
ASIC's are much more energy efficient. You just pay more for the custom designing/manufacturing of ASIC's, but in the end with ASIC's you have much less power consumption.

*EDIT*: So in principle you can say less power consumption would automatically mean more centralization. The only way to have both (decentralisation and power efficiency) at the same time is if you use a hybrid of proof-of-work and proof-of-stake

The problem with the increasing blockchain size is within the bitcoin protocol itself. As mentioned in the white paper there is the thread about 'ultimate blockchain compression' for bitcoin. But it is by far not as good as this new proposed coin. It only tries to fix some effects without really fixing the underlying problem. If you have a proposal, which could improve the existing bitcoin protocol which is comparable to the performance of this proposal here, then everyone would definately like to hear it.

This new coin proposed by bitfreak is really designed from a new perspective to reduce the bloat which we see in BTC. So I think it really deserves to be implemented and tested!

Btw, it adds some other important features, as aaaxn said:
I think the most important one is that secure 0-confirmations would be possible. I would definately add this to the first post.

I am just comparing the two possibilities which you presented:
#1 The BTC seller is the gateway
#2 A fourth party is the gateway

I see only negative points with #1 and only positive points with #2. Let me elaborate:

I think many users would like to trade without recording their online-banking session if there is no dispute. You already proposed earlier that the method could be used after a dispute only. I personally would like that much more. But then you would have to wait maybe 1-3 days until the wire-transfer cleared and only then you would have to eventually enter the dispute process and use the proxy. It's not quite clear that the BTC seller is online at that time.

I, personally, would try to minimize the use of the proxy, because proxying an online-banking connection increases the risks (i.e. man-in-the-middle attacks as described in CVE-2009-3555). Your risks increase even more if you cannot use SSL-renegotiation during this banking session (i.e. your full recorded SSL-session is exposed to one party and could be decrypted using your master key, which you have to expose at least to another party). I personally would like to minimize both these risks and I also don't like to change my online-banking password so often.

Maybe you could persuade me to always expose my online-banking-session and the corresponding session-master-key if you could elaborate more on your proposal to use
if you find 100% secure way to do this, then maybe I will trust this. Otherwise, I would prefer to trade without recording my SSL-session.

So in summary:
if we use option #1 the BTC seller is the gateway
--> BTC-seller and BTC-buyer have to be online at the same time
--> Only instant trades are possible (not possible to first wait for the clearing of the money-wire before a dispute)
--> Every trade has to use recording of SSL-sessions.
--> Much higher risks

in contrast, with option #2 where a fourth party is the gateway
--> asynchronous trades are possible
--> recording of SSL-session only in case of disputes
--> reduced risks

So why not allow p2p-trades with a lot of different contracts, depending on what risks someone is willing to take? I think the worst option is to only implement the solution with the highest risks, isn't it?


I don't see the extra level of complexity, because you have to implement some form of randomly choosing the escrow anyway. So you can also use the exact same algorithm to select an independent gateway.


I think your proposed solutions are really very good and I hope this will work. I am just comparing the options which you (and dansmith) already suggested earlier and at the moment I would conclude that it is much better to only record my banking session in the case of a dispute. And I see this only if the gateway is another user, because then nobody has to be online at the same time. Otherwise it would get really hard for some parties to proof that the gateway was online or was offline and if the connection was possible or was not possible because of some network failure or whatever. If the gateway is a party which is involved in the trade, it could get very hard to proof anything. If the gateway is choosen randomly at the time when it is needed, then you can proof something at all times independent from the other party.

I'm still not convinced by either side.
As you can see from my earlier posts I was first also very skeptical about it, because bytemaster used circular reasoning when he says that the price will be parity.

But still I also haven't seen a proof that it will not work. For example, it is not enough to say that the fiat price cannot enter the system because

This has been stated several times, but it is not true. You underestimate the psychology of all market participants. Actually fiat data could enter the system through all parties which are trading between real USD, bitshares and crypto-USD.

Here is an illustration of how it might work, just by psychology:
Let's compare it to bitcoins. The supply of bitcoins is exactly determined. Therefore the bitcoin-USD exchange rate is very volatile because the demand is always changing according to good or bad news about bitcoins.
In contrast, now lets look at the supply of crypto-USD. The supply is floating and constantly changing according to the decisions of all market-participants (going short or long).
Nobody so far has stated exactly if the exchange rate will definitely go up or go down. So nobody knows exactly if it will go up or down. Therefore we could assume the following:
A) 40% of all market-participants think the exhange rate between crypto-USD to fiat-USD will go up
B) 40% of all market-participants think the exhange rate between crypto-USD to fiat-USD will go down
C) 20% believe that the concept of bitshares will work and therefore they think that crypto-USD will track fiat-USD

So 40% will go long, 40% will go short and 20% will go short or long depending on if the price is below or above parity.
Therefore the 20% of all market participants are enough to drive the market to parity.

I could also help with development if needed (depending on which language you use).
Now I am really curious about the simulation and the resulting data. Hopefully it will help us to better understand the concept and maybe improve it if there are some weaknesses/flaws.

I have one question: Isn't there a problem to implement the closing of a short position in the blockchain? Let's look at our simulation so far and hypothetically continue it in a way that you want to redeem your short position:

1) Bytemaster minted 10 cUSD with 5.5 MortgagedBS for cUSD @ .55 BS
2) greBit minted 20 cUSD with 10.2 MortgagedBS for cUSD @ .51 BS
3) Bytemaster sold 10 cUSD to nomailing
4) Bytemaster buys 10 cUSD from greBit
5) Bytemaster redeems his short-position (minted 10 cUSD @ .55 BS) with the bought 10 cUSD from greBit (minted 10 cUSD @ .51 BS).

As I understand so far you would have to implement #5 somehow like this:
In the blockchain you would have to annotate the tx-out of your newly bought 10 cUSD as now having the native currency unit BS again. But the underlying value of the tx-out is 10x0.51 BS in comparison to the 10x0.55 BS, which you would like to receive. So you have to redistribute all tx-outs, which are annotated in cUSD, in the blockchain. Only if the blockchain somehow redistributes the tx-outs you can redeem your 5.5 MortgagedBS by reminting the bought cUSD to BS. Otherwise you would only get 5.1 BS back, because you bought cUSD which were minted at a different rate.

I am not familiar enough with all bitcoin internals to know if this is easy to implement... But, is my reasoning in the example above correct? Is this redistribution of MBS neccessary when you want to close your short position?

I would add SSL-renegotiation (as optional for the payer) to increase security. How could you really be 100% sure that the gateway and the escrow do not exchange more of your session-dump or your session-key? This doesn't look 100% secure, maybe just 99% secure without SSL-renegotiation.  So it's better for the payer to use SSL-renegotiation if his bank supports it. And many important websites seem to support renegotiation (e.g. paypal and large banks).

Probably the only reason why renegotiation is disabled on some websites is the security vulnerability (CVE-2009-3555). That many banks have it disabled is overkill, because there is a patch for OpenSSL to close this vulnerability. Maybe over time many websites will anyway update to the newer openSSL version and will enable SSL-renegotiation again.


The problem which you describe in #2 applies also to the selection of the escrow agent. How would you make sure that the escrow agent is really a third party and not in cahoots with either the seller or buyer? Probably by some mechanism to randomly choose the escrow. So if it works there, why not use the same mechanism for the gateway? So I would say your point #3 doesn't make sense, especially if you think about the problem that they both have to be online at the same time it is better to select a random user from the pool?

To make sure that all 4 parties (seller,buyer,escrow,gateway) are really different persons, it would even make more sense to link p2p-accounts to real-world-bank-accounts. This would reduce the risk that someone could flood the p2p pool, because nobody has arbitrary many bank accounts.

A problem with the approach to always have the proxy on the machine of the BTC-seller is that they might not be online at the same time. How could they agree to a specific online time? Should they specify this in their trade? In principle the BTC-buyer could just say that he couldn't do the transfer because the BTC-seller was always offline when he wanted to do it.

Isn't this the case also for all real-life currencies.
So I think you haven't presented a proof that the idea will not work.

Indeed reputation should be in the system too. something like the OTC rating system. this would help to minimize disputes.
Why not link the p2p accounts (and the corresponding reputations) to the supplied real-world bank accounts? It would further minimize the number of disputes because nobody wants to risk that he can never use his bank account anymore in the p2p exchange. Is it possible to link p2p-account-reputations to real-world-bank-accounts without disclosing the bank-account-number to everyone? Maybe one could create a hash of the account-number, which then serves as the user-id in the p2p exchange?

Could you elaborate why this wouldn't help? I think if a user always trades using his paypal account, then he could build a good reputation by always using this exact paypal account. Consider he has a good reputation after some time, then he wouldn't want to fraud with this account? If you go further, a user might be able to link his paypal and bank-account and p2p-account all together to even get a higher reputation. And when he once linked them, then it's not possible to delink them anymore because everyone knows that these accounts belong to the same real-world person...

why did a 'lost' money? In my opinion I get interest for my cUSD, which you issued to me @.55BS which is more than the current exchange rate. So I should have made a profit, or am I wrong?

in other words, I anticipated the rise of cUSD value...

Buy 20 @ 0.51 BS  (nomailing)
Mint 20 cUSD (backed by max 0.51 mBS)

Ok, because at the moment there are no sell order, I will try to make a profit by setting some high price:

Sell 10 cUSD @ 1 BS

I would suggest to format the mortgage as MBS instead of mBS so that there is no confusion with milliBS. *EDIT* or some other letter.

Still not quite sure how I should formulate it, if I want to mint some cUSD to myself. I will try it like this:

I want to purchase 20 cUSD for 5 BS.
I want to mint 20 cUSD (backed by 5 BS) in response to the highest bid.
*EDIT* is it possible to add a limit to my second order?


So I will back 1 cUSD with 0.25 mBS, right?
(btw, please correct my balance: subtract the 10 sUSD that I paid to you for the 10 cUSD)

ahh Ok, thanks.
I will accept that. So I pay you 10sUSD for 10 cryptoUSD (minted at 0.55 BS).

nice. I also want to participate. I hope your concept will work out although everyone is quite skeptical about it

I want to purchase 100 BitShares for 60 simulated USD, send BitShares to address nomailing1.
I want to purchase 10 Crypto-USD for 10 simulated USD if on average 1 Crypto-USD is backed by at least 0.9 BitShare. send CryptoUSD to address nomailing1.

I assume I can add this condition in my second order to be sure that the crypto-USD is backed by enough bitshares, right?

@bytemaster you still haven't replied to my answer above. So I assume we are still on a different level. Maybe I still miss some important point, or you are still reliying on circular reasoning?!
I will try to clarify what I mean, so that we can maybe come to the same conclusions...

You say:

But your assumption that "they can make a profit by selling 100 crypto-USD for 101 paper-USD" is solely based on the assumption that the exchange rate between crypto-USD and fiat-USD actually IS on average 1:1. So it is a circular argument.

So, I just want to point out here, that what you say in the white paper, is not a proof that the price will be parity (on average), because in your reasoning you use the assumption that the price is on parity on average. Do you see the point, and could you agree to this?

If that is the case, then maybe we could come to the following conclusion, which is what I understand from your reasoning: the exchange-rate between fiat-USD and crypto-USD will be 1 on average IF enough people think that the exchange-rate between fiat-USD and crypto-USD will be 1 on average. So although this IS circular reasoning, the idea might still work?! But it is no proof that it will work.

But your assumtion that they *FEAR* that crypto-USD will fall in value is based on the assumption that they assume that the price will reach parity in the future. You haven't proven that this is the case.

For example you could do the same reasoning for BTC by just renaming it to crypto-USD. Just by naming it USD you could argue that people want to sell it for paper-USD if the price is 101$. But nobody can guaranty that the price will be on parity. In reality the price could diverge to some arbitrary number (like with the BTC-USD exchange rate). So I still think that you use circular reasoning... But probably I just miss some important point... Would be nice if you could point me to the correct reasoning if I made an error. thanks a lot..