Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 0A3C7C26 for ; Fri, 3 Nov 2017 01:02:38 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f172.google.com (mail-qk0-f172.google.com [209.85.220.172]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id ED7634CE for ; Fri, 3 Nov 2017 01:02:36 +0000 (UTC) Received: by mail-qk0-f172.google.com with SMTP id x82so1495370qkb.12 for ; Thu, 02 Nov 2017 18:02:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=niftybox-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4RZ0oS7Wg4LwHD+L6veVxdAmOG4uPeZDaA1qMN7QAeQ=; b=1mxShVQ/f9eMphpsxfdpecBYdJE43BthyTo8uu9AGX0rg0+k+hYlIKwJaLZL4z3Pfc 6VrjnP4ZFvsZ2QcGWdJjbQQOcToQ8iYMeZcisr2bCHJ7HtR7UYB69Bxc3lY95dCXIn6R vwyAPG5AkozxqYw7/hcAcrE6JDEW0FkLjGBi1NJsZ7o0VyeHRqXCLoznhd25CNKUgUeD PUt5v1y7+Ioy+ARfHYAPsEyVfOgP5jmc1sUJNb+k2vSzIsKNo5wynj9KQN49aM/QQ9J8 C5GQq+6Wwa27fszeHf/HSi4z9emHzRzv0cn2huPNw4FcowsgrxdRRWtn26TtQjfvQNqp cmWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4RZ0oS7Wg4LwHD+L6veVxdAmOG4uPeZDaA1qMN7QAeQ=; b=qY/RVvDvkMqlLuCDoPz5uzJBCmTj+JSlDEIe7roAlAPE1OOKJxTOoKPbWFeuIsZzdK +c6WUiGjgmOUwqT0i7zN6a0kgoUwS/NXJPozR1aJ6339SRzLKUvBnCDSyMjFlszqr98D ma364tIJlbavj5Raz+tpOXgwKNs/O2ivBuRSwGxB42x+uvvJxe2XpXeXf1znAfmuiCqm ZAyP8oqzD3K2MnUu1lHjUN1SglnEVMCEYZW19pHAqsqDyXjWdjL8AK90S/QRl0wQq8gK 3VmPWODscZAO8CszdSF8xbb+/WDh5og0mq8M3D5fcTHTEBBJT2eICho7N5rD/rpfJk2w TfsA== X-Gm-Message-State: AMCzsaVdVzEbF01tbOtvtkWFFOJ2xfEcAw9LHsOjDaR2yMkFaqPOUfXd QAAd6rLoVFSw43ptDN/ooVtUJErmB7HucVy0ybRZ8A== X-Google-Smtp-Source: ABhQp+TLIdtaT5SohLYv3Qw4dBGN5uHtT8ORYnxIlcBk1xzlF+/l/yp+ynlNXE4lkCcZPrxSEFOPuaPcBY2kFw8N/PI= X-Received: by 10.55.175.132 with SMTP id y126mr7737140qke.45.1509670955842; Thu, 02 Nov 2017 18:02:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Devrandom Date: Fri, 03 Nov 2017 01:02:25 +0000 Message-ID: To: Tao Effect Content-Type: multipart/alternative; boundary="94eb2c0629360d15e6055d09a96a" X-Spam-Status: No, score=0.5 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=disabled version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Fri, 03 Nov 2017 01:40:50 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Introducing a POW through a soft-fork 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: Fri, 03 Nov 2017 01:02:38 -0000 --94eb2c0629360d15e6055d09a96a Content-Type: text/plain; charset="UTF-8" I am also concerned. However, this proposal allows two POWs to coexist and allows for gradual transitions. This is hopefully a less disruptive approach since it allows cooperative miners to migrate over time. And of course, as a soft-fork it keeps backwards compatibility with existing software. On Thu, Nov 2, 2017 at 4:55 PM Tao Effect wrote: > Just going to throw in my support for a POW change, not any particular > implementation, but the idea. > > Bitcoin is technically owned by China now. That's not acceptable. > > - Greg > > -- > Please do not email me anything that you are not comfortable also sharing with > the NSA. > > On Oct 31, 2017, at 10:48 PM, Devrandom via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > Hi all, > > Feedback is welcome on the draft below. In particular, I want to see if > there is interest in further development of the idea and also interested in > any attack vectors or undesirable dynamics. > > (Formatted version available here: > https://github.com/devrandom/btc-papers/blob/master/aux-pow.md ) > > # Soft-fork Introduction of a New POW > > ## Motivation: > > - Mitigate mining centralization pressures by introducing a POW that does > not have economies of scale > - Introduce an intermediary confirmation point, reducing the impact of > mining power fluctuations > > Note however that choice of a suitable POW will require deep analysis. > Some pitfalls include: botnet mining, POWs that seem ASIC resistant but are > not, unexpected/covert optimization. > > In particular, unexpected/covert optimizations, such as ASCIBOOST, present > a potential centralizing and destabilizing force. > > ## Design > > ### Aux POW intermediate block > > Auxiliary POW blocks are introduced between normal blocks - i.e. the chain > alternates between the two POWs. > Each aux-POW block points to the previous normal block and contains > transactions just like a normal block. > Each normal block points to the previous aux-POW block and must contain > all transactions from the aux-POW block. > Block space is not increased. > > The new intermediate block and the pointers are introduced via a soft-fork > restriction. > > ### Reward for aux POW miners > > The reward for the aux POW smoothly increases from zero to a target value > (e.g. 1/2 of the total reward) over time. > The reward is transferred via a soft-fork restriction requiring a coinbase > output to an address published in the > aux-POW block. > > ### Aux POW difficulty adjustment > > Difficulty adjustments remain independent for the two POWs. > > The difficulty of the aux POW is adjusted based on the average time > between normal block found > to aux block found. > > Further details are dependent on the specific POW. > > ### Heaviest chain rule change > > This is a semi-hard change, because non-upgraded nodes can get on the > wrong chain in case of attack. However, > it might be possible to construct an alert system that notifies > non-upgraded nodes of an upcoming rule change. > All blocks are still valid, so this is not a hardforking change. > > The heaviest chain definition changes from sum of `difficulty` to sum of: > > mainDifficulty ^ x * auxDifficulty ^ y > > where we start at: > > x = 1; y = 0 > > and end at values of x and y that are related to the target relative > rewards. For example, if the target rewards > are equally distributed, we will want ot end up at: > > x = 1/2; y = 1/2 > > so that both POWs have equal weight. If the aux POW is to become > dominant, x should end small relative to y. > > > ## Questions and Answers > > - What should be the parameters if we want the aux POW to have equal > weight? A: 1/2 of the reward should be transferred > to aux miners and x = 1/2, y = 1/2. > > - What should be the parameters if we want to deprecate the main POW? A: > most of the reward should be transferred to > aux miners and x = 0, y = 1. The main difficulty will tend to zero, and > aux miners will just trivially generate the > main block immediately after finding an aux block, with identical content. > > - Wasted bandwidth to transfer transactions twice? A: this can be > optimized by skipping transactions already > transferred. > > - Why would miners agree to soft-fork away some of their reward? A: they > would agree if they believe that > the coins will increase in value due to improved security properties. > > ## Open Questions > > - After a block of one type is found, we can naively assume that POW will > become idle while a block of the other type is being mined. In practice, > the spare capacity can be used to find alternative ("attacking") blocks or > mine other coins. Is that a problem? > - Is selfish mining amplified by this scheme for miners that have both > types of hardware? > > ## POW candidates > > - SHA256 (i.e. use same POW, but introduce an intermediate block for > faster confirmation) > - Proof of Space and Time (Bram Cohen) > - Equihash > - Ethash > > ## Next Steps > > - evaluate POW candidates > - evaluate difficulty adjustment rules > - simulate miner behavior to identify if there are incentives for > detrimental behavior patterns (e.g. block withholding / selfish mining) > - Protocol details > > ## Credits > > Bram Cohen came up with a similar idea back in March: > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013744.html > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > --94eb2c0629360d15e6055d09a96a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am also concerned.=C2=A0 However, this proposal allows t= wo POWs to coexist and allows for gradual transitions. This is hopefully a = less disruptive approach since it allows cooperative miners to migrate over= time.=C2=A0 And of course, as a soft-fork it keeps backwards compatibility= with existing software.

On Thu, Nov 2, 2017 at 4:55 PM Tao Effect <contact@taoeffect.com> wrote:
Just going to throw in m= y support for a POW change, not any particular implementation, but the idea= .

Bitcoin is technically owned by China now. That's = not acceptable.

- Greg

--
Please do not email me anything that you are not comfortable= also sharing=C2=A0with the NSA.

On Oct = 31, 2017, at 10:48 PM, Devrandom via bitcoin-dev <bitcoin-dev@lists.linu= xfoundation.org> wrote:

Hi all,

Feedback is welcome on the draft below.=C2=A0 In p= articular, I want to see if there is interest in further development of the= idea and also interested in any attack vectors or undesirable dynamics.

(Formatted version available here:= =C2=A0https://github.com/devrandom/btc-papers/blob/master= /aux-pow.md )
# Soft-fork = Introduction of a New POW

## Motivation:
=

- Mitigate mining centralization pressures by introduci= ng a POW that does not have economies of scale
- Introduce an int= ermediary confirmation point, reducing the impact of mining power fluctuati= ons

Note however that choice of a suitable POW wil= l require deep analysis.=C2=A0 Some pitfalls include: botnet mining, POWs t= hat seem ASIC resistant but are not, unexpected/covert optimization.
<= div>
In particular, unexpected/covert optimizations, such as = ASCIBOOST, present a potential centralizing and destabilizing force.
<= div>
## Design

### Aux POW intermedi= ate block

Auxiliary POW blocks are introduced betw= een normal blocks - i.e. the chain alternates between the two POWs.
Each aux-POW block points to the previous normal block and contains tran= sactions just like a normal block.
Each normal block points to th= e previous aux-POW block and must contain all transactions from the aux-POW= block.
Block space is not increased.

Th= e new intermediate block and the pointers are introduced via a soft-fork re= striction.

### Reward for aux POW miners

The reward for the aux POW smoothly increases from zero to = a target value (e.g. 1/2 of the total reward) over time.
The rewa= rd is transferred via a soft-fork restriction requiring a coinbase output t= o an address published in the
aux-POW block.

=
### Aux POW difficulty adjustment

Difficulty = adjustments remain independent for the two POWs.

T= he difficulty of the aux POW is adjusted based on the average time between = normal block found
to aux block found.

F= urther details are dependent on the specific POW.

= ### Heaviest chain rule change

This is a semi-hard= change, because non-upgraded nodes can get on the wrong chain in case of a= ttack.=C2=A0 However,
it might be possible to construct an alert = system that notifies non-upgraded nodes of an upcoming rule change.
All blocks are still valid, so this is not a hardforking change.

The heaviest chain definition changes from sum of `diffic= ulty` to sum of:

=C2=A0 =C2=A0 mainDifficulty ^ x = * auxDifficulty ^ y

where we start at:
<= br>
=C2=A0 =C2=A0 x =3D 1; y =3D 0

and e= nd at values of x and y that are related to the target relative rewards.=C2= =A0 For example, if the target rewards
are equally distributed, w= e will want ot end up at:

=C2=A0 =C2=A0 x =3D 1/2;= y =3D 1/2

so that both POWs have equal weight.=C2= =A0 If the aux POW is to become dominant, x should end small relative to y.=


## Questions and Answers

- What should be the parameters if we want the aux POW to h= ave equal weight? A: 1/2 of the reward should be transferred
to a= ux miners and x =3D 1/2, y =3D 1/2.

- What should = be the parameters if we want to deprecate the main POW?=C2=A0 A: most of th= e reward should be transferred to
aux miners and x =3D 0, y =3D 1= .=C2=A0 The main difficulty will tend to zero, and aux miners will just tri= vially generate the
main block immediately after finding an aux b= lock, with identical content.

- Wasted bandwidth t= o transfer transactions twice?=C2=A0 A: this can be optimized by skipping t= ransactions already
transferred.

- Why w= ould miners agree to soft-fork away some of their reward?=C2=A0 A: they wou= ld agree if they believe that
the coins will increase in value du= e to improved security properties.

## Open Questio= ns

- After a block of one type is found, we can na= ively assume that POW will become idle while a block of the other type is b= eing mined.=C2=A0 In practice, the spare capacity can be used to find alter= native ("attacking") blocks or mine other coins.=C2=A0 Is that a = problem?
- Is selfish mining amplified by this scheme for miners = that have both types of hardware?

## POW candidate= s

- SHA256 (i.e. use same POW, but introduce an in= termediate block for faster confirmation)
- Proof of Space and Ti= me (Bram Cohen)
- Equihash
- Ethash

## Next Steps

- evaluate POW candidates
- evaluate difficulty adjustment rules
- simulate miner beh= avior to identify if there are incentives for detrimental behavior patterns= (e.g. block withholding / selfish mining)
- Protocol details

## Credits

Bram Cohen came u= p with a similar idea back in March:
_______________________________________________
bitcoin-dev mailing list=
bitcoin-dev@lists.linuxfoundation.org
https://= lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--94eb2c0629360d15e6055d09a96a--