Make Master Protocol harder to censor #248
Comments
|
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. |
ripper234
changed the title
|
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. |
|
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. |
|
As most actual mining is done by pool operators, the two groups are the same. 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? |
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 "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? |
|
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.
Metadata sure, but remember that you can't replace the core data with off-chain stuff without a severe reduction in security.
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.
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 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?
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 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.
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. |
|
I think @petertodd hit the point exactly: 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:
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. |
|
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. |
|
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. |
You mentioned it's spam and pollution several times, but I sort seem to have missed the underlying reason to begin with?
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. |
|
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 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. |
|
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). |
|
@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. |
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 |
|
@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). |
|
@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... |
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. |
|
@petertodd wrote: 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 |
|
@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. |
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. |
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? |
|
@petertodd a dust output to 1Exodus for every transaction certainly is not UTXO neutral... nor in support of anti-censorship |
|
@faizkhan00 The regular transactions pay a fee to be processed and stored. OP_RETURN txns should be no different, really. |
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.
Those dust outputs get periodically spent, and anyway, will likely get removed from the protocol eventually for better anti-censorship properties as discussed above. |
|
@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. |
|
@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. |
|
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. |
|
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. ;) |
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 ...
... 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'd name easier Bitcoin <> Mastercoin interaction, but that's probably a huge topic on it's own. What I stumbled upon by the way: Allegedly secure DHT with rich feature set at beta stage. |
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.
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.
After visiting Maidsafe in person I don't have any reason to think they know what they're doing with respect to consensus security. |
|
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. |
|
@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. |
|
Whats the current expense of one OP_RETURN transaction? The cost of two can't be prohibitive... |
|
@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 |
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. |
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. |
|
@faizkhan00 There's a IsStandard() limit of one OP_RETURN txout per transaction; they don't cost anything beyond standard tx fees.
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. |
|
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. |
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? |
|
After re-reading the thread, a few more notes:
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]):
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.
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. |
|
Hello,
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... |
|
Sort of related:
|
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
The text was updated successfully, but these errors were encountered: