Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 4FB21A86 for ; Mon, 6 Nov 2017 19:50:09 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail148102.authsmtp.net (outmail148102.authsmtp.net [62.13.148.102]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7EDC920D for ; Mon, 6 Nov 2017 19:50:08 +0000 (UTC) Received: from mail-c245.authsmtp.com (mail-c245.authsmtp.com [62.13.128.245]) by punt20.authsmtp.com. (8.15.2/8.15.2) with ESMTP id vA6Jo6kP043309; Mon, 6 Nov 2017 19:50:06 GMT (envelope-from pete@petertodd.org) Received: from petertodd.org (ec2-52-5-185-120.compute-1.amazonaws.com [52.5.185.120]) (authenticated bits=0) by mail.authsmtp.com (8.15.2/8.15.2) with ESMTPSA id vA6Jo4De009739 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 6 Nov 2017 19:50:05 GMT (envelope-from pete@petertodd.org) Received: from [127.0.0.1] (localhost [127.0.0.1]) by petertodd.org (Postfix) with ESMTPSA id 3F524400F8; Mon, 6 Nov 2017 19:50:03 +0000 (UTC) Received: by localhost (Postfix, from userid 1000) id 87EAF20888; Mon, 6 Nov 2017 14:50:00 -0500 (EST) Date: Mon, 6 Nov 2017 14:50:00 -0500 From: Peter Todd To: Devrandom , Bitcoin Protocol Discussion Message-ID: <20171106195000.GA7245@fedora-23-dvm> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0OAP2g/MAC+5xKAE" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Server-Quench: af9d6304-c32b-11e7-bb95-9cb654bb2504 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdgQUFloCAgsB AmEbWl1eVV17WWY7 bghPaBtcak9QXgdq T0pMXVMcUnRue0MF ckseUhB1dAwIfnhx bQgzCHkPWkd6cVsu QUwGCGwHMGB9OjIW VV1RJFFSdQcYLB1A alQxNiYHcQ5VPz4z GA41ejw8IwAXCSJJ WAYBMFkTR0lDF3YE YC9KATU1GlAKR206 ZwchJEJZEkELMS0A X-Authentic-SMTP: 61633532353630.1039:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 52.5.185.120/25 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Status: No, score=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW autolearn=disabled version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org 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: Mon, 06 Nov 2017 19:50:09 -0000 --0OAP2g/MAC+5xKAE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 01, 2017 at 05:48:27AM +0000, Devrandom via bitcoin-dev wrote: Some quick thoughts... > 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 First of all, I don't think you can really call this a soft-fork; I'd call = it a "pseudo-soft-fork" My reasoning being that after implementation, a chain with less total work = than the main chain - but more total SHA256^2 work than the main chain - might be followed by non-supporting clients. It's got some properties of a soft-fork, but it's security model is definitely different. > ### 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 a= ll > transactions from the aux-POW block. Note how you're basically proposing for the block interval to be decreased, which has security implications due to increased orphan rates. > ### Heaviest chain rule change >=20 > This is a semi-hard change, because non-upgraded nodes can get on the wro= ng > chain in case of attack. However, Exactly! Not really a soft-fork. --=20 https://petertodd.org 'peter'[:-1]@petertodd.org --0OAP2g/MAC+5xKAE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEMyU1607oofLeYpz8Y5kBEETor7IFAloAvOcACgkQY5kBEETo r7IHCQf/f1rZFuOEuR1Lw2Es9T1j9Hap0eyoANmhsvHYe173aFOf2305tTkp2o+s uZhmFuOiVqJ/We6KiWxw564bqdwf2fLeV/Gcr0KPQQgaiHPskvuk9mCPvZFXv3kN 1HiNVK162+1+w1LLFYHb7v3MQGrKsTB0D9aCrKBaZtEiTOZMnKdN1dlNPm7sIpxZ pd+4A+tJ/V4ik2UWTtTkXyrkR5M4aQRVf/m6tDyk36asyYMyQbRcKoLpwK+YP2ek Spzj54nurP4vUk6CYWSQRsgtjhnBklT3bL4Q9fTJlQQMXoO56tpD1bLH5u3P4LPt +wcKwJ2z3j4ll1v07lWT3cg0RKOJmw== =r80o -----END PGP SIGNATURE----- --0OAP2g/MAC+5xKAE--