Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 6D642C19 for ; Thu, 2 Nov 2017 23:55:57 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from homiemail-a5.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 83E92DF for ; Thu, 2 Nov 2017 23:55:56 +0000 (UTC) Received: from homiemail-a5.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a5.g.dreamhost.com (Postfix) with ESMTP id DFF6E70407D; Thu, 2 Nov 2017 16:55:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=taoeffect.com; h=from :content-type:mime-version:subject:message-id:date:references:to :in-reply-to; s=taoeffect.com; bh=iXqkmUepY6zZ56XqHgk9Ts0t9og=; b=UMlfSgscNYj/tLOzMz6q3Op4lg1E0JbPD5XdDnAOD8LZDCzUfuC7hm0gMQrgk BIaM93d/u+eR1rGzuFIUk401de/x3hBqDUilfzp4sxgiWgGVoYal2HVTe7ux07wb fuMbfIQO2qNxhviRQLttC7wWpM5GXthr4A33wFoFu3f7uc= Received: from [192.168.42.66] (184-23-254-163.fiber.dynamic.sonic.net [184.23.254.163]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: contact@taoeffect.com) by homiemail-a5.g.dreamhost.com (Postfix) with ESMTPSA id 86E42704078; Thu, 2 Nov 2017 16:55:55 -0700 (PDT) From: Tao Effect Content-Type: multipart/signed; boundary="Apple-Mail=_934A4CDF-DA4A-4164-9803-6BB7C19E50A3"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Mao-Original-Outgoing-Id: 531359754.946768-8b0393adb31fa394c0f357e3e8786091 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Thu, 2 Nov 2017 16:55:55 -0700 References: To: Devrandom , Bitcoin Protocol Discussion In-Reply-To: X-Mailer: Apple Mail (2.3273) X-Spam-Status: No, score=-0.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU, HTML_MESSAGE, RCVD_IN_DNSWL_NONE 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 00:01:22 +0000 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: Thu, 02 Nov 2017 23:55:57 -0000 --Apple-Mail=_934A4CDF-DA4A-4164-9803-6BB7C19E50A3 Content-Type: multipart/alternative; boundary="Apple-Mail=_7FB1C43F-2CD8-4630-A50B-99FFB29C12DE" --Apple-Mail=_7FB1C43F-2CD8-4630-A50B-99FFB29C12DE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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 = > wrote: >=20 > Hi all, >=20 > 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. >=20 > (Formatted version available here: = https://github.com/devrandom/btc-papers/blob/master/aux-pow.md = ) >=20 > # Soft-fork Introduction of a New POW >=20 > ## Motivation: >=20 > - 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 >=20 > 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. >=20 > In particular, unexpected/covert optimizations, such as ASCIBOOST, = present a potential centralizing and destabilizing force. >=20 > ## Design >=20 > ### Aux POW intermediate block >=20 > 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. >=20 > The new intermediate block and the pointers are introduced via a = soft-fork restriction. >=20 > ### Reward for aux POW miners >=20 > 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. >=20 > ### Aux POW difficulty adjustment >=20 > Difficulty adjustments remain independent for the two POWs. >=20 > The difficulty of the aux POW is adjusted based on the average time = between normal block found > to aux block found. >=20 > Further details are dependent on the specific POW. >=20 > ### Heaviest chain rule change >=20 > 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. >=20 > The heaviest chain definition changes from sum of `difficulty` to sum = of: >=20 > mainDifficulty ^ x * auxDifficulty ^ y >=20 > where we start at: >=20 > x =3D 1; y =3D 0 >=20 > 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: >=20 > x =3D 1/2; y =3D 1/2 >=20 > so that both POWs have equal weight. If the aux POW is to become = dominant, x should end small relative to y. >=20 >=20 > ## Questions and Answers >=20 > - 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 =3D 1/2, y =3D 1/2. >=20 > - 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 =3D 0, y =3D 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. >=20 > - Wasted bandwidth to transfer transactions twice? A: this can be = optimized by skipping transactions already > transferred. >=20 > - 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. >=20 > ## Open Questions >=20 > - 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? >=20 > ## POW candidates >=20 > - SHA256 (i.e. use same POW, but introduce an intermediate block for = faster confirmation) > - Proof of Space and Time (Bram Cohen) > - Equihash > - Ethash >=20 > ## Next Steps >=20 > - 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 >=20 > ## Credits >=20 > 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 --Apple-Mail=_7FB1C43F-2CD8-4630-A50B-99FFB29C12DE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 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<= /a> )

# = 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 =3D 1; y =3D 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 =3D 1/2; = y =3D 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 =3D 1/2, y =3D 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 =3D = 0, y =3D 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-Ma= rch/013744.html
_______________________________________________
bitcoin-dev = mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= /a>

= --Apple-Mail=_7FB1C43F-2CD8-4630-A50B-99FFB29C12DE-- --Apple-Mail=_934A4CDF-DA4A-4164-9803-6BB7C19E50A3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEgYtgnomHliYDCUth7GcgK+kJUkcFAln7sIoACgkQ7GcgK+kJ UkfNRhAA14St486JMZDiNkymAysHXvCj0JnEQp73Ch8AX0UkjJnGe8T8O8NgDLNW XIrRp5ZSC8pz9rTbr3i1lgwTcWVgqTmYeT73yWv2bi5IgDNjomRWolJRMRdr+srw L2BRdQZ7uYA+FP0YppwACZ6Lb7OSgrkneCiIBG8rcC4nqDDc/zfehjP62c0pPq2V 3ylFOVWOt6ipLuMKJZJS/AdwrkKzp3pFnny7L1rJNRB3kbnbSBh448aQzUHOQjJR o/VucHgOsV7vFydntO19NSIvv2+ZKGss0Tka/GyEsAQcFiof6JZXpfAk01cLXs6S vjeGZrQkiUjhyXOFKXg2zYk1dQGsnF+e/Ov6fN8YWnxXLCaXhIUYY91JLUqpHEoo DBcJKerkiryd+BJrX6aAB935D3Tb+Ii5ydjdKeRXe1AgzcRkTSeWyaFz65sEHeq0 l3hFjDB2bSc60zyPVeZ8+bICo3yQpQ2g6L5WrvctyKX4STikkhmTUNySGl8KZNri OhJ8Xjn+ljdNI5xi9LlJZT/3FVDm//uo6TubG7rCbPJBfoAySTz34bXZ5dKKHot/ jdEm5vNxmlH7gCrtHnUvk3aLXOf2hjpEv5g66Vitg9ZNOILIdDRChnvndJJS6HTt WUn3Q4zfTeNbCNtv9dPuZN2ybZPGeQ8AdsmX7eXCRFeku8A31RI= =TOtZ -----END PGP SIGNATURE----- --Apple-Mail=_934A4CDF-DA4A-4164-9803-6BB7C19E50A3--