From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 232964A4 for ; Sat, 15 Apr 2017 14:15:34 +0000 (UTC) X-Greylist: delayed 00:23:33 by SQLgrey-1.7.6 Received: from ter.terralibrecity.com (ter.terralibrecity.com [216.172.177.108]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 50B72144 for ; Sat, 15 Apr 2017 14:15:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=crypto.press; s=default; h=Content-Type:To:Subject:Message-ID:Date:From: MIME-Version:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=e4kSpudbkmSkdwm1SPlCwIYd+mjootFNykHYT3l+V+w=; b=b3Syf7KkckoHMxQz8rbu0Kmweq yBP1yJWKt/USLeGcR6XaNzc/n2LekAq1hEZV4DAwvRQd5i54e1rzTzQCN84JbONlhAoyCfJ9FN6KB CwAVF8/Ct2doPTtgXMdUKAcnOWZ/u16lDE+3XqyV5AYO3dw22Vq7o3RQOQsHoMNOB/vzhT3KnaKr5 up/3zQoVWXQ8L+vp5PceQrPFBQ50bG8rXo1mIsJ9IaePujlGpwWzmaBvqB2K9ppeK2jrryNCeb9q6 opTXvGR106ZGQTYu8mziq5yOvEMY34XP2mfFJ/FV+/iQA7LBn4x3STJF+gL6P8Cqh7TiJYwdTKi6S f2GIHUxQ==; Received: from mail-ua0-f180.google.com ([209.85.217.180]:34888) by ter.terralibrecity.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from ) id 1czO7L-000568-GO for bitcoin-dev@lists.linuxfoundation.org; Sat, 15 Apr 2017 08:51:59 -0500 Received: by mail-ua0-f180.google.com with SMTP id f10so36206740uaa.2 for ; Sat, 15 Apr 2017 06:51:59 -0700 (PDT) X-Gm-Message-State: AN3rC/77ceXUFxjD47nYJ5o7PhsdTefQw3BWNZ2wB6S38CTtl4E8sQpi HpoSj9pi6TD/jCOwiHbICcho+ImpCQ== X-Received: by 10.176.65.196 with SMTP id 62mr6172268uap.175.1492264318677; Sat, 15 Apr 2017 06:51:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.37.69 with HTTP; Sat, 15 Apr 2017 06:51:58 -0700 (PDT) From: "Crypto.Press" Date: Sat, 15 Apr 2017 07:51:58 -0600 X-Gmail-Original-Message-ID: Message-ID: To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary=001a114fb3a4a03ed1054d34dc6d X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ter.terralibrecity.com X-AntiAbuse: Original Domain - lists.linuxfoundation.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - crypto.press X-Get-Message-Sender-Via: ter.terralibrecity.com: authenticated_id: crypto@crypto.press X-Authenticated-Sender: ter.terralibrecity.com: crypto@crypto.press X-Source: X-Source-Args: X-Source-Dir: X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Sun, 16 Apr 2017 20:09:52 +0000 Subject: [bitcoin-dev] Diminishing Signaling Returns X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Apr 2017 14:15:34 -0000 --001a114fb3a4a03ed1054d34dc6d Content-Type: text/plain; charset=UTF-8 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 --001a114fb3a4a03ed1054d34dc6d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi everyone, I have never posted to the list and do= not commit the project=C2=A0proper=C2=A0so I do apologize if this is= not even possible in advance.=C2=A0

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

The scaling debate would see= m to be a fore-bearer of this.=C2=A0

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

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

What if we applied a rate of diminishing= returns on signaling in BIP9? Something along the lines of:=C2=A0
Every (X) block signaled The actual signal value diminishes from a 1 sign= al 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 ef= fected after the timeout currently apart of BIP9 for ease of implementation= ?).<= /span>

Some thoughts
  • The pools that find more blocks would lose the ability to block the=20 network without taking an economical hit splitting up their hash power=20 as signaling was never intended to be a voting mechanism (to my=20 knowledge).
  • The longer that the signaling took place would = eventually run a larger pool's signaling influence to 0 first. This cre= ates a balancing effect between hash rate & #of miners actually signali= ng ready.=C2=A0
  • Gamesmanship of this system would be visible to the community at large. e.g. pools=20 hash rate/blocks found jumps or declines significantly in a short time=20 frame, or specific time frame (when pools influence begins to decline).=C2=A0
  • 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.

u= nfortunately, this itself would require a soft fork if I am correct?=C2=A0


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

Thoughts?=C2=A0

Regards,
Benjamin Geor= ge
Crypto.Press http://crypto.press
--001a114fb3a4a03ed1054d34dc6d--