Topic: Is Mastercoin bloating the blockchain and what we can do about it? - page 3. (Read 10335 times)

With any luck you'll face competition from clones that realize the entire idea is just dumb. Are you planning to release the sourcecode to MasterCoin? Because if you don't, we'll all just say how it's probably got hidden backdoors that are going to steal all your (master)coins, and if you do release it, we can just take that code and remove the silly requirement for the exodus address/MasterCoins. Or just stick with, who was it, TierNolan and co's colored coins stuff?

Also, even if you want to use the colored coins paradigm, you actually don't need any data in the blockchain at all beyond what appear to be bog-standard pubkeys. Even better, is that you can design your protocol to really make it censorproof by allowing the colored coins to be included in standard CoinJoin transactions in such a way that anyone looking at the blockchain data will have no way of knowing what outputs were the colored coins.

Frankly the only clever thing you've done is you've taken the same colored coins/side-chains ideas everyone else has and found a way to get Bitcoin users to shovel money at you for it. Too bad really - I guess the rest of us couldn't imagine how you didn't even need to write any code to separate $300k worth of Bitcoins from the idiots who used to own them. (We forgot about The Pirate already!) Hopefully that's not actually true, and it's actually your own money and not many people are getting scammed here.

Anyway, I have better things to do than waste my time talking about ideas sufficiently stupid to be indistinguishable from scams for free, so don't bother replying unless you've got a paying contract. (1.5BTC/hr, escrow required for you)

I will say though, you're so close to doing something useful for me: showing the world how little protection we actually have against the UTXO set being bloated other than the blocksize limit. Do me a favor and keep your stupid protocol just the way it is.

Hey Peter! Thanks for checking out the project! (Peter and I met at the conference in San Jose, and had some interesting discussions there, and he is a tireless advocate for keeping bitcoin awesome, as you can see from his sig)

I completely agree. We seem to have a rather formidable war-chest

Being a good block-chain citizen is a matter of survival for MasterCoin. If we don't, we'll face competition from a clone that says "We're like MasterCoin, but with less impact on the blockchain"

Given how much money you've raised it'd be quite easy to pay someone to add support for OP_RETURN to those clients, among other things.

I think you are assuming that we have code which directly sends MasterCoin transactions, which we do not. Sends are currently accomplished using standard unmodified bitcoin clients (bitcoin-qt, blockchain.info, etc)

JR, put OP_RETURN in front of the data script. That can't take more than a few seconds to change, and a few minutes to communicate. You may even be able to use dust/empty outputs in this case (you should, but not sure if the client supports it yet).

Agree it should be easy on one client, but less so for people who are currently using blockchain.info for MasterCoin. I don't want to leave them hanging.

I look forward to seeing what people come up with for hiding this data in the chain in more efficient ways

I believe no more than a couple of days of work, if you know what are you doing. Likely less than that for a person who is very familiar with the client codebase, data structures etc.

So, yes, it makes sense to do this from the start.

Relevant PM:


edit: I accidentally said "higher protocol layer" in this PM, but I meant bitcoin, the lower protocol layer.

Sure. I've got to run a small list of expenditures by the oversight board next week, which includes the bounty that you and bytemaster earned. Thanks!

I'm totally cool with stuffing the data in alternate places once we have our own client. I see using unspendable transactions as a "crutch" so that the protocol works until we get to that point. For instance, right now none of the existing bitcoin clients has functionality that will let an average user hide data in OP_CHECKMULTISIG.

I expect once we have alternate ways of storing the data, we'll support both methods for awhile, then switch to the more efficient one at some pre-determined block number.

MasterCoin wants to be a good block-chain citizen in the long run, but we are willing to put that off in the short run in favor of simplicity and immediate usability. Also, one of my design goals was to be "censorship resistant", meaning it would be really hard for anybody to tweak the bitcoin protocol such that MasterCoin no longer works. Any pruning scheme will need to be similarly robust.

Thanks for your input!

+1. This was going to happen sooner or later. There's way too much brainpower on these forums to not have a rational storage implementation come out of this effort.

Whilst getting consensus on this topic is unlikely, I would think it's clear JRW is not just spitting out another 'altcoin' and would look at any suggestions to mitigate blockchain bloat - Mastercoin is supposed to complement Bitcoin after all.

Given Mastercoin is an additional layer of functionality that sits on top of Bitcoin, it therefore needs Bitcoin to succeed and as such it would make no sense to make design choices that negatively impact Bitcoin.

Shame to see the hostility (I've always found collaborating to be much more rewarding) but I'm sure with the quarter million plus $ raised the project will be able to engage the right minds to find the best implementation.

There was a suggestion to directly limit the UTXO set.  For example, a block is invalid if the number of outputs is more than greater than the total number of inputs.

An output that pays to OP_RETURN wouldn't count as an output.

What about a weaker rule, if there is a tie between 2 blocks, break the tie in favor of the one with lower (total output - total inputs).

If a node receives a block and it would result in a small UTXO set, it still forward it and mine against it, displacing the earlier received block.

This would only affect blocks when orphans would happen, but does create an incentive to favor transactions which reduce the UTXO set.

A block which combines lots of dust into a single output would have an advantage, so miners would include those for free.

@dacoinminster, if you're still intending to give me those 3 BTC for pointing out that problem with your proposal, could you please send them to 1GMaxweLLbo8mdXvnnC19Wt2wigiYUKgEB

@gmaxwell, thanks for your efforts.

Identify those transactions and reject them as invalid.
Do not store or relay them.

Off-Chain transactions comes to mind but may only be a part of the total solution
https://bitcointalksearch.org/topic/decentralized-networks-for-instant-off-chain-payments-152334

https://bitcointalksearch.org/topic/m.2949016

@gmaxwell
Sorry to add towards the posting just replying now while it is still fresh.

EDIT:
After reading the bitangels response on the Mastercoin thread and the devs reply I am on the fence with either implementation this needs more discussion since both sides seem to have validated points.
That said discussion has started, which is encouraging.

Unfortunately not everybody will be willing to use the Bitcoin blockchain as we/the devs would like. If someone creates something that bloats the UTXO set, they might just do not care about what the devs think about it.

How we solve THAT problem?

Creating an altcoin system which stores its data in blockchain is parasitic and increases the cost for non-consenting Bitcoin uses— and I think that is not great, and, I think it's pretty objectively clear that it bloats the blockchain, but that is not what I was complaining about.

Nor do I think we needed _yet another thread_ to help pump the name of this latest altcoin. This will be my one and only post in this thread and I hope other people decline to help give free PR here by continuing to post in this thread and giving them a free controversy to spin.

The issue here is that that mastercoin stores data in Bitcoin by creating perpetually unredeemable transaction outputs. It doesn't just store data in the blockchain, it stores it in the UTXO set and the blockchain. The former is a more precious resource than the latter. This kind of behavior, if wide spread, changes the asymptotic fast storage requirements for a full validating node from something close to constant (just some growth due to forever lost Bitcoins which all users are paid for via deflation) to perpetually growing.  The ability to for a full node to forget old transaction data would currently let you run one with about 2% of the storage that the blockchain takes up, but these outputs cannot be spent so they cannot be forgotten.

I am reasonably confident that you would prefer I defend Bitcoin by nicely asking as opposed to the alternatives.

No more than the door of your home cares when some thief walks through it when you've left it unlocked.  The technically possibility of something does not equal moral authority, nor does the possibility of doing something now guarantee that that possibility will remain in the future— especially if it causes harm to others, like taking up their resource for private use. Just because it's possible doesn't mean its right, nor does it mean that its wise.

I certainly believe the users of Bitcoin care and will take action to defend Bitcoin from use which is harmful to it. Some time back I'd made a minor technical proposal which would completely block data-storage txouts with no impact to normal Bitcoin usage.  Adopting it would require switching people to a new address style for new transactions, so it's not something that would be adopted quickly if the Bitcoin userbase were to decide to go down that route, but it certainly could be done.  I tend to think asking nicely is preferable, however.

I have better things to do with my time than to provide free consulting for altcoins who've just raised hundreds of thousands of dollars worth of investments in their ill considered schemes. The concerns here are not new, the impacts of unspendable outputs are not mysterous to people who have even half a technical clue about the Bitcoin system, and the solutions are not subtle.

My preference is that you do what hundreds of other altcoins have done and not store your data inside Bitcoin (but feel free to merge-mine if you need a consensus system), don't non-consensually consume the resources of people who are disinterested— even opposed— to your system... but failing that, see what all the other people piling on are saying about keeping data out of the UTXO set as a bare minimum.

Or prefix the data output with OP_RETURN, which is guaranteed to be prunable. If the output is never meant to be spent, then it is irresponsible not to do this.

It bloats the UTXO set, which is bad.

MasterCoin transactions should all be spendable or provably prune-able. There are plenty of ways to accomplish that, the easiest of which that works today would be to stuff data into unused public keys of an OP_CHECKMULTISIG transaction.