[Bitcoin-dev-moderation] [bitcoin-discuss] Your message to bitcoin-dev awaits moderator approval

[Ryan Grant]

Peter_R, you were moderated because your summary and content are
self-contradicting, and because your hypothesis does not advance the
understanding of a reasonable practitioner subscribed to bitcoin-dev.

You were held to a higher standard for advancing the understanding of
a reasonable practitioner subscribed to bitcoin-dev, because you're
not writing in the clear realm of necessary code changes, or
presenting a BIP clarifying and improving a known deficiency in the
protocol.

For those of you following along at home, the following errors were made:

  - Bitcoin-dev moderators are accepting moderation communication on
    their personal email identities, and communicating with moderated
    posters directly, rather than acting as a single inbox-persona
    (with authenticated identity per moderator used in headers or
    footers), sending all communication through a publicly-logged
    channel.  These lapses allowed Peter_R to troll with a
    he-said-she-said tactic.

    Weakly corroborating the moderators' story, Peter_R did submit a
    slightly modified post, after the bulk of the delay:

      https://lists.ozlabs.org/pipermail/bitcoin-dev-moderation/2016-February/000078.html
      https://lists.ozlabs.org/pipermail/bitcoin-dev-moderation/attachments/20160222/42ecb382/attachment.mht

    Peter_R's original post was here:

      https://lists.ozlabs.org/pipermail/bitcoin-dev-moderation/2016-February/000077.html
      https://lists.ozlabs.org/pipermail/bitcoin-dev-moderation/attachments/20160221/166d95fd/attachment.mht

  - A soft-rules-level (rather than clear-rules-level) reply tactic -
    of making someone wait - was used, once personal complaints to
    moderators began.  Moderator duty should never appeal to a
    person's capacity for reasonable understanding.  It is a realm
    where responses are either due or not due.  In order for a
    response to not be due, Peter_R should have already received a
    reply that could be tracked publicly.  See the following point.

  - The burden of moderation should include saying why something
    doesn't fit the list.

    Peter_R submitted a post with commonly-understood title and
    "TL;DR" conclusion not matching its own content.  It also does not
    advance the understanding of a reasonable practitioner of
    bitcoin-dev.  The non-matching summaries and content can be used
    as a wedge for creating misunderstanding in forums with less
    tenacity in following along.

    Specifically, he calls the hard-fork requirement to upgrade by a
    certain date a symmetric "relaxation" analogous to the eventual
    need to upgrade after a soft-fork, so as not to rely on miner
    validation.  On a technical level, to reasonable practitioners,
    this perspective is useless.  If one of these responsibilities
    fails, it has immediate and severe consequences (such as risking
    loss of funds if attempting a transaction after a hard-fork flag
    day), and the other uses the full strength of both mining and the
    validating network to shield the node operator from immediate
    consequences.

    The title, summary, and content are ridiculous in their level of
    cognitive dissonance.  Quoting consecutive sentences from the text
    (which is in both versions submitted, as linked above):

      > However, [non-mining nodes] CANNOT continue to enforce the old
      > rule set [after the fork], without the risk of forking
      > themselves off the network.
      >
      > **TL/DR**: The main point is that from the non-mining nodes'
      > perspective, synchronous coordination is not required for
      > either soft- or hard-forking changes.

    Since the moderators do not explain the reasoning for moderating
    his content, Peter_R scores an emotional victory, in crying
    censorship.  Perhaps he intends to parlay it into more character
    assassination, as commonly encouraged on /r/btc, amongst those
    ignorant or counter-incentivized enough to accept such stories
    blindly.


  - Moderation policy should explicitly reference a notion of a
    penalty box.  Every human moderating is going to be thinking about
    certain identities with additional suspicion, after events like
    these.  Reasoning is more defensible (in our adversarial setting)
    if a penalty flag was publicly set after prior moderated content.

  - Ozlabs is hosting the records of moderation.  There is no
    indication that hashes are being recorded in an irreversible
    blockchain.  Thus, even the moderation database could be
    questioned.

I hope others find it helpful to name and dissect the deficiencies.

Without the above proof available, it may be easy to believe Peter_R's
false timeline of the moderation events:

  On Sun, Feb 21, 2016 at 10:05 PM, Peter R [via bitcoin-discuss]
  wrote:
  > I am hearing that you thought my **original email** on forking
  > theory

      [Emphasis added.  Link removed.  Here Peter_R links externally
      to content from the **second** submission, the one including
      image links, **not the original ASCII-only version**, which I
      have linked to above.]

 > was a "shitpost" and that you chose to ignore it [...]

He has first probed for a spot of weak debunking effort (which
this post hopefully mitigates), and then feels safe conflating the
following events:

  - he switches the post which Bryan called a shitpost to one of
    his "technical" submissions, even though Bryan was, at that
    point, clearly referring to his complaints, saying "you start
    shitposting about the rejection"; and

  - he claims that Bryan made the original technical post
    wait, when the weakly-corroborated facts indicate that Peter_R
    asked the moderators to hold his post.

If you are reading this, you may be thinking this energy level for
debunking is unsustainable, and wondering if moderation can be
decentralized.  It has been proposed before, ages ago, and I am
involving myself in projects determined to try it again.