Quote from: TraderTimm on August 06, 2013, 09:55:55 PM

Quote from: dacoinminster on August 05, 2013, 11:59:38 PM

Quote from: TraderTimm on August 05, 2013, 11:46:38 PM

I've been thinking about the fundraising part, and I can concede that being able to eat and keep a roof over your head is equitable. I'm just concerned about the nature of fundraising when it is paired with:

Quote

"Get 'em now folks, before they're worth SO MUCH MORE."*(multiple caveats in fine print)

Upon further consideration, that is the real 'meat' of my argument, in addition to the overall blockchain impact - which I'm not very pleased about, since I have no way (at this time) to say "no thank you, I will not verify your data". Bitcoin being what it is, it should be opt-in - the same way it is for what version of client you choose to run (unless we fork so hard we have to select one).

That's another problem, isn't it, it takes off and then we're talking not only about multiples of bandwidth/storage, but the ability of the main bitcoin devs being able to pick up the pace for future expansion and improvement. And since I've never bought the early-stressor argument either, please don't try it, it isn't very convincing.

Yup. If MasterCoin is successful, it will add a lot of transactions to bitcoin, making the total size of the block chain even more painful.

You are right - there is simply no way to prevent people from trying crazy stuff like this on top of bitcoin. For someone like me, that's kind of cool. Other people may not be so excited about it

Sometimes when I read crazy ideas like these, I have to wonder if we're either on the precipice of something horrible - like two halves of plutonium banging together and going critical, or something great, like the birth of the internet. The main issue here is the risk taken in doing so. If your baby 'breaks' bitcoin (For whatever duration - either temporarily or permanently), will the usual sentiment I see from software engineers the world over - usually along the lines of "Well, if 'X' couldn't handle it, then 'X' is stupid and deserved to die." - going to be enough to placate the angry mob of now-bereft bitcoiners?

Of course, the flip side is supposed to be "well, if we didn't do new things no progress would be made" -- but I've yet to see anyone say "Lets test this idea out responsibly just in case we totally fuck something up." It's all SHOVE it into the live production network and see what chaos it causes - "Oopsie!, we're just trying new and crazy ideas guys, so sorry for screwing over the rest of the community."

There has to be a better way than working on the jet engine while at 30,000 feet in the air - just saying.

Several people have raised the issue of blockchain spam after I did and I think it is very valid. Do we really need data streams (for example) permanently encoded in the bitcoin blockchain for all time? Your use of bitcoin will likely drive txn fees much higher, which will cause large chilling effect on MasterCoin and a smaller one on bitcoin. Let's try to keep the bitcoin txn fees low, because regardless of whether MC succeeds or not, it would be nice to protect our BTC stashes :-). So I'm quoting my own suggested solution (massively reworked for clarity) because it was not responded to the 1st time:

Quote from: thezerg on August 06, 2013, 01:17:58 AM

You have done some amazing work in cramming this protocol entirely inside bitcoin. I skimmed this but did not analyze. But there seem to be clear issues with this such as data density (space efficiency), complexity (bugs), lack of control over the underlying Bitcoin protocol (as BitcoinX discovered with the "dust" patch), and possibly a perception of SatoshiDice-like spamming from the point of view of Bitcoin-only users. At the same time the critical issue with alt chains is the lack of atomic exchange between BTC and the altcoin.

So, have you considered running a parallel chain for MasterCoin, but one that ALSO uses your research into overlay protocols to stick the minimum possible information into the bitcoin chain? For example, when trading bitcoin for mastercoin (atomically) there would need to be a txn in bitcoin with overlay data that the Mastercoin chain can reference. The Mastercoin side would be IN the Masterchain blockchain but would be invalid unless it finds the partner bitcoin txn.

Frankly, I think that that's it. That's the ONLY time the bitcoin chain need be used.

MasterCoin clients would need access to both chains. This would require no more data than an overlay protocol would use -- its just a different organization. But that organization solves all the problems I described above. And I think that with clever coding someone in the future could allow a "non-btc-validating" MasterCoin client that sees only the MasterCoin chain (and can only issue intra-MasterCoin transactions). Basically, "btc-validating" miners (all MasterCoin miners would be btc-validating) would add something to the MC blockchain that "commits" the prior MC txn. So non-btc-validating clients would look for that commit txn before validating the MC txn.