I agree with Greg, 0 quantification of what defines success has been provided for the generally expressed intention of reducing spam. If one admits any decentralized system that allows user-derived public keys / hashes fundamentally includes the ability to embed spurious data in place of those values, eliminating the spamming of those values is effectively impossible. That leaves us with the question: given the goal is simply 'reduction of spam', what defines success and what are the limiting principles? If success is 'reduce spam as much as possible', that would implicitly mean one should remove virtually all OP codes and leave Bitcoin with only basic send/receive that utilizes as few public keys and hashes as possible. Through this rational, empirical lens, I just don't see how this PR's seemingly arbitrary modifications of Bitcoin's protocol rules 1) actually reduce spam (likely will just result in spammers using different constructions), and 2) achieve mitigation of the hazy legal concerns that were a primary driver of this initiative.
Can you please quantify what amounts/measurables you are targeting, and explain why this PR will achieve reductions to those level, such that they deliver on desired outcomes? Please connect whatever realistically achievable level reductions you believe will occur to the real world effects you believe they will deliver, such as "If we can just ensure no block can contain more than X bytes of spam, the Three-Letter Agency Y will not come after us because Z rule/limit/law/regulation says so". I am just providing an example of linking action to outcome delivery, so if you don't like that one, please provide whatever you feel best conveys it. Would you then agree that this proposal will fail at its stated purpose, particularly with respect to concerns about potentially 'unlawful' material? As that concern as expressed has a threshold of "any at all" and could just as well be performed via a "less commonly abused" path? Would you also agree the same for essentially all other forms-- that they'd simply made a few line of code changes and then evade these restrictions? In light of that, how would the very real and significant reductions in intentional functionality (such as efficient "few of dozens" multisigs or other such constructs) be justified? How could the confiscation risk be justified? How could the deployment costs be justified? How could the "policy risk" be justified? (E.g. that bitcoin could be driven or forced in to an endless sequences of 'update' blocking actions, each carrying its own risk and disruptions) Although your description of changes is vague and it's not possible to tell for sure without seeing the actual updates-- I don't think your suggested revisions will move your proposal off from having essentially zero risk of adoption, and if it were adopted (which I think is unlikely) I think it's a certainty that there would be a countering fork to continue a Bitcoin without these poorly justified (even essentially useless) restrictions. -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/c385373b-a307-43b3-b958-fadb5866e3d9n%40googlegroups.com.
