You're pathetic, people: I described it in detail several pages ago: https://bitcointalk.org/index.php?topic=265488.msg4365991#msg4365991

Getting profitable fast enough is definitely not related to hashing power, there are more important reasons to do it on Bitcoin blockchain:

1. it needs to be on Bitcoin blockchain to make it possible to send bitcoins to exodus address
2. "simple send" can be done using a normal bitcoin client, this way you can make an illusion of working cryptocurrency (you can send coins!) spending only a couple of hours on making some basic script


A robust cryptocurrency protocol is supposed to be resistant to all kinds of attacks.


I'm well aware of competitors, in fact I am the lead developer of one of them. I just wanted to know which of them you had in mind. Invictus?

It's not about hash-power, it's not that hard to make a merged-mined alt-chain which will have almost as much hash-power as Bitcoin itself.

J. R. Willett explicitly mentioned that it is important to build Mastercoin on top of Bitcoin and let them interact.



Well, if Bitcoin allows one to use other people's resource, either it is flawed, or your understanding of what it is is flawed.


Are you talking about something specific?

In any case, to make decentralized exchange useful, you need it to be integrated with a powerful cryptocurrency.

Let's consider an example: suppose Freimarkets got implemented overnight, and some startup offers its shares for sale through this system.

I want to invest $100k, so I buy $100k worth of freicoins... Ouch, it's not so simple: that many freicoins are simply not available on exchanges, and trying to buy them would move the price, a lot. So it isn't even funny.

Thus a barely functioning decentralized exchange which works with bitcoins is more useful than a perfect decentralized exchange which works only with some obscure alt-coin.

I'm afraid you're missing the point of colored coins and mastercoin: they are supposed to extend functionality of Bitcoin.

Obviously, smart property, user currencies and decentralized exchanges can be implemented in a variety of ways, but there is a significant demand for things like this specifically from Bitcoin community: people who already own bitcoins and want to trade using bitcoins.

Decentralized exchange/smart property applications on top of Ethereum might be awesome, but it's not same thing as colored coins and matercoin.

I don't think there are any special requirements for bitcoin.conf. txindex merely allows one to get transactions by their hash, it cannot be harmful in any way. (Well, aside from eating some space on your disk and making processing a bit slower.)


No, it reindexes blockchain you already have on disk... Which takes time, yes.

It is possible only if you can create a compact cryptographic proof that transfers on secondary chain were valid. That is, you need something like this: http://www.scipr-lab.org/

But even a compact proof size is well beyond what Bitcoin blockchain allows you to include into transactions, so, unless you want to split this data over multiple transactions, you need an additional blockchain for these proofs.

Bitcoin clients do not require entire Bitcoin blockchain because Bitcoin was designed with SPV (Simplified Payment Verification) in mind. Clients like Electrum and Multibit already work that way, and it is secure. Then only need to download block headers and Merkle tree branches which confirm transactions they have.

SPV is possible because Bitcoin miners verify transactions and do not allow inclusion of invalid transactions into blocks. If rogue miners includes and invalid transaction into a block, other miners will reject that block, so it is a very expensive thing to do.

Thus we can say that miners are paid in order to make it safe for everyone.

Mastercoin is designed in a different way... J.R. Willett mentioned that the only consideration was simplicity. It is possible to send mastercoins using an ordinary Bitcoin client which isn't mastercoin-aware. All you need is 10-line Python script which creates addresses.

But, well, Mastercoin is completely incompatible with SPV, it isn't possible to verify validity of payments without downloading the whole Bitcoin blockchain.

Comparing Bitcoin and Mastercoin is like comparing left and right paintings here: http://static.guim.co.uk/sys-images/Guardian/Pix/online/2012/8/22/1345647849262/Ecce-Homo-by-Elias-Garcia-006.jpg

One is a work of a genius which shows tremendous attention to detail, another is a quick botched work. (Backstory: 81 year old woman tried restoring painting in church, not recognizing that she is ruining it, probably due to bad eyesight.)



How is it relevant to Mastercoin? It isn't tied to unspent transactions in any way.


You absolutely need to track all transactions on RPC blockchain to check validity of transfers. Mastercoin transactions are not validated by miners, so their validity shouldn't be taken for granted.

If mastercoin can be brought back from a secondary chain to main chain, how is it possible to check the validity of such transaction without following the secondary chain? I'm fairly certain that it isn't possible.

If it is one way only, it can work, but price of mastercoins in a secondary chain might be fully detached from price of mastercoin on the main chain.

No.


Yes, if you can find people who can implement it (first and foremost brave C++ programmer(s)), I'll be able to discuss it.

Well, you need a developer who can do that kind of thing...

From technical perspective, the solution is kinda obvious: add color tags to transaction outputs, track "colorvalue" for each UTXO, make sure that miners check validity, introduce a way to make genesis transactions... That's the basic version.

Freimarkets is quite a bit more sophisticated, but I guess you're asking about the simplest thing which could work, right?

If you can find a good developer (ideally, one who is already familiar with Bitcoin source code), it would take him something like a week to implement a basic version.

There are many design considerations, say, compatibility with existing tools... Is that important? Hard to say.

ChromaWallet isn't ready for a prime time yet, but in a couple of weeks it might be...

I'll be glad to help with evaluation/migration when it is ready.

A special currency is not required for "smart property" decentralized exchange. We implemented it a year ago for colored coins, but masrtercoin-like implementation is also possible, and doesn't require Mastercoin.

However, other features require a special currency:

1. Escrow-backed currencies: you need to put something into "escrow", and it cannot be Bitcoin, because Bitcoin doesn't obey to "escrow" rules.
2. Automatic bet and CFD settlements: again, you need special rules, and thus special currency.
3. Saving addresses, spending limits.

However, a special currency is necessary only if you want to implement it exactly the way Mastercoin does. If you consider different kind of implementation, it is possible to do it with Bitcoin alone:

1. CFD/bets: Can be done via Bitcoin contracts ( https://en.bitcoin.it/wiki/Contracts )
2. Savings/rate limiting: can be done using multi-sig scripts and third-party operator which will control one of keys. See here: https://www.bitgo.com/

It is very hard to implement escrow-backed currencies in a decentralized way without a special currency... But if you consider complex approaches, it's probably possible to do this using secure multi-party computations, you can create a "decentralized autonomous corporation" to take care of escrow. But to do this, you'd have to hire highly qualified cryptographers to design the system, it's not so simple.

That said, escrow-backed currencies are a bad idea in the first place. (Don't take my word for it,  Ron and David wrote that CFD's are more likely to work properly.)

Anyway, real motivation for Mastercoin is this: "Personally, I am waiting for an investment opportunity which offers the kind of blue-sky moonshot that bitcoin is, where my investment gains value in proportion to the success of the protocol. " -- J. R. Willett.

See here: https://groups.google.com/d/msg/bitcoinX/9_YJ_3qi41c/PWEp1WI4E10J

Who cares if there is another way to do this if that other way won't make you rich?

Colored coins is a concept, it is not a concrete coin one can buy.

I have no sympathy for person who fell for it, scam announcement didn't even try to explain how it could make one rich.

Well, I just wanted to outline the general idea, not to describe a concrete recipe. Here's a protocol which fixes problems you mentioned:

1. txAB has inputs from both Alice and Bob, sends coins to 2-of-2 multisig, additionally pays premium to Alice
2. tx-call executes the call option, is signed only by Alice
3. tx-timeout returns coins to original owners after a timeout, is signed by both parties
4. tx-cancel returns coins to original owners, is signed only by Alice

Parties sign tx-call, tx-timeout and tx-cancel first, and after that both of them sign txAB. At that point Alice receives the premium.

If Bob cancels option early, Alice also receives her coins early, but she cannot do it on her own.

It is possible to provide partial execution/partial cancellation by signing many different versions of transactions, essentially a tree. For example, suppose Alice agreed to sell 100 AAA for 100 BTC. Bob might want to get 10 BTC out of this, so he publishes tx-cancel-10, and then other branch of transactions is in effect: tx-call-90, tx-timeout-90, tx-cancel-90.

This tree can be pretty big, but it is hardly a problem, as only part of it is included into blockchain, the rest is just shared between Bob and Alice. People routinely send each other 10 MB photos, and a lot of different options can fit into 10 MB of data.


I think I've addressed all issues, although #3 can be a bit of a problem.


Well, this kind of call contract I described requires concrete coins, so Bob has to provide some concrete coins, and avoid spending them until contract becomes irrelevant. He can always spend his coins, but in that case contract is canceled.

If contract is a partial transaction (SIGHASH_ANYONECANPAY), then there is no need to reference concrete coins of Bob, which is definitely better.

So my conclusion is:

1. we can do something useful with colored coins
2. Freimarkets-lite (i.e. Freimarkets without sub-transactions and other advanced features) can be significantly more useful
3. full implementation of Freimarkets is definitely even better, and it removes some complexity from the client-side implementation, but it makes cryptocurrency protocol more complex

First of all, let's note that the problem is actually not with fake exchange proposals, but with fake offers: we could simplify the protocol and require Alice to include her txins with the offer. In this case Carol would post a partially signed transaction, and will be left at mercy of Alice who can either make a fully-signed transaction, or ignore it.

Freimarkets kind of eliminate the problem with fake offers, as offers are sub-transactions and are already signed.

But Alice can still disrupt the exchange with double-spending: when she sees that somebody made a complete transaction out of her sub-transaction, she will double-spend her inputs, thus making exchange impossible. The effect is the same as with fake offers DoS attack described above: offers are seen, but cannot be executed. (I assume that Alice can perform this double-spending attack with high probability of success via network-level shenanigans.)

Thus if you want an exchange which has more stable behavior, you still might want some kind of reputation system or double-spend-prevention service even if you have sub-transactions.


I don't think that that it is a same thing... Smartphones are, essentially, online all the time, they can receive push notifications and such. Somehow it doesn't inconvenience people.

Although, more realistically, trader will keep his laptop open for 8+ hours a day (because he uses it), and execution of orders is possible during that time. 8 hours a day is good enough. In fact, that's how exchanges like NYSE work, they are not available 24h a day.

Having an ability to get your offers filled 24h a day might be better, but not always: some catastrophe might happen over night, when you're sleeping, and you'll buy some worthless securities.

So my point is, offline execution is a useful feature, but not critical.


I see, it might be really important for some use cases.


We haven't decided yet, I'll post more information about these two approaches on the bitcoinX mailing list in a couple of days.


Yes. I guess making Bitcoin a special kind of an asset is good for people who invested in Bitcoin, so this limitation might be seen as a feature.


Hmm, interesting... Well, you can partially address granularity problem by publishing many offers of different size which use same inputs, e.g. 100, 50, 25, 10, etc. This will reduce blockchain bloat, but isn't same thing as proper granularity, I guess.

By the way, did you consider the fact that extra complexity brought by advanced features like sub-transactions and such might lead to higher chances of having critical bugs in code? Many feature in Freimarkets proposal are far from trivial, so it is a serious concern, in my opinion.

Only Mastercoin funding is centralized, protocol itself isn't centralized.

I was unable to find code which handles blockchain reorganizations.

Also, it looks like you parse the whole blockchain at start... or am I missing something?

Or, depending on how you look at it, he is a hero who warns people of the Mastercoin's weakness and prevents much bigger losses.

Well, I wasn't addressing this specifically to you, sorry...


This reads to me that Garr first tried to write it off as pool's bad luck, then understood that he won't be able to produce any evidence, and later mentioned solo mining. It's just a bullshit excuse.

If we continue asking about it Garr will say that by "our pool" he meant some kind of an internal pool (for all hardware which Garr manages), which is basically equivalent to solo mining.

Most likely Garr doesn't have enough bitcoins to compensate for this loss... Have you noticed that he is delinquent on FIMB loan?

So basically he provides some vague and weird explanations, communicating as infrequently as possible, in hope to win time: when cointerra hardware arrives, he'll get some bitcoins from mining (his personal stake in cognitive, for example) and would be able pay off FIMB interest, and maybe will compensate the loss of dividends in September/November.

We were supposed to get dividends for 5 weeks of mining, we got dividends for 1 week of mining.

The likely scenario was that equipment was off for a month, then Garr found that out, started mining (on a mining pool), and paid dividends for 1 week only.

Other possibilities:

1. he was solo mining for one month and solved no blocks
2. he mined something (either via solo or via pooled mining) but doesn't want to share it with shareholders
3. money which he mined was stolen, but Garr doesn't want to mention that to avoid panic and accusations of bad security practices

It doesn't matter what exactly have happened, as end result is the same: shareholders lost approximately 1 month worth of dividends.