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