It is impossible to confirm that he was solo mining and had such a bad luck that solved zero blocks: in this case NO payouts were produced, so there is NO evidence.

Can you people just stop beating the dead horse?

Please stop asking about "payout address": if there were no payouts, it is 100% irrelevant.

It is obvious that Garr mentioned solo mining only because no evidence can be produced. That is, even if he was honest, he could not produce any evidence.

So again, any further investigation makes no sense. If you believe that "payout address" could reveal something, you're delusional and do not understand how Bitcoin mining works.

Let's focus on one fact we know for sure: due to Garr's negligence, mining equipment was not working for us for about a month. (More accurate time frame was mentioned here.) What do we do in this situation?

Thank you, Jorge. So, if we consider only simple trading (without options and such), difference is largely in ability to execute orders offline, right?

Well, I don't know whether this feature is important. It is certainly might be convenient to be able to execute orders offline, but I think decentralized exchange is usable (and useful) even if it functions only as long as all participants are online.

BTW some limited form of offline order execution is possible with colored coins. For example, using bitfield-tagging scheme proposed by Peter Todd: destination output(s) are specified in inputs. Thus it is possible to create a partial transaction which sends colored coin from input_0 to output_1, while output_0 has the requested payment. Input_0 is signed with "SIGHASH_SINGLE | SIGHASH_ANYONECANPAY" hashtype specified.

Buyer creates a complete transactions buy adding payment as input_1 (which he signs) and output_1 (which receives the colored coin).

Note that it is only possible to create sell offers ('asks') through this method.

As for options, it is trued that you can't do them with colored coins alone, but it is possible to do it using contracts ( https://en.bitcoin.it/wiki/Contracts ). Let's consider call option, for example:

1. We assume that Alice and Bob know each other's pubkeys and can communicate indefinitely long.
2. Alice creates a transaction which sends her colored coin to 2-of-2 multisig script, but doesn't sign this transaction. (Let's call it txA)
3. Bob creates a transaction which sends his bitcoins to 2-of-2 multisig script, doesn't sign it either. (Let's call it txB.)
4. Alice and Bob together create a call option contract transaction: it spends colored coin output from txA, sending it to Bob's address, it also spends txB's output, sending it to Alice. (Let's call it txC.)
5. Alice creates a transaction which spends output from txA to Alice's another address, and has nLockTime in future (e.g. a month from now). Let's call this transaction txA-out. Both Alice and Bob sign it.
7. Now Alice can sign txC.
8. Alice signs txA.

Three scenarios are possible:

1. Bob wants to exercise call option. To do this, he signs and published both txB and txC.
2. Bob wants to spend his money, he just double-spends txB's inputs.
3. When option expires, Alice can get her coins back by publishing txA-out.

I've left several niceties (premiums, early exit for Alice) as an exercise to the reader.

This is less than ideal because Bob's money is locked for as long as he wants an ability to exercise an option. It's possible to use the trick with SIGHASH_SINGLE I described above to avoid this problem, but it works only for CALL options.

I propose a motion to confiscate shares owned by stabs.

Two weeks(tm). No, really, I believe we'll release a usable version in January.

I'd like to see more information about this: practical difference between Freimarkets and a hypothetical system without partial transactions (or however you call it). In what situations do we see this difference? What kind of guarantees Freimarkets will allow which alternative system can't?

I hope you understand that I'm not just wasting your time, I genuinely want to learn more about this. FYI I've just donated 5000 FRC to this project.


You're in control of your coins only after transaction is included in the blockchain. Before that, you can be subject to double-spends.

I see no difference in case with decentralized exchange: there is no certainty before transaction is included into the blockchain.

So, philosophically, it isn't different from Bitcoin.

I think that you're trying to say that user-defined currencies do not create additional demand for Mastercoin, and thus do not increase its value.

It is true, to a certain extent. (They make Mastercoin more useful no more than they make Bitcoin more useful.)

However, you're missing that demand for mastercoins can come from other directions: mastercoin provides features which work only for mastercoin-based currencies, and mastercoin is probably the biggest mastercoin-based currency, so people will use it.

Particularly, escrow-based currencies and CFDs: when/if these features will be in use, you'll need some mastercoins to use as an escrow/collateral for CFD. If there is a large CFD market, (e.g. suppose it requires $1B of value in collateral), mastercoin "market cap" will also be large.


You seem to be missing the fact that mastercoin itself will be used as a currency. Would you rather use Mastercoin which has $200M market cap, or some shoddy "user defined coins"?

"User defined coins" is not the only feature.

Well, again, Garr mentioned that he was mining solo... Which means that he can't provide any evidence that it was mining at all.

Most likely he just stopped giving a fuck about miners for a month or two.

I agree with Tafelpoot that it no longer makes sense to ask for explanations and demand compensation instead.

Garrett already demonstrated that he will go to great length to avoid accusations, so it's just a waste of time.

In any case, (no matter what actually happened) it was a mismanagement and we can demand compensation.

It isn't a problem. There are other ways to enable decentralized exchange.

It looks like your plan is to provide it all in a monolithic package, while we aim solve it outside of the scope of the core protocol, which gives a lots of room for different approaches.

If you implemented only "color" validation without the rest of changes, Freimarkets could be a drop-in upgrade to colored coins: if we'll be able to provide decentralized exchange capabilities for colored coins (and I'm confident we'll provide them in near future), one could simply replace transaction encoding without changing the rest of the protocol, and thus benefit from fast validation.

But if you're going to implement the whole thing or nothing, it might be late at the party... There are many developments in this area, so it is possible that in a year or two Freimarkets won't offer significant advantages over other approaches.

Yes.


Why do you think there should be a correlation? Amount of mastercoins being transferred is encoded in a different way. Bitcoin amounts are irrelevant.


The specification defines how amounts are encoded. How else this issue can be addressed?


Amount of mastercoins in existence is fixed, it was possible to create new mastercoins by sending to exodus address only in August of 2013. No new mastercoins will be created. (Some amount of mastercoins will be released to foundation over time, but we can assume that they were already created.)

There are two possibilities:

1. you do not understand how it works
2. everybody else does not understand how it works

Which is more likely?

I'm not sure whether you mean that it is compatible with a particular existing protocol, or whether it is compatible with p2p coin mixing in general.

I believe that 1) we need to use color-aware p2p coin mixing for colored coins; 2) in that case it doesn't matter which coloring scheme you use.

First, I should note that I did research on p2p mixing before it was cool about a year before gmaxwell described CoinJoin, so I don't know what terminology is currently in use... But anyway, I describe quality of mixing in terms of entropy, i.e. a measure of uncertainty. E.g. if attacker is able to trace a particular txout to a set of 1024 txouts, each of which can be a source of money equiprobably, then mixing entropy is 10 bits. Bigger is better.

Suppose there are colored coins in a CoinJoin transaction, for simplicity we can assume that there is one txin/txout with each color. Obviously, attacker can trivially connect txout to txin. So we get two things out of it:

1. there are no mixing entropy gains for colored coins
2. mixing entropy gains are reduced for non-colored coins

So it is definitely better when mixing is color-aware... And if mixing is color-aware, then order-based coloring and its variants work fine. Basically, you just do this mixing thing for each color in separation (it's OK to reorder txins/txouts withing one color), and then you just concatenate smaller transactions together (txins_1 + txins_2 + txins_3, txouts_1 + txouts_2 + txouts_3).

So now

1. it is possible to mix colored coins too
2. everybody can easily understand entropy gain and plan accordingly.

Perhaps I'm missing something... If your point is that it is possible to re-use existing protocol (if it is possible, I'm not sure about that: we need an ability to modify nSequence after list of outputs is known), then I guess it is good because it is saves work, but doing color-aware mixing protocol is definitely better in the long term.



You can get same results by mixing your coins before you buy that colored coin.

Yes. Isn't it obvious?


Yes, one needs to scan transaction history for a particular color. Of course, it is possible that he needs only a fraction of the whole history, but in the worst case he needs all of it...

Which is why in the long term we either needs Freimarkets, or some alternative solution, possibly SCIP.


With Mastercoin, one needs a list of all Mastercoin transactions up to the transaction in question. The only way to obtain it is to scan blockchain from the first block which has transaction sent to exodus address to the block which includes the transaction in question.

Some people think that it's possible to obtain a list of Mastercoin transactions without scanning the blockchain, but, actually, it is impossible to make sure that it is the correct list: attacker can simple withhold information about some transactions to perform a double-spend. There is no way to check whether list is complete.

(Well, aside from magic SCIP.)


As far as I know, SPV clients do not need to check transaction history.

You need to scan almost the whole blockchain to validate Mastercoin transactions. Obviously, thin clients can't do that...

"David Johnston" isn't an unique name, I guess he added "CEO" just to disambiguate. It's informative.

As for "The Second Bitcoin Whitepaper", it is as cheesy as it sounds... I don't know what kind of an explanation you're looking for.

FYI J.R. also created this: https://sites.google.com/site/2ndbtcwpaper/using-memes-to-explain-bitcoin#!

And this: http://lifeboat.com/blog/2013/04/bitcoins-dystopian-future#!

Here's an example of color_desc: "obc:b3b2c25ea6366d8506ea338f8e93624af897f284a511864eafe472d283819b41:0:147478"

It identifies a particular color, like URL identifies a page on a web site.


I do what I can... Why won't you help instead of complaining?

FYI that "Colored coins - BitcoinX" whitepaper is dead.

Here's an example of how it looks like now: Dusis5Fcme7fDa@moi5hNSCMRFpAgALXGGmVwqqeremPHvgfL

Dusis5Fcme7fDa is  a hash of color descriptor, moi5hNSCMRFpAgALXGGmVwqqeremPHvgfL is a normal testnet address.

We'll probably use a different format later, but the idea will be the same.

No, this is entirely an user-interface feature: user interface doesn't allow one to send to a "wrong" address.

But on the script level it is same as normal Bitcoin transactions.

Mastercoin and colored coins work in very different ways.

There are several different approaches here... The basic idea is that two parties enter a contract by signing a transaction of special form (with contract details encoded in OP_RETURN data, for example) together.

They can close it in two ways:

1. both of them agree on settlement payout
2. one of parties forces the settlement, referencing evidence of some sort in the transaction

In the later case, others can check if settlement is right.

There is also a more centralized variant: only some kind of authority can make a transaction with forced settlement.


No, it's just a different format of addresses. Like <color_id>@<bitcoin_address>.


The specification is incomplete.

If you mean the one written by Vitalik Buterin, it is pretty much completely unrelated to how it is actually implemented.