Make Master Protocol harder to censor

[ripper234]

The 1Exodus marker address is making it easy to people to censor Master Protocol transactions. This spec issue is a placeholder for discussion on how to upgrade the protocol in a way that will make such censorship harder.

@petertodd, @dexX7, @LOLLOLOOLOL, can you share your thoughts on the matter here?

@CraigSellars FYI

[ghost]

I'm not sure that's such a crippling result, PT

If its possible to chain those transactions together, with some metadata to keep the order, something could be constructed to workaround the limitation as Mastercoin's done using multiple multisigs for large amounts of data, for ex.

[petertodd]

@faizkhan00 You have to understand that while moving towards supporting OP_RETURN is arguably good, doing so leaves Mastercoin vulnerable to censorship; OP_RETURN support is easily turned off and core devs have promoted doing so on occasion. This is a fundemental disagreement on what Bitcoin should be used for.

[wizkid057]

@petertodd At the risk of going off topic a bit, I'll address merged mining and Coiledcoin with this: Who gives/gave a crap about Coiledcoin? It was yet another junk complete clone ripoff coin someone whipped up to try and make a buck. Its fate was death from the beginning, like every other nonsense coin out there today, regardless of if anyone "attacked" it or not (which from my understanding wasn't the case anyway...)

Assuming MasterCoin is legitimate and makes sense to mine, merged mining would be the perfect fit since a) miners would have some incentive, even a small one, to support the network; b) the majority of Bitcoin miners could and would easily adopt this coin for merged mining.

I'll point out namecoin as an example. Good luck censoring namecoin at 10 billion difficulty. A coin that doesn't matter nor ever mattered nor will ever matter (CoiledCoin) will never be supported because its just crap and no one would believe in it enough to bother.

Along side merged mining you can obviously have actual dedicated mining, perhaps at an increased incentive, for further increased security.

There's certainly a way to make merged mining work for MasterCoin using some kind of clever transitional mechanism... something like the MasterCoin chain not actually taking effect until the chain difficulty reaches X% of Bitcoin, lets say, and then the chain snapshots MasterCoin related data from the Bitcoin blockchain into its own at that point and continues on as a self-sustained entity that is fully protected from censorship. There are definitely ways to do it with proper effort, I'm sure.

But away from merged mining, @petertodd, I think storing non-bitcoin data directly in the Bitcoin blockchain is just a bad idea in general. If you really want anti-censorship, you're going to need to get away from that eventually I'm sure anyway.

In the short term, while your solution does not bloat the UTXO, I won't really bother with it, personally. I don't think the option to bloat the UTXO should exist either, since that just means that the project itself doesn't care about Bitcoin at all... more reason that it should be its own chain.

Are there solutions besides merged mining and bloating the UTXO that support your anti-censorship need?

[petertodd]

If its possible to chain those transactions together, with some metadata to keep the order, something could be constructed to workaround the limitation as Mastercoin's done using multiple multisigs for large amounts of data, for ex.

That's part of what this discussion is about: how best to work around OP_RETURN limitations in the cheapest possible fashion. Chaining transactions isn't the cheapest way to do it. :)

[ghost]

I think alternate implementations (such as libbitcoin) will continue to support features like OP_RETURN not only because it is in their best interest but because it has value to the protocol and the community

Given that and the current volume of 2.0 transactions, it may not really be necessary to require the full power of the Bitcoin network at all, but only a fraction (the fraction that cares to support OP_RETURN, for instance).

[ghost]

Agreed, its not cheap... But it works :)

[ghost]

Another way would be to have a 3rd party provider store all the data off-chain, with only the smallest possible information necessary to convey a successful transaction being stuffed in an OP_RETURN. Judging from your earlier comments, 40bytes might not be enough for even that approach :/

[petertodd]

I think alternate implementations (such as libbitcoin) will continue to support features like OP_RETURN not only because it is in their best interest but because it has value to the protocol and the community

In general, keeping Bitcoin open to permissionless development has significant value - we all want a Bitcoin where new technologies making use of the network don't have to ask permission from a small minority of mining pools and "core devs" first.

Given that and the current volume of 2.0 transactions, it may not really be necessary to require the full power of the Bitcoin network at all, but only a fraction (the fraction that cares to support OP_RETURN, for instance).

@faizkhan00 Yeah, that's an interesting long-term aspect of the discussion: will miners start rejecting valid blocks that contain Mastercoin transactions? Maybe, but doing so quickly destroys Bitcoin in general, so it's pretty unlikely.

[wizkid057]

@petertodd, @faizkhan00 It's not cheap because it's not data that should be in the bitcoin blockchain in the first place, hence the associated cost of utilizing that resource.

Since miners can mine the transactions at whatever fee they see fit, perhaps it would make sense to partner with miners to reduce the costs, but be able to fall back to the fee if needed.

[luke-jr]

@petertodd While I will entirely agree we don't want permission from "core devs or pool ops", your assertion that permissionless is the only (or correct) solution is very wrong, and you should be well aware that such a system cannot function and will die. The obvious answer is "permission from the collective" - ie, let those who want to relay/mine it do so, and those who don't, don't.

[petertodd]

Another way would be to have a 3rd party provider store all the data off-chain, with only the smallest possible information necessary to convey a successful transaction being stuffed in an OP_RETURN. Judging from your earlier comments, 40bytes might not be enough for even that approach :/

Oh believe me, this has been discussed! Heck, AFAIK I came up with one of the first solid ways to do so, written up as my "zookeyv" protocol on the #bitcoin-wizards mailing list. There are some interesting tradeoffs possible for certain applications, but they generally all need to be able to "fallback" to the secure Bitcoin blockchain if the less-secure alternative is attacked. (or of course they just accept that they're less secure!) Equally, usually you don't need metadata to be in the blockchain - e.g. the name of assets and so on - so long as it's committed in the blockchain by hash.

You should read my paper on proof-of-publication if you haven't already: http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg03307.html

[ghost]

@wizkid057 Partnering with miners seems ideal, but this issue needs to be brought up: is the volume of OP_RETURN transactions (not only in the Mastercoin dimension) on the blockchain now justified in making these discussions relevant? I think at the current volume, this is like asking a Mom&Pop to pay co-location fees for special kinds of internet traffic. While the argument makes sense at certain macro levels, I think the miners hardly notice the effect of a couple thousand OP_RETURNS here and there (but would love some numbers to back this up from the miners).

[wizkid057]

@faizkhan00 I'm not sure the volume matters much. With OP_RETURN You're basically paying a fee at a cost per byte for essentially infinitely durable long term arbitrary data storage, and IMO that shouldn't be free/cheap.

While I still don't like the fact that non-Bitcoin data is being stored in Bitcoin, I'd at least support using OP_RETURN over any UTXO-based method if it meant protecting Bitcoin from UTXO bloat... even more so if a long term road map included eventually getting off of Bitcoin's back...

[petertodd]

@wizkid057 Who gives/gave a crap about Coiledcoin? It was yet another junk coin someone whipped up to try and make a buck. Its fate was death from the beginning, like every other nonsense coin out there today, regardless of if anyone "attacked" it or not (which from my understanding wasn't the case anyway...)

That's exactly the issue: Coiledcoin gave a crap about Coiledcoin, and because they were merge-mined the could be attacked by anyone with hashing power.

If Mastercoin was merge-mined it'd be very easy for, say, Blockstream to use some of its investment capital to buy sufficient hashing power to attack it and destroy it, removing a competitor to the project.

This isn't about what isn't a so-called "shitcoin" - notably a term Austin Hill likes to use - this is a question about how to best secure your system from adversaries at the cheapest possible price. Like I said above, we do tell people to not re-use addresses because if everyone doesn't it makes censorship harder - embedded consensus system are very wise to take that advice.

[ghost]

@petertodd wrote:

they generally all need to be able to "fallback" to the secure Bitcoin blockchain if the 
less-secure alternative is attacked

Yeah, and if the most important (financial) data is embedded in the 'chain, I think that the number of guarantees that can be made goes up (but i think there are a number of theorhetical rebuttals against this point to begin with)

thanks PT, will check that paper out, sounds like something to look into for discussions such as these

[wizkid057]

@petertodd Coiledcoin gave a crap about CoiledCoin because it was their scam they came up with to rip people off... I certainly don't think that is a legitimate reason for anyone to bother with it. But lets move away from this, since it isn't really relevant...

In any case, you say if MasterCoin was merge-mined someone with hash power could attack it.... that's the same with any mined coin, including Bitcoin. I'm suggesting that you get a sufficiently large amount of hash power on board with the merged mining before MasterChain even matters, thus pretty much preventing this entirely.

No one is going to spend millions on enough hash power just to temporarily cause problems to a merged mined coin... nor are miners/pools going to do so and sacrifice the legitimate income generating by just playing ball.

[petertodd]

@wizkid057 I'd at least support using OP_RETURN over any UTXO-based method if it meant protecting Bitcoin from UTXO bloat...

Mastercoin already implements encoding methods that do not bloat the UTXO set and always will. But I also advise them to continue to support encoding methods that do as a defense against censorship should miners attempt to block the Mastercoin protocol.

Incidentally, I'd advise you to read my proof-of-publication paper as well; you seem to have some misunderstandings of the theory involved. This isn't a question of data storage, but rather proof-of-publication.

[ghost]

I'm not sure the volume matters much. With OP_RETURN You're basically paying a fee 
at a cost per byte for essentially infinitely durable long term arbitrary data storage,
and IMO that shouldn't be free/cheap.

Maybe not, but depending on how fees evolve for the network in the future, its hard to say how much of a difference/cost OP_RETURN makes. It could be that OP_RETURN could be had for free if the rest of the network received fees well beyond the per-byte cost of a transaction, such that the opcode is basically operating on a 'freemium' plan (supported by other transaction's fees).

Edit: perhaps businesses that rely heavily on Bitcoin transactions would pay a premium, subsidizing other parts of the network?

[wizkid057]

@petertodd a dust output to 1Exodus for every transaction certainly is not UTXO neutral... nor in support of anti-censorship

[wizkid057]

@faizkhan00 The regular transactions pay a fee to be processed and stored. OP_RETURN txns should be no different, really.

[petertodd]

@wizkid057 In any case, you say if MasterCoin was merge-mined someone with hash power could attack it.... that's the same with any mined coin, including Bitcoin. I'm suggesting that you get a sufficiently large amount of hash power on board with the merged mining before MasterChain even matters, thus pretty much preventing this entirely.

Again, embedded consensus means we have the same hashing power as Bitcoin on day one, and ensures that's always true. Note how even Namecoin, mined by a majority % of the Bitcoin hashing power, is still more vulnerable than it would be as an embedded consensus system as chosing to not mine it or attack it can be done with cost only equal to the marginal return that Namecoin provides, which is small. Again, if someone wanted to attack Namecoin the cost to do so is only that much smaller marginal cost rather than the much larger cost of actually having hashing power.

a dust output to 1Exodus for every transaction certainly is not UTXO neutral...

Those dust outputs get periodically spent, and anyway, will likely get removed from the protocol eventually for better anti-censorship properties as discussed above.

[wizkid057]

@petertodd Have to run soon, but I guess I'll leave with a final question:

Do you support MasterCoin implementing a system, now or in the future, regardless of reasoning (censorship, whatever), that utilizes unspendable outputs on the Bitcoin blockchain?

I think this is important to know so Bitcoin users know what to support in this regard.

[petertodd]

@wizkid057 Of course I do. Decentralized protocols have to handle "abuse" via economics, not persuading people to act against their best interests, and we know of a variety of good solutions to UTXO set growth. Heck, Mastercoin already makes use of one of those solutions, one I even first proposed myself, the minimum dust limit, as its multisig encoding is specifically designed to use spendable outputs to reduce costs.

[wizkid057]

Alrighty. I will continue with best efforts to filter MasterCoin then, since if this is the case it works to the detriment of Bitcoin.

End of line.

[petertodd]

Please do. It's useful to have a motivated but weak attacker on hand when you're designing security-related software to give you an easy way to test your defenses against stronger attackers without causing real problems to your system.

Equally, Mastercoin can be seen as such an attacker from the Bitcoin side of things if you want. ;)

[dexX7]

1) The unnecessary 1Exodus output indicating it is a Mastercoin transaction.

Some marker is required, right? But this could indeed easily be moved into OP_RETURN which was already discussed earlier, but back at that time v0.9+ clients were rather a minority. And ...

2) The abuse of multisig and p2pkh outputs to convey data rather than OP_RETURN.

... it's more a question of available space and potential confirmation delay due to new-ish output types. I'm in the camp of getting rid of most of the descriptive meta-data like memos (just an example which is actually not used), but even if this data is replaced by a reference, the reference itself needs to be stored, too. Combined with a marker it's even worse.

In contrast bare multisig encoding appears much more favorable.

I think it would also be ideal if Mastercoin migrated to its own blockchain - it really has no inherent need to be inside bitcoin's, and does not benefit from being there either.

I'd name easier Bitcoin <> Mastercoin interaction, but that's probably a huge topic on it's own.

What I stumbled upon by the way: https://github.com/maidsafe/MaidSafe-Routing/wiki

Allegedly secure DHT with rich feature set at beta stage.

[petertodd]

@dexX7 Some marker is required, right?

Not necessarily, and it certainly doesn't have to be a specific address. For instance you can just try interpreting every transaction as MSC transactions, rejecting invalid ones. Of course the vast majority will be invalid, but that's not a problem. Markers can make things more efficient, but in that case it's quite possible to use "fuzzy" markers that match probabalistic filters. For instance you could make the marker be such that a specific bloom filter matches it, use bloom filters to get the set of all MSC transactions plus some false-positives, and then interpret that subset as above.

I'd name easier Bitcoin <> Mastercoin interaction, but that's probably a huge topic on it's own.

That came up in my discussions with Zerocash actually. Having it be a separate blockchain, merge-mined or not, greatly increases the time it takes to securely exchange Zerocash and Bitcoins due to the reorg risk from attacks. For instance many alts, e.g. Feathercoin, has been attacked with huge reorgs so often that exchanges make you wait a day or so before your deposit is accepted. Equally the sidechain proposals force you to wait dozens or hundreds of confirmations before using sidechain-specific withdraw methods to avoid making reorg attacks profitable to carry out.

What I stumbled upon by the way: https://github.com/maidsafe/MaidSafe-Routing/wiki

After visiting Maidsafe in person I don't have any reason to think they know what they're doing with respect to consensus security.

[robby-d]

To second @petertodd's comments on Counterparty, it was originally designed to work with 80-byte OP_RETURN outputs by default, both to minimize transaction cost and impact to the Bitcoin blockchain. Only when OP_RETURN was reduced in size from 80 to 40 bytes, we moved to encoding in multisig outputs as our first line method.

Moreover, a few months ago we implemented support for more adaptive encoding that allowed certain transactions (e.g. simple sends) to be encoded into the 40-byte OP_RETURN. However, from what I recall, our testing showed that BTCGuild in particular did not appear to be mining these transactions, so we had to keep to using multisig for everything in order to minimize confirmation delays.

If Bitcoin adopted an 80-byte OP_RETURN (as was the original plan, at least as it was publicly communicated) that was mined by all major pools, we would gladly move to use OP_RETURN. And due to the security considerations Peter raised, merged mining is not an actual option.

[petertodd]

@xnova Yeah, lots of the hashing power hasn't updated their bitcoind to the one where OP_RETURN was introduced; it causes problems for stealth payments as well.

[ghost]

Whats the current expense of one OP_RETURN transaction? The cost of two can't be prohibitive...

[ghost]

@xnova, I'm curious as to what was done to make your simple sends fit into 40 bytes, if you have information on that I'd like to take a look

[dexX7]

For instance you can just try interpreting every transaction as MSC transactions, rejecting invalid ones.

Well, this seems rather crude, but actually not every transaction needs to be checked, but only those which interact in some way with "known Mastercoin entities", starting with Exodus.

[dexX7]

Whats the current expense of one OP_RETURN transaction? The cost of two can't be prohibitive...

Should be around 0.0001 BTC - without reference or marker output.

Edit: Mastercoin Simple Send has a length of 16 bytes. This would actually leave space for a receiver reference (20 byte) and a tiny 4 byte marker.

[petertodd]

@faizkhan00 There's a IsStandard() limit of one OP_RETURN txout per transaction; they don't cost anything beyond standard tx fees.

@dexX7 Well, this seems rather crude, but actually not every transaction needs to be checked, but only those which interact in some way with "known Mastercoin entities", starting with Exodus.

Well, I am talking very generally about the theory behind embedded consensus, not specifcs there. In any case, you are correct to say that one "marker" method is to just look for all (script)pubkeys that might sign a MSC transaction. (+ some way of adding a (script)pubkey to that set) However actually using that as a useful marker isn't necessarily useful - you'd quickly end up with a 100% filed bloom filter for instance. Remember that the point of markers is to reduce bandwidth and CPU usage by Mastercoin-protocol participants - that marker method fails on both counts.

Note how with colored coins that "marker" is essentially always available, but with local consensus, in the sense that if you care about a particular colored output you can easily find the next transaction spending it in the exact same ways that a wallet would for any transaction.

[ripper234]

I think this is actually turning out into a useful thread, some very good discussion here.

Peter I like your model of Mastercoin "attacking" Bitcoin and pools "attacking" Mastercoin. Security should not rely on the lack of attackers in existence.

[dexX7]

Remember that the point of markers is to reduce bandwidth and CPU usage by Mastercoin-protocol participants ...

I think I have a bias against a marker-free approach which is not necessarily reasonable and I'm rather spoiled by using an address indexed branch all the day.

Since MasterCore is already a heavy client, it would certainly be possible to use no marker at all and test every transaction.

Is there anything that speaks against it, besides potential performance implications?

[dexX7]

After re-reading the thread, a few more notes:

@faizkhan00: ... volume of OP_RETURN transactions ...

There is almost no volume at this point. At a block height of 312999 I came up with these results (the numbers represent the total amount of all outputs of it's type on mainnet [Null Data = OP_RETURN]):

@wizkid057: With OP_RETURN You're basically paying a fee at a cost per byte for essentially infinitely durable long term arbitrary data storage, and IMO that shouldn't be free/cheap.

Using OP_RETURN and paying a fee purely based on size would be perfectly fine, even with chained transactions, an reasonable (theoretical) additional fee, because it's data or whatsoever. The blocker is rather the widely used "fee per 1000 byte rounded-up" policy. Given that a OP_RETURN transaction is roughly in the range of 190-225 byte, that's a cost overhead by a factor of 4-5x, thus it's much more appealing to "abuse" other output types and use the space that would otherwise be wasted.

@wizkid057: People running full Bitcoin nodes have essentially agreed to store the Bitcoin public ledger, not your Mastercoin ... merged mining would be the perfect fit ... to support the network ...

I picked those comments almost arbitrary, but I have the impression that one point is brought up quite often: "metacoins enjoy a free ride, do not contribute, fullnode owners suffer, etc. ..."

What is probably overlooked here is the fact that Mastercoin or metacoin users in general have an inceive to contribute to the underlying network as well. Merged mining aside, but for the sake of an example: would you rather prefer MSC friendly miners and node owners to support Bitcoin or an alternative chain which MSC uses exclusively? In my opinion fragmentation should be avoided.

[ABISprotocol]

Hello, Why not just leave it up to individuals as to what sort of information (or how much) they will convey? Though the thread seems to have gone this way and that, the concerns I have seen here seem to relate primarily to: 1) 1Exodus output / Exodus markers, use of such in Mastercoin, 2) multisig and p2pkh outputs vs OP_RETURN, 3) non-financial or non-transactional information. 4) blacklists or potential for those to grow, 5) [ @xnova ] 80-byte OP_RETURN and Counterparty For some reason here I am reminded also of a discussion related to Ethereum which indicated the possibility of nodes of various types and complexities ~ to wit, a question was posed as part of the post I am remembering here, which asked, "Should we modularize(Ethereum clients) so that we can, for example, have a client that can only send transactions but that doesn't need to mine? Having modules reduces code size and allows for defining only what is necessary to interact with the Ethereum ecosystem for a specific context." The answer was something like "yes:" "You betcha. Ethereum nodes will have various degrees of complexity from bare-bones to a full processing node, and everything in between." I am not here to emphasize use of Ethereum rather than (X,Y,Z), or of Mastercoin in place of or in addition to X,Y,Z, or of Bitcoin in particular, (though I think all of the aforementioned projects are very promising in their own right), but when we are looking at any distributed, decentralized system, and as I ponder the context of this discussion thread, a few things occur to me: 1) The ability to have individuals convey what sort of information they want without that information being restricted is important. 2) Individuals should be able to decide how private or public they want to be in interactions with one another across different decentralized systems, and should be given the option of anonymity. 3) In the range of possibilities, individuals should be able to utilize either "light" or "heavy" nodes (with various ranges in between) that convey what they wish to convey in a way that reflects their desired level of participation. In other words, some types of nodes might be designed that convey certain types of information (let's call these types C Nodes just to be as general as possible), and others might be designed that wouldn't convey the full range of information that C Nodes would ~ let's call these D and F nodes, just for the sake of some sort of minimal categorization. There are already many ways, some lighter, some heavier, that people have to interact with Bitcoin, but I'm suggesting that there should be a greater ability for individuals to choose along a range involving degrees / variations of nodes ~ some would do more and some would do less, some would reward people for conveying and confirming lots of information, others simply serving to allow broadcasting of a limited degree of information.

I do realize that miners make significant decisions in the bitcoin sphere. With that said, I suggest that individuals (really: any users) be given a greater role (whether we are talking about Bitcoin, Mastercoin, or anything else) in terms of what sort of information they will facilitate and what will be processed by them. At the very least, this implies that if we are looking at various types of nodes, that individuals are likely to aggregate towards nodes that burden the individuals least when they are participating in a decentralized system. This also may imply that some developers may take an interest in seeing a greater degree of control given to individuals through settings in whatever type of wallet (including full client) the user is interested in. Finally, I don't think that merely because there may be non-financial or non-transactional information conveyed, that this should be a problem for Bitcoin or for any other system. Efficiency is not the only goal that developers should have in mind (sure it's important), but also there should be an analysis which includes ensuring that the individual users are able to voluntarily decide what they wish to convey, confirm, etc., as well as providing the means for people to more readily and easily engage in voluntary processes which include giving, as part of what they do during their participation in decentralized systems.

In closing... "In the land of the blind, the one-eyed man is king..." (Desiderius Erasmus Roterodamus [27 October 1466 - 12 July 1536])

[dexX7]

Sort of related: http://eligius.st/~gateway/news/mining-policy-discussion

As always, Eligius plans to support full miner customisation of their own policies via GBT as soon as it's finished. However, since that is still a bit off, we've decided to hold a public discussion to determine the more near-future Eligius transaction mining policies. Topics may include things such as spam filtering, transaction fees, prioritisation, or anything else that affects what transactions we put in our blocks.

The discussion has been tentatively scheduled for October 4th at 4 PM UTC in hopes that this is convenient for the greatest possible number of miners. This is 9 AM for west coast USA, noon for east coast USA, and 8 PM for Moscow. It is also Lamboary  at 9.99T by the Tonal calendar and clock.

The meeting will take place in the #eligius channel on Freenode IRC.

Since the meeting may have high turn-out, it is advised to use a dedicated IRC client or the freenode webchat client rather than the webpage's Chat applet.