Make Master Protocol harder to censor #248

ripper234 · Sep 6, 2014

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

See also confirmation that Eligious is censoring Master Protocol.

ripper234 · Sep 6, 2014

See also confirmation that Eligious is censoring Master Protocol.

Forcing people to mine transactions they don't want to mine is bad. Don't bother trying, because it's impossible to prevent anyway, just makes more work for the good guys who should be able to spend their time improving Bitcoin instead of battling spammers.

P.S. I recommend investing in a good dictionary, since you don't seem to know what "censorship" means or how to spell. :|

luke-jr · Sep 6, 2014

Forcing people to mine transactions they don't want to mine is bad. Don't bother trying, because it's impossible to prevent anyway, just makes more work for the good guys who should be able to spend their time improving Bitcoin instead of battling spammers.

P.S. I recommend investing in a good dictionary, since you don't seem to know what "censorship" means or how to spell. :|

Fixed op for spelling, tnx.
Let's agree to disagree Luke.

ripper234 · Sep 6, 2014

Fixed op for spelling, tnx.
Let's agree to disagree Luke.

Are you willing to agree to disagree? Or are you still planning to try to force me to agree with you?

luke-jr · Sep 6, 2014

Are you willing to agree to disagree? Or are you still planning to try to force me to agree with you?

You don't need to agree with me, just like governments don't need to agree to let Bitcoin operate.

ripper234 · Sep 6, 2014

You don't need to agree with me, just like governments don't need to agree to let Bitcoin operate.

To put it another way, Bitcoin doesn't need permission from governments to work, and Master Protocol should not need permission from Core Devs or Pool Operators to work.

ripper234 · Sep 6, 2014

To put it another way, Bitcoin doesn't need permission from governments to work, and Master Protocol should not need permission from Core Devs or Pool Operators to work.

Nor should you try to force core devs or pool operators (I think you really mean miners) to do your bidding against their will.

luke-jr · Sep 6, 2014

Nor should you try to force core devs or pool operators (I think you really mean miners) to do your bidding against their will.

As most actual mining is done by pool operators, the two groups are the same.
The so called group of miners, who do contribute hashing power to a pool, don't actually mine Bitcoin, they are just renting out their hash power. They have zero control over protocol decisions, don't validate transactions, and are at the mercy of the small group of pool operators (that is until they decided to leave centralized pools and join P2Pool).

I'm not going to engage on ideological debates with you Luke.

ripper234 · Sep 6, 2014

As most actual mining is done by pool operators, the two groups are the same.
The so called group of miners, who do contribute hashing power to a pool, don't actually mine Bitcoin, they are just renting out their hash power. They have zero control over protocol decisions, don't validate transactions, and are at the mercy of the small group of pool operators (that is until they decided to leave centralized pools and join P2Pool).

I'm not going to engage on ideological debates with you Luke.

So which part of that (not that it's accurate) do you assert justifies you forcing others to do your bidding against their will?

luke-jr · Sep 6, 2014

So which part of that (not that it's accurate) do you assert justifies you forcing others to do your bidding against their will?

Nor should you try to force core devs or pool operators (I think you really mean miners) to do your bidding against their will.

Without transparency (e.g. published blacklists), I don't see how this is a choice made by miners.

Nevertheless, what one could call censorship, can be called freedom from the perspective of the pool operator as well.

Getting rid of the Exodus marker is the first target, moving away from m-of-n multisig encoding altogether the second, given that m-of-n is almost exclusively used by metacoins. A marker (in form of an Exodus output or an unobfuscated prefix within the data package such as XCP uses) has it's benefits though, namely the ability to identify Mastercoin transactions really fast. This is good in terms of faster validation, but comes at the cost of being exposed to censorship. The question is probably: is there something that does not create additional cost for Mastercoin, but creates work and cost for those who'd like to filter the transactions, but are not a user?

My personal opinion and priority: 1. Get at a point where we don't need to rely on the merit of pool operators at all, e.g. by moving parts off-chain. We are probably far away from this, but it can start with any meta-data that is nice to have, but not strictly needed for the transaction to justify storage within the blockchain - such as lengthy asset descriptions or whatsoever.* 2. Improve the product, get away from being considered as spam, but worth to mine. The initial guesture of slightly increased fees, fees as basis of DEx spam protection etc. was a good idea, but unfortunally not fruitful. 3. If it's not critical, avoid cat and mouse games which come at the cost of both parties.

dexX7 · Sep 6, 2014

Nor should you try to force core devs or pool operators (I think you really mean miners) to do your bidding against their will.

Without transparency (e.g. published blacklists), I don't see how this is a choice made by miners.

Nevertheless, what one could call censorship, can be called freedom from the perspective of the pool operator as well.

Getting rid of the Exodus marker is the first target, moving away from m-of-n multisig encoding altogether the second, given that m-of-n is almost exclusively used by metacoins. A marker (in form of an Exodus output or an unobfuscated prefix within the data package such as XCP uses) has it's benefits though, namely the ability to identify Mastercoin transactions really fast. This is good in terms of faster validation, but comes at the cost of being exposed to censorship. The question is probably: is there something that does not create additional cost for Mastercoin, but creates work and cost for those who'd like to filter the transactions, but are not a user?

My personal opinion and priority: 1. Get at a point where we don't need to rely on the merit of pool operators at all, e.g. by moving parts off-chain. We are probably far away from this, but it can start with any meta-data that is nice to have, but not strictly needed for the transaction to justify storage within the blockchain - such as lengthy asset descriptions or whatsoever.* 2. Improve the product, get away from being considered as spam, but worth to mine. The initial guesture of slightly increased fees, fees as basis of DEx spam protection etc. was a good idea, but unfortunally not fruitful. 3. If it's not critical, avoid cat and mouse games which come at the cost of both parties.

@dexX7 Thanks for your input. Eligius uses my public spam filter branch, and miners are capable of seeing what they are mining at any given moment in full detail using GBT. I think your strategy sounds like a good solution to aim for; please feel free to ping me if there's anything I can do to help out in that area (I can't guarantee anything with Eligius since wizkid057 runs it now, but I can certainly recommend things to him if they make sense).

luke-jr · Sep 6, 2014

@dexX7 Thanks for your input. Eligius uses my public spam filter branch, and miners are capable of seeing what they are mining at any given moment in full detail using GBT. I think your strategy sounds like a good solution to aim for; please feel free to ping me if there's anything I can do to help out in that area (I can't guarantee anything with Eligius since wizkid057 runs it now, but I can certainly recommend things to him if they make sense).

@luke-jr "Forcing people to mine transactions they don't want to mine is bad."

Hey, just so you know I'm going to be starting a charity to help low-income pregnant teens pay for their abortions, provide sex-positive sexual education, and also operate a sunday school praising the word of God.

Should I have separate donation addresses for each of those categories so you can blacklist funds going to just the causes you dislike, or is that too much trouble and you'd rather block them all in one go?

petertodd · Sep 6, 2014

@luke-jr "Forcing people to mine transactions they don't want to mine is bad."

Hey, just so you know I'm going to be starting a charity to help low-income pregnant teens pay for their abortions, provide sex-positive sexual education, and also operate a sunday school praising the word of God.

Should I have separate donation addresses for each of those categories so you can blacklist funds going to just the causes you dislike, or is that too much trouble and you'd rather block them all in one go?

@dexX7

The Exodus marker is only truly useful if you have SPV mastercoin clients; we don't so dropping it for now until there is a secure way of querying blockchain data with fuzzy matching is reasonable. As for the encoding, blockpop does solve this stuff in a solid, forward-compatible, way.

Get at a point where we don't need to rely on the merit of pool operators at all, e.g. by moving parts off-chain.

Metadata sure, but remember that you can't replace the core data with off-chain stuff without a severe reduction in security.

If it's not critical, avoid cat and mouse games which come at the cost of both parties.

Honestly, that Eligius is the only pool blocking stuff is telling you know... The other 95% of miners realise that politicising transaction acceptance makes Bitcoin less valuable for everyone. Equally, this isn't a cat and mouse game, there's a tiny number of moves in the game that make sense, and you can very quickly force miners into adopting heavy-weight blacklists. Heck, that 95% aren't even adopting light-weight blacklists.

petertodd · Sep 6, 2014

@dexX7

The Exodus marker is only truly useful if you have SPV mastercoin clients; we don't so dropping it for now until there is a secure way of querying blockchain data with fuzzy matching is reasonable. As for the encoding, blockpop does solve this stuff in a solid, forward-compatible, way.

Get at a point where we don't need to rely on the merit of pool operators at all, e.g. by moving parts off-chain.

Metadata sure, but remember that you can't replace the core data with off-chain stuff without a severe reduction in security.

If it's not critical, avoid cat and mouse games which come at the cost of both parties.

Honestly, that Eligius is the only pool blocking stuff is telling you know... The other 95% of miners realise that politicising transaction acceptance makes Bitcoin less valuable for everyone. Equally, this isn't a cat and mouse game, there's a tiny number of moves in the game that make sense, and you can very quickly force miners into adopting heavy-weight blacklists. Heck, that 95% aren't even adopting light-weight blacklists.

Thanks @luke-jr, I assume that's the one: spamfilter? In general I think it's sad to see that there is a killswitch to block all bare multisig transactions which even made it's way into bitcoin:master while Eligius in particular (and I give you much credit for this) remains to be the only larger pool (that I know of) which supports exotic transactions. I'd rather wish to see more options than the only one which is intended to block "metacoin spam".

Especially when put into relation where the overall footprint on the chain is absolutely insignificant and providing simple tools such as an endpoint to retrieve unspent outputs of m-of-n transactions resulted in a complete remake of Chancecoin which is now basically build around the idea of spending dust instead of creating pollution - to name one example.

The Exodus marker is only truly useful ... As for the encoding, blockpop does solve this stuff in a solid, forward-compatible, way.

I actually see one argument to keep the marker as it is: the available infrastructure build around "addresses". Just think about Electrum - you may right now fire up your local client, fetch all Exodus transaction references within seconds via it's console with the command getaddresshistory("1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P") and reconstruct the current state within a very reasonable amount of time.

Maybe I missed your point or the capabilities of blockpop, but I assume you were talking about obfuscation of transaction data and suggest to drop the Exodus output. Say we drop the Exodus output - how are transactions identified?

Metadata sure, but remember that you can't replace the core data with off-chain stuff without a severe reduction in security.

Yes, that for sure. In this context I was thinking about meta-data like asset name, category, subcategory url, extra data and a memo field. Since not even the name provides any reliable information, but introduces name squatting and scam, I'm not really a fan of right it from the start. Going one step further and moving order publishments/negotiations would probably be acceptable, too. It's really too bad we are not at a point of output bound transactions - I dream about a decentralized digital asset exchange ~~with honest pricing and market depth~~ on steroids.

While I think without a doubt some form of secondary network for those things would be very awesome and should be aimed for, it's questionable, if the gain outweights the cost of establishing such a network - at least from a short term perspective. If we can come up with something that indeed offers actual benefits besides being "blockchain friendly", like faster transactions or whatsoever, that's a different story, but I don't see a light right now.

@luke-jr: I'm really interested in your input, not because I consider Eligius' block as game changing event, but as tip of the iceberg and the need for a solid solution which might offer other benefits has probably consequences far greater than the scope of Mastercoin in general.

Honestly, that Eligius is the only pool blocking stuff is telling you know... The other 95% of miners realise that politicising transaction acceptance makes Bitcoin less valuable for everyone. Equally, this isn't a cat and mouse game ...

I was actually surpirsed as well and expected worse. Nevertheless, isolated this doesn't justify much, but it can't hurt to think one step ahead or to act proactive instead of hoping this remains to hold true - better be safe than sorry.

dexX7 · Sep 6, 2014

Thanks @luke-jr, I assume that's the one: spamfilter? In general I think it's sad to see that there is a killswitch to block all bare multisig transactions which even made it's way into bitcoin:master while Eligius in particular (and I give you much credit for this) remains to be the only larger pool (that I know of) which supports exotic transactions. I'd rather wish to see more options than the only one which is intended to block "metacoin spam".

Especially when put into relation where the overall footprint on the chain is absolutely insignificant and providing simple tools such as an endpoint to retrieve unspent outputs of m-of-n transactions resulted in a complete remake of Chancecoin which is now basically build around the idea of spending dust instead of creating pollution - to name one example.

The Exodus marker is only truly useful ... As for the encoding, blockpop does solve this stuff in a solid, forward-compatible, way.

I actually see one argument to keep the marker as it is: the available infrastructure build around "addresses". Just think about Electrum - you may right now fire up your local client, fetch all Exodus transaction references within seconds via it's console with the command getaddresshistory("1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P") and reconstruct the current state within a very reasonable amount of time.

Maybe I missed your point or the capabilities of blockpop, but I assume you were talking about obfuscation of transaction data and suggest to drop the Exodus output. Say we drop the Exodus output - how are transactions identified?

Metadata sure, but remember that you can't replace the core data with off-chain stuff without a severe reduction in security.

Yes, that for sure. In this context I was thinking about meta-data like asset name, category, subcategory url, extra data and a memo field. Since not even the name provides any reliable information, but introduces name squatting and scam, I'm not really a fan of right it from the start. Going one step further and moving order publishments/negotiations would probably be acceptable, too. It's really too bad we are not at a point of output bound transactions - I dream about a decentralized digital asset exchange ~~with honest pricing and market depth~~ on steroids.

While I think without a doubt some form of secondary network for those things would be very awesome and should be aimed for, it's questionable, if the gain outweights the cost of establishing such a network - at least from a short term perspective. If we can come up with something that indeed offers actual benefits besides being "blockchain friendly", like faster transactions or whatsoever, that's a different story, but I don't see a light right now.

@luke-jr: I'm really interested in your input, not because I consider Eligius' block as game changing event, but as tip of the iceberg and the need for a solid solution which might offer other benefits has probably consequences far greater than the scope of Mastercoin in general.

Honestly, that Eligius is the only pool blocking stuff is telling you know... The other 95% of miners realise that politicising transaction acceptance makes Bitcoin less valuable for everyone. Equally, this isn't a cat and mouse game ...

I was actually surpirsed as well and expected worse. Nevertheless, isolated this doesn't justify much, but it can't hurt to think one step ahead or to act proactive instead of hoping this remains to hold true - better be safe than sorry.

In the end miners always choose which transactions to mine and which not to mine. This will never be the choice of the creators of the transactions or the security behind the purpose of mining would be pointless.

People running full Bitcoin nodes have essentially agreed to store the Bitcoin public ledger, not your Mastercoin (and other similar non-Bitcoin nonsense) that you're forcing people to also store against their will. As far as I'm concerned since it is not a legitimate Bitcoin transaction it is spam. As a miner it is my duty to prevent spam from reaching the block chain. As it stands now, most other miners are not fulfilling this duty.

I would, however, fully support most non-Bitcoin ventures if they could be merge-mined along side Bitcoin through either the existing merged mining setup (not so great but works) or an output in the coinbase transaction that can be pruned from indexes. This way people can choose whether or not to store whatever it is you store and support your efforts or not. It provides security for your own chain, it doesn't harm Bitcoin, and everybody wins. Whether or not that works for Mastercoin or not, who knows... may be too far gone to consider reasonable solutions.

wizkid057 · Sep 6, 2014

In the end miners always choose which transactions to mine and which not to mine. This will never be the choice of the creators of the transactions or the security behind the purpose of mining would be pointless.

People running full Bitcoin nodes have essentially agreed to store the Bitcoin public ledger, not your Mastercoin (and other similar non-Bitcoin nonsense) that you're forcing people to also store against their will. As far as I'm concerned since it is not a legitimate Bitcoin transaction it is spam. As a miner it is my duty to prevent spam from reaching the block chain. As it stands now, most other miners are not fulfilling this duty.

I would, however, fully support most non-Bitcoin ventures if they could be merge-mined along side Bitcoin through either the existing merged mining setup (not so great but works) or an output in the coinbase transaction that can be pruned from indexes. This way people can choose whether or not to store whatever it is you store and support your efforts or not. It provides security for your own chain, it doesn't harm Bitcoin, and everybody wins. Whether or not that works for Mastercoin or not, who knows... may be too far gone to consider reasonable solutions.

I think @petertodd hit the point exactly:

Honestly, that Eligius is the only pool blocking stuff is telling you know... 
The other 95% of miners realise that politicising transaction acceptance makes 
Bitcoin less valuable for everyone. Equally, this isn't a cat and mouse game,
there's a tiny number of moves in the game that make sense, and you can
very quickly force miners into adopting heavy-weight blacklists. Heck, that 
95% aren't even adopting light-weight blacklists.

Why even spin cycles for a single pool who cares to enforce a blacklist? It seems pedantic to try to convince a single pool operator to accept meta-coin multisigs, and frankly its a bit overblown to call this "censorship".

(I'd say) Leave that pool alone, if we hit enough of a volume to warrant a discussion between operators about being "spam" perhaps then we should worry about our transactions being filtered out.

This seems like premature optimization rather than a actual, pressing problem that needs to be addressed.

ghost · Sep 6, 2014

I think @petertodd hit the point exactly:

Honestly, that Eligius is the only pool blocking stuff is telling you know... 
The other 95% of miners realise that politicising transaction acceptance makes 
Bitcoin less valuable for everyone. Equally, this isn't a cat and mouse game,
there's a tiny number of moves in the game that make sense, and you can
very quickly force miners into adopting heavy-weight blacklists. Heck, that 
95% aren't even adopting light-weight blacklists.

Why even spin cycles for a single pool who cares to enforce a blacklist? It seems pedantic to try to convince a single pool operator to accept meta-coin multisigs, and frankly its a bit overblown to call this "censorship".

(I'd say) Leave that pool alone, if we hit enough of a volume to warrant a discussion between operators about being "spam" perhaps then we should worry about our transactions being filtered out.

This seems like premature optimization rather than a actual, pressing problem that needs to be addressed.

I'd rather keep this github issue on track and not digress to philosophy.

Whether we "should" send Master Protocol transaction, and whether miners and pools "should" filter them out or not, pre-supposes an objective moral compass that you can measure against. I'd rather not go there.

The facts as I see them are:

There are people who believe Master Protocol transactions are in fact "legitimate" Bitcoin transactions. These people will broadcast these transactions if they find them beneficial.
There are people who believe Master Protocol transactions are spam, and will try to block them.
Sooner or later, the number of people in group #2 may increase significantly, and we should be prepared for that and try our best to make their job harder. It is the core mission statement of the Mastercoin Foundation to develop the Master Protocol and to ensure its successful operations.
Of course, the timing for when such obfuscation actions should be implemented is up for discussion. I never meant to suggest that right now it's a super high priority task, just that we should be aware of that and include that in our roadmap.

CC @DavidJohnstonCEO as well.

ripper234 · Sep 6, 2014

I'd rather keep this github issue on track and not digress to philosophy.

Whether we "should" send Master Protocol transaction, and whether miners and pools "should" filter them out or not, pre-supposes an objective moral compass that you can measure against. I'd rather not go there.

The facts as I see them are:

There are people who believe Master Protocol transactions are in fact "legitimate" Bitcoin transactions. These people will broadcast these transactions if they find them beneficial.
There are people who believe Master Protocol transactions are spam, and will try to block them.
Sooner or later, the number of people in group #2 may increase significantly, and we should be prepared for that and try our best to make their job harder. It is the core mission statement of the Mastercoin Foundation to develop the Master Protocol and to ensure its successful operations.
Of course, the timing for when such obfuscation actions should be implemented is up for discussion. I never meant to suggest that right now it's a super high priority task, just that we should be aware of that and include that in our roadmap.

CC @DavidJohnstonCEO as well.

Your "fact" #3 is not a fact, but a "moral compass"-based (as you put it) judgement. With facts 1 and 2, it seems obvious the appropriate course of action is for people in group 1 to mine MC transactions, and group 2 to not mine them. Forcing group 2 to serve the interests of group 1 is a (clearly bad) idea, not a fact. Changing the Master Protocol to be sane so that fewer people are in group 2, as @dexX7 suggested, makes much more sense from the perspective of developing the protocol to ensure its success.

luke-jr · Sep 6, 2014

Your "fact" #3 is not a fact, but a "moral compass"-based (as you put it) judgement. With facts 1 and 2, it seems obvious the appropriate course of action is for people in group 1 to mine MC transactions, and group 2 to not mine them. Forcing group 2 to serve the interests of group 1 is a (clearly bad) idea, not a fact. Changing the Master Protocol to be sane so that fewer people are in group 2, as @dexX7 suggested, makes much more sense from the perspective of developing the protocol to ensure its success.

What amusing about all this discussion about "forcing" people, is that in any other context Luke-Jr and most other devs are all for ensuring that all transactions are indistinguishable to ensure that miners can't pick and choose which ones they mine. Hell, Eligius was (is?) preventing peopel from re-using addresses specifically to encourage people to make their transactions indistinguishable from each other. But when it comes to Mastercoin, suddenly they're angry when we propose doing the obvious thing: ensuring that our transactions are as indistinguishable as possible from any other so they can't be easily blocked.

Anyway, in a decentralized system it's silly to get hung up on discussions of "morality" - what matters is what our goals are and how best to achieve them.

petertodd · Sep 7, 2014

What amusing about all this discussion about "forcing" people, is that in any other context Luke-Jr and most other devs are all for ensuring that all transactions are indistinguishable to ensure that miners can't pick and choose which ones they mine. Hell, Eligius was (is?) preventing peopel from re-using addresses specifically to encourage people to make their transactions indistinguishable from each other. But when it comes to Mastercoin, suddenly they're angry when we propose doing the obvious thing: ensuring that our transactions are as indistinguishable as possible from any other so they can't be easily blocked.

Anyway, in a decentralized system it's silly to get hung up on discussions of "morality" - what matters is what our goals are and how best to achieve them.

Oh, and re: merge mining, remember this is the same Luke-Jr who used Eligius to attack the merge-mined Coiledcoin at no cost... Merge-mining just isn't secure.

petertodd · Sep 7, 2014

Oh, and re: merge mining, remember this is the same Luke-Jr who used Eligius to attack the merge-mined Coiledcoin at no cost... Merge-mining just isn't secure.

Quit with the bad logic and FUD @petertodd

luke-jr · Sep 7, 2014

Quit with the bad logic and FUD @petertodd

I think its best to close this now, before the thread is engulfed in the fires of trollbait&flamewar.

If this issue still warrants a discussion, it would probably be best to open a new issue with a small proposal keep the conversation going forward.

ghost · Sep 7, 2014

I think its best to close this now, before the thread is engulfed in the fires of trollbait&flamewar.

If this issue still warrants a discussion, it would probably be best to open a new issue with a small proposal keep the conversation going forward.

Changing the Master Protocol to be sane so that fewer people are in group 2 ...

You mentioned it's spam and pollution several times, but I sort seem to have missed the underlying reason to begin with?

I think its best to close this now, before the thread is engulfed in the fires of trollbait&flamewar.

Hehe, this outcome was pretty obvious right from the start, given how loaded the topic is. But why not keep getting some alternative opinions? I mean, I don't necessarily agree with the points or claims made here, but it's certainly interesting and at worst a waste of time, at best it can yield an useful insight.

dexX7 · Sep 7, 2014

Changing the Master Protocol to be sane so that fewer people are in group 2 ...

You mentioned it's spam and pollution several times, but I sort seem to have missed the underlying reason to begin with?

I think its best to close this now, before the thread is engulfed in the fires of trollbait&flamewar.

Hehe, this outcome was pretty obvious right from the start, given how loaded the topic is. But why not keep getting some alternative opinions? I mean, I don't necessarily agree with the points or claims made here, but it's certainly interesting and at worst a waste of time, at best it can yield an useful insight.

Re: Eligius was (is?) preventing peopel from re-using addresses

This patch was disabled shortly after it was implemented due to some internal issues, mainly the fact that Eligius currently reuses addresses...

Re: Merge-mining just isn't secure

It's only not secure if no one supports what is available for merged mining in the first place (ie, crappy scamcoins with no purpose that no one actually gives a crap about). The top merge-mined coins (namecoin, ixcoin, devcoin) I'm pretty sure are well secured against 51% attacks at this point, for example, with difficulties in the 10s of billions.

If MasterCoin is indeed as useful and popular as everyone here seems to think it is/like it to be, then getting merged mining adoption would be a piece of cake.

In all honesty, this type of thing is best done on it's own chain, which does in fact solve the problem this issue is about in the first place.

wizkid057 · Sep 7, 2014

Re: Eligius was (is?) preventing peopel from re-using addresses

This patch was disabled shortly after it was implemented due to some internal issues, mainly the fact that Eligius currently reuses addresses...

Re: Merge-mining just isn't secure

It's only not secure if no one supports what is available for merged mining in the first place (ie, crappy scamcoins with no purpose that no one actually gives a crap about). The top merge-mined coins (namecoin, ixcoin, devcoin) I'm pretty sure are well secured against 51% attacks at this point, for example, with difficulties in the 10s of billions.

If MasterCoin is indeed as useful and popular as everyone here seems to think it is/like it to be, then getting merged mining adoption would be a piece of cake.

In all honesty, this type of thing is best done on it's own chain, which does in fact solve the problem this issue is about in the first place.

I don't see a need to close this issue.

However, from now on I ask any of our github moderators (myself included) to remove any off-topic responses to this github issue. The topic is not whether Master Protocol should be harder to censor, but rather how to accomplish that. Anything that doesn't promote that objective is off-topic here, and can be discussed on this thread on mastercointalk.org.

ripper234 · Sep 7, 2014

I don't see a need to close this issue.

However, from now on I ask any of our github moderators (myself included) to remove any off-topic responses to this github issue. The topic is not whether Master Protocol should be harder to censor, but rather how to accomplish that. Anything that doesn't promote that objective is off-topic here, and can be discussed on this thread on mastercointalk.org.

FWIW I just got confirmation that Luke-Jr is working for with Austin Hill on the blockstream project, so there is an obvious undeclared conflict of interest here given that the Blockstream project is in direct competition with embedded consensus systems like Mastercoin. It's notable that Austin Hill has been trying to setup deals with large pools and other controllers of hashing power to merge-mine systems using Blockstream's technology as well as get the necessary changes to the Bitcoin protocol adopted by a majority of hashing power.

Obviously I too have a conflict of interest as I'm working for Viacoin, but it would be in their interests for Mastercoin to move to Viacoin, which I currently can't suggest. In any case, having stronger anti-censorship technology available if needed is valuable regardless of what host blockchain an embedded consensus system uses. I could discuss merge-mining more here, but I agree with @ripper234 on the need to stay on topic.

In any case something I haven't mentioned re: censorship resistance is that the less need there is in the protocol for global consensus, the more strongly censorship-resistant the protocol is. We can easily force miners into adopting specific blacklists to censor embedded consensus usages of the Bitcoin blockchain; the larger those blacklists need to be the better off we are. For instance censoring colored coin technology is particularly hard as unless you know that a particular txout is colored there is no way to distinguish it from any other transaction; a blacklist for colored coins will need to dynamically add new issuances every time a new coin is issued. This may be outright impossible if the list of txouts corresponding to an issuance is committed to in a merkle sum tree but not actually published in full. Keeping these blacklists free of false-positives will also be highly difficult, as colored coin transactions frequently mix colored and uncolored coins, the latter of which are part of the freely circulating set of coins. (one of Blockstream
s goals is to replace colored coin technology)

A non-finance example is in certificate transparency, for instance to ensure that you are using the same version of software as everyone else and are not being targetted specifically. Again you can easily force a blacklist to contain all software packages specifically rather than making it possible to blacklist the technology itself by limiting the consensus domain to per-package rather than globally.

Going forward I'd advise Mastercoin to think carefully about when there may exist opportunities to reduce the "global consensus footprint" of the protocol, and such opportunities need not necessarily get in the way of features.

petertodd · Sep 8, 2014

FWIW I just got confirmation that Luke-Jr is working for with Austin Hill on the blockstream project, so there is an obvious undeclared conflict of interest here given that the Blockstream project is in direct competition with embedded consensus systems like Mastercoin. It's notable that Austin Hill has been trying to setup deals with large pools and other controllers of hashing power to merge-mine systems using Blockstream's technology as well as get the necessary changes to the Bitcoin protocol adopted by a majority of hashing power.

Obviously I too have a conflict of interest as I'm working for Viacoin, but it would be in their interests for Mastercoin to move to Viacoin, which I currently can't suggest. In any case, having stronger anti-censorship technology available if needed is valuable regardless of what host blockchain an embedded consensus system uses. I could discuss merge-mining more here, but I agree with @ripper234 on the need to stay on topic.

In any case something I haven't mentioned re: censorship resistance is that the less need there is in the protocol for global consensus, the more strongly censorship-resistant the protocol is. We can easily force miners into adopting specific blacklists to censor embedded consensus usages of the Bitcoin blockchain; the larger those blacklists need to be the better off we are. For instance censoring colored coin technology is particularly hard as unless you know that a particular txout is colored there is no way to distinguish it from any other transaction; a blacklist for colored coins will need to dynamically add new issuances every time a new coin is issued. This may be outright impossible if the list of txouts corresponding to an issuance is committed to in a merkle sum tree but not actually published in full. Keeping these blacklists free of false-positives will also be highly difficult, as colored coin transactions frequently mix colored and uncolored coins, the latter of which are part of the freely circulating set of coins. (one of Blockstream
s goals is to replace colored coin technology)

A non-finance example is in certificate transparency, for instance to ensure that you are using the same version of software as everyone else and are not being targetted specifically. Again you can easily force a blacklist to contain all software packages specifically rather than making it possible to blacklist the technology itself by limiting the consensus domain to per-package rather than globally.

Going forward I'd advise Mastercoin to think carefully about when there may exist opportunities to reduce the "global consensus footprint" of the protocol, and such opportunities need not necessarily get in the way of features.

Here's another good example: OP_RETURN for stealth addresses seems to be relatively well supported politically - trying to block a mechanism that makes Bitcoin more private looks bad. There seems to be consensus that raising the OP_RETURN limit for stealth addresses is worthwhile, for instance to make the limit be 40 bytes + (# of txouts * 8 bytes) to allow for a more efficient encoding of multiple output stealth transactions. The privacy properties of stealth require that encoding to be indistinguishable from applications using OP_RETURN for data, which in turn reduces the cost of encoding data significantly as every, say, P2PKH/P2SH txout encoding ~20 bytes gives you another 8 bytes free. FWIW my blockpop library is able to take advantage of this to more efficiently embed data in transactions.

petertodd · Sep 8, 2014

Here's another good example: OP_RETURN for stealth addresses seems to be relatively well supported politically - trying to block a mechanism that makes Bitcoin more private looks bad. There seems to be consensus that raising the OP_RETURN limit for stealth addresses is worthwhile, for instance to make the limit be 40 bytes + (# of txouts * 8 bytes) to allow for a more efficient encoding of multiple output stealth transactions. The privacy properties of stealth require that encoding to be indistinguishable from applications using OP_RETURN for data, which in turn reduces the cost of encoding data significantly as every, say, P2PKH/P2SH txout encoding ~20 bytes gives you another 8 bytes free. FWIW my blockpop library is able to take advantage of this to more efficiently embed data in transactions.

FWIW, I see no conflict of interest between Blockstream and MasterCoin, nor do those contracting my services have a right to my "interest". My independence in this regard is part of why I only do contracting, never employment. But this FUD of @petertodd 's is truly getting off-topic - I only post this here as a correction.

luke-jr · Sep 8, 2014

FWIW, I see no conflict of interest between Blockstream and MasterCoin, nor do those contracting my services have a right to my "interest". My independence in this regard is part of why I only do contracting, never employment. But this FUD of @petertodd 's is truly getting off-topic - I only post this here as a correction.

(Deleted one off-topic comment by Luke).

ripper234 · Sep 8, 2014

(Deleted one off-topic comment by Luke).

Re: keeping non-transactional data off-chain, I do see the point being made, and I think with PT's comments about OP_RETURN, it seems that a probable way out is to open the possibility of some hybridized scheme where the core financial data is stored in an OP_RETURN, with some off-blockchain reference to Asset details and other various metadata that isn't financial in nature. IIRC Colored coins does something like this, via linking to custom URLs with asset information (on some privately hosted server). I can see this being considerably less controversial than stuffing obfuscated data in pubkeys in attempts to dodge the mining police

ghost · Sep 8, 2014

Re: keeping non-transactional data off-chain, I do see the point being made, and I think with PT's comments about OP_RETURN, it seems that a probable way out is to open the possibility of some hybridized scheme where the core financial data is stored in an OP_RETURN, with some off-blockchain reference to Asset details and other various metadata that isn't financial in nature. IIRC Colored coins does something like this, via linking to custom URLs with asset information (on some privately hosted server). I can see this being considerably less controversial than stuffing obfuscated data in pubkeys in attempts to dodge the mining police

Not sure why Luke's post was deleted for being considered off topic... simply is discussing alternative methods, and actually agrees with removing the 1Exodus output...
Original post: http://pastebin.com/tX46xgZX

wizkid057 · Sep 8, 2014

Not sure why Luke's post was deleted for being considered off topic... simply is discussing alternative methods, and actually agrees with removing the 1Exodus output...
Original post: http://pastebin.com/tX46xgZX

Not sure about the competing supply argument nor the separate blockchain one Luke; Mastercoin uses Bitcoin's blockchain for many of the same reasons other 2.0 projects do (XCP,CC,etc.), security &/or stability

Edit: replying to the wizkid057's pastebin, thanks

ghost · Sep 8, 2014

Not sure about the competing supply argument nor the separate blockchain one Luke; Mastercoin uses Bitcoin's blockchain for many of the same reasons other 2.0 projects do (XCP,CC,etc.), security &/or stability

Edit: replying to the wizkid057's pastebin, thanks

@faizkhan00 MasterCoin does not gain any security or stability from using Bitcoin's blockchain.

luke-jr · Sep 8, 2014

@faizkhan00 MasterCoin does not gain any security or stability from using Bitcoin's blockchain.

Earlier post that got lost:

@dexX7 From my understanding, there are two ways I, and probably anyone who considers the blockchain to have a social agreement/contract, consider it spam:

The unnecessary 1Exodus output indicating it is a Mastercoin transaction.
The abuse of multisig and p2pkh outputs to convey data rather than OP_RETURN.
Some of the data may be non-financial/transactional in nature.
Basically anything that isn't a pubkey shouldn't be scripted as a pubkey, anything that isn't a hash shouldn't be scripted as a hash, and anything that isn't financial data (not sure if this exists, but it was implied in this conversation earlier that it did) shouldn't appear directly in the blockchain.

There is also an argument that MasterCoin is competing in supply (one cannot convert more bitcoins to mastercoins or vice-versa) and many users may not wish to support it when they store/validate the blockchain. I don't hold to this argument myself, but it may be worth considering possible ways to satisfy it.

Not per se related to spam, 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. It does benefit from having bitcoin miners securing it, but that can also be had by supporting some form of merged mining, which is just as safe if those same miners freely support it.

I agree this thread should be closed as "invalid".

luke-jr · Sep 8, 2014

Earlier post that got lost:

@dexX7 From my understanding, there are two ways I, and probably anyone who considers the blockchain to have a social agreement/contract, consider it spam:

The unnecessary 1Exodus output indicating it is a Mastercoin transaction.
The abuse of multisig and p2pkh outputs to convey data rather than OP_RETURN.
Some of the data may be non-financial/transactional in nature.
Basically anything that isn't a pubkey shouldn't be scripted as a pubkey, anything that isn't a hash shouldn't be scripted as a hash, and anything that isn't financial data (not sure if this exists, but it was implied in this conversation earlier that it did) shouldn't appear directly in the blockchain.

There is also an argument that MasterCoin is competing in supply (one cannot convert more bitcoins to mastercoins or vice-versa) and many users may not wish to support it when they store/validate the blockchain. I don't hold to this argument myself, but it may be worth considering possible ways to satisfy it.

Not per se related to spam, 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. It does benefit from having bitcoin miners securing it, but that can also be had by supporting some form of merged mining, which is just as safe if those same miners freely support it.

I agree this thread should be closed as "invalid".

It does sit on top of the most successful proof-of-work based coin in existence today, and I think that some of the reliability in terms of hashing power can be explained in terms of stability (ie. there is some guarantee that can be made my transactions won't disappear tomorrow, because this other decentralized system works), the security claim may be more shaky (can't think of a good relation of how we're really leveraging the underlying crypto, for ex.) but we do use SHA256 for obfuscation :X

ghost · Sep 8, 2014

It does sit on top of the most successful proof-of-work based coin in existence today, and I think that some of the reliability in terms of hashing power can be explained in terms of stability (ie. there is some guarantee that can be made my transactions won't disappear tomorrow, because this other decentralized system works), the security claim may be more shaky (can't think of a good relation of how we're really leveraging the underlying crypto, for ex.) but we do use SHA256 for obfuscation :X

@wizkid057 There is strong agreement among the Mastercoin team that Mastercoin is most secure on the Bitcoin blockchain; discussing that topic is off topic here and distracts from on-topic discussion on how to best avoid censorship.

petertodd · Sep 8, 2014

@wizkid057 There is strong agreement among the Mastercoin team that Mastercoin is most secure on the Bitcoin blockchain; discussing that topic is off topic here and distracts from on-topic discussion on how to best avoid censorship.

I am in favor of a blockpop-based approach though, if it ends up reducing the overall angst about storing non-financial data. It might be a better use-case for an asset-driven system anyway- I'm wondering if there's a good example on how that might work in practice?

ghost · Sep 8, 2014

I am in favor of a blockpop-based approach though, if it ends up reducing the overall angst about storing non-financial data. It might be a better use-case for an asset-driven system anyway- I'm wondering if there's a good example on how that might work in practice?

@petertodd Consensus or not, utilizing its own block chain effectively eliminates any real or perceived censorship, so is in fact not off topic as it is an actual solution regardless of whether or not you or the team summarily rejects it for whatever reason.

Also, @petertodd, am I correct in my understanding that your intention is to still encode arbitrary data into public key/hash portions of a txout as well as using OP_RETURN for more data? That seems to be an abuse of that particular feature and certainly does not help the anti-censorship portion since I don't believe any legitimate transaction would do this...

wizkid057 · Sep 8, 2014

@petertodd Consensus or not, utilizing its own block chain effectively eliminates any real or perceived censorship, so is in fact not off topic as it is an actual solution regardless of whether or not you or the team summarily rejects it for whatever reason.

Also, @petertodd, am I correct in my understanding that your intention is to still encode arbitrary data into public key/hash portions of a txout as well as using OP_RETURN for more data? That seems to be an abuse of that particular feature and certainly does not help the anti-censorship portion since I don't believe any legitimate transaction would do this...

@wizkid057 An attack on said blockchain is its own form of censorship; embedded within Bitcoin you are forced to attack all of Bitcoin.

am I correct in my understanding that your intention is to still encode arbitrary data into public key/hash portions of a txout as well as OP_RETURN? That seems to be an abuse of that particular feature and certainly does not help the anti-censorship portion since I don't believe any legitimate transaction would do this...

Distinguishing "arbitrary data" from pubkeys and hashes is easy to make impractical, or even impossible, with the encodings blockpop uses. That's the whole point of this discussion: ensuring we're doing our best job to make distinguishing Mastercoin transactions from other types of transactions impractical.

petertodd · Sep 8, 2014

@wizkid057 An attack on said blockchain is its own form of censorship; embedded within Bitcoin you are forced to attack all of Bitcoin.

am I correct in my understanding that your intention is to still encode arbitrary data into public key/hash portions of a txout as well as OP_RETURN? That seems to be an abuse of that particular feature and certainly does not help the anti-censorship portion since I don't believe any legitimate transaction would do this...

Distinguishing "arbitrary data" from pubkeys and hashes is easy to make impractical, or even impossible, with the encodings blockpop uses. That's the whole point of this discussion: ensuring we're doing our best job to make distinguishing Mastercoin transactions from other types of transactions impractical.

@faizkhan00 Basically OP_RETURN was originally written to embed up to 80 bytes. This was publicly announced and known for months. Just prior to release it was reduced to 40 bytes without any discussion with anyone intending to use it - e.g. Counterparty. Heck, that reduction also screwed up my plans with stealth addresses, which was going to just just over 40 bytes.

petertodd · Sep 8, 2014

@faizkhan00 Basically OP_RETURN was originally written to embed up to 80 bytes. This was publicly announced and known for months. Just prior to release it was reduced to 40 bytes without any discussion with anyone intending to use it - e.g. Counterparty. Heck, that reduction also screwed up my plans with stealth addresses, which was going to just just over 40 bytes.

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.

ghost · Sep 8, 2014

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.

@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.

petertodd · Sep 8, 2014

@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.

@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?

wizkid057 · Sep 8, 2014