public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Crypto.Press" <crypto@crypto.press>
To: bitcoin-dev@lists.linuxfoundation.org
Subject: [bitcoin-dev] Diminishing Signaling Returns
Date: Sat, 15 Apr 2017 07:51:58 -0600	[thread overview]
Message-ID: <CAPMASjto+y3SpaBuJPLb2XUrZm8aWu0QWEEVHN6PDherrBeuWg@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 3183 bytes --]

Hi everyone, I have never posted to the list and do not commit the project
proper so I do apologize if this is not even possible in advance.

Examining bitcoin's past and contrasting it with other social contracts and
even physical phenomena it would seem that as bitcoin continues to age
entropy will continue to grow.

The scaling debate would seem to be a fore-bearer of this.

One main contributor to this in bitcoin is as people/businesses become
involved and vested into their perspective it becomes minted in their
identity. The idea that this will somehow decrease as the user base grows
with more perspectives and use-cases seems counter-intuitive so I propose a
potential way to combat entropy in a divided community.

Diminishing Signaling Returns

Since entropy is the increase of disorder in a system (the various scaling
solutions for this idea) and measuring via resource is not trustless, we
need a mechanism to essentially counteract entropy while not relying on
game-able metrics.

What if we applied a rate of diminishing returns on signaling in BIP9?
Something along the lines of:

Every (X) block signaled The actual signal value diminishes from a 1 signal
1 block to a fraction of a signal per block found after a burn in period of
some reasonable time to ensure a majority upgrade(this could even be
effected after the timeout currently apart of BIP9 for ease of
implementation?).

Some thoughts

   - The pools that find more blocks would lose the ability to block the
   network without taking an economical hit splitting up their hash power as
   signaling was never intended to be a voting mechanism (to my knowledge).
   - The longer that the signaling took place would eventually run a larger
   pool's signaling influence to 0 first. This creates a balancing effect
   between hash rate & #of miners actually signaling ready.
   - Gamesmanship of this system would be visible to the community at
   large. e.g. pools hash rate/blocks found jumps or declines significantly in
   a short time frame, or specific time frame (when pools influence begins to
   decline).
   - creates multiple economic incentives for the mining community to be on
   a similar page
   - this as a feature of a soft forks greatly diminishes politics becoming
   a factor in the future.


unfortunately, this itself would require a soft fork if I am correct?


Acceptance then becomes the question.
While bitcoin has proven to be highly resilient, stagnation has destroyed
many systems/businesses and if the current state of affairs is any measure
it would stand to reason that in the future this will only worsen. Taking
this action could be a solution to that stagnation.  So, it would be in
everyone's best long-term interest to support a continually evolving
bitcoin and would allow parties with ideas that differ the time and
resources to fork in a more responsible manner without devoting their
resources to politics. However, everyone would still have the time to voice
their opinions during the burn-in/timeout period and of course before any
code was actually included through technical consensus.

Thoughts?

Regards,
Benjamin George
Crypto.Press http://crypto.press

[-- Attachment #2: Type: text/html, Size: 5472 bytes --]

                 reply	other threads:[~2017-04-15 14:15 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAPMASjto+y3SpaBuJPLb2XUrZm8aWu0QWEEVHN6PDherrBeuWg@mail.gmail.com \
    --to=crypto@crypto.press \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox