Daniele Pinna, Ph.D

<= /div>

On Fri, Oct 2, 2015 at 10:20 AM, Jorge Tim= =C3=B3n <jtimon@jtimon.cc> wrote:

On Oct 2, 2015 10:03 AM, "Daniele Pinna via bitcoin-dev" <bitc= oin-dev@lists.linuxfoundation.org> wrote:
>
> should an algorithm that guarantees protection from ASIC/FPGA optimiza= tion be found.

This is demonstrably impossible: anything that can be= done with software can be done with hardware. This is computer science 101= .
And specialized hardware can always be more efficient, at least energy-wise= .

On the other hand, BIP99 explicitly contemplates "anti-= miner hardforks" (obviously not for so called "ASIC-resistance&qu= ot; [an absurd term coined to promote some altcoins], but just for restarti= ng the ASIC and mining market in case mining becomes too centralized).

--001a11c019c0f2558905211afe14-- 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 612A619BD for ; Fri, 2 Oct 2015 10:46:31 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from smtp10.hushmail.com (smtp10.hushmail.com [65.39.178.143]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1918231 for ; Fri, 2 Oct 2015 10:46:31 +0000 (UTC) Received: from smtp10.hushmail.com (localhost [127.0.0.1]) by smtp10.hushmail.com (Postfix) with SMTP id C3D6DC0214 for ; Fri, 2 Oct 2015 10:46:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=hush.com; h=date:to:subject:from; s=hush; bh=eQE7mUBjvkr/SlTFQl36+sJ0il56Kc8Uk/msD9e8VKc=; b=gARqng2rf2vWd1jMoIpjjf9q24PqoDjQtpcHEz9bKaFpIgBCklOu60GaNWRg+2uCYRxXjB7LtfmnsugV2g96Isv7zq+WyrPKZEL53apg0A6MMMQjki/5d0141b2jb8+XVrGwGJ831wbcDi5OKICstDrpITwczfZIeSITUWXq5fE3vVlY3AiBGlNq9L4Bg54n0mn60yrPNw7FAmJP4VPzU2gB0IGE9CjgDb6yczbMk2ZeQs3jznywWnHXzEgAXcl18xdvE71UHvsgcUkgZja0a7EzQ8OCXvzvfo6Ud986cZsy5o/d1X6duVUE90Vd/jKQyyJfXX7V0az7YmRP8vuYWg== Received: from smtp.hushmail.com (w1.hushmail.com [65.39.178.83]) by smtp10.hushmail.com (Postfix) with ESMTP; Fri, 2 Oct 2015 10:46:30 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 5F7A720101; Fri, 2 Oct 2015 10:46:30 +0000 (UTC) MIME-Version: 1.0 Date: Fri, 02 Oct 2015 13:46:30 +0300 To: "=?UTF-8?B?Sm9yZ2UgVGltw7Nu?=" , "Daniele Pinna" From: "NxtChg" In-Reply-To: References:

Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20151002104630.5F7A720101@smtp.hushmail.com> X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] =?utf-8?q?Dev-list=27s_stance_on_potentially_alteri?= =?utf-8?q?ng_the_PoW=09algorithm?= X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 10:46:31 -0000 >...obviously not for so called "ASIC-resistance" [an absurd term coined to promote some altcoins] Yet another fallacy of "all-or-nothing" thinking, which is so abundant in the Core camp. The fact that you can build ASIC for any kind of algorithm _in_theory_ doesn't mean you can't make it _arbitrary_hard_ in practice. So I would tone down the arrogance a bit. 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 31AF71E25 for ; Fri, 2 Oct 2015 11:01:01 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 852A08E for ; Fri, 2 Oct 2015 11:00:59 +0000 (UTC) Received: by wicfx3 with SMTP id fx3so28343803wic.1 for ; Fri, 02 Oct 2015 04:00:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=szXdhtlui7vcTdt7fEqPG4/8iZ6HXDr5a7zjV3KIJzQ=; b=S3UYRxYRrkYJCXvieL0qaUPiJtEpaelkmn2X9bF6UjV199xM+NMVnSJEQ/Cbu0V60q QoRd70l9KrJRyGRoyKGm8fCLBBHooConTMPh+8guPfzIWqq4tr62jvuE6q56ZyXSEXWw YPNXR1FdFHJ2wTGYGScB2yzc60mE8OF89bYn7vyrEGw/a4efcrQDmEkNf/mu4OuygzjJ aKPcTlPC5upR60HFc2VBqcjkNOHWqfGCiIF4UyUxlb5yN76g1dR/4eXlqFcD/nZMp0i2 d0RyNKfAhULuTP2UMt9n+9dFHGloeqQSlmXi6XVjywhV1LN8yU2ETvQtguEyyFrYQpmM FmLQ== X-Gm-Message-State: ALoCoQm0FsoYoZubr0ONWfbwmhDEjv1ldGS4x3RmjRseccZfp3vSfZDLdI6vGkNI1s1BwMkP0gnN MIME-Version: 1.0 X-Received: by 10.180.8.106 with SMTP id q10mr3407934wia.92.1443783658388; Fri, 02 Oct 2015 04:00:58 -0700 (PDT) Received: by 10.194.114.199 with HTTP; Fri, 2 Oct 2015 04:00:57 -0700 (PDT) Received: by 10.194.114.199 with HTTP; Fri, 2 Oct 2015 04:00:57 -0700 (PDT) In-Reply-To: <20151002104630.5F7A720101@smtp.hushmail.com> References:

<20151002104630.5F7A720101@smtp.hushmail.com> Date: Fri, 2 Oct 2015 13:00:57 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: NxtChg Content-Type: multipart/alternative; boundary=f46d0421a72317549805211d14dc X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev , Daniele Pinna Subject: Re: [bitcoin-dev] Dev-list's stance on potentially altering the PoW algorithm X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 11:01:01 -0000 --f46d0421a72317549805211d14dc Content-Type: text/plain; charset=UTF-8 On Oct 2, 2015 12:46 PM, "NxtChg" wrote: > > > >...obviously not for so called "ASIC-resistance" [an absurd term coined to promote some altcoins] > > Yet another fallacy of "all-or-nothing" thinking, which is so abundant in the Core camp. > > The fact that you can build ASIC for any kind of algorithm _in_theory_ doesn't mean you can't make it _arbitrary_hard_ in practice. > > So I would tone down the arrogance a bit. > ASIC-RESISTANCE is simply not possible, I'm sorry if that position strikes you as arrogant. Note that I didn't say anything about memory-hard, which is possible (but not necessarily preferrable to simple-to-implement-in-hardware pow algorithms). --f46d0421a72317549805211d14dc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Oct 2, 2015 12:46 PM, "NxtChg" <nxtchg@hush.com> wrote:
>
>
> >...obviously not for so called "ASIC-resistance" [an abs= urd term coined to promote some altcoins]
>
> Yet another fallacy of "all-or-nothing" thinking, which is s= o abundant in the Core camp.
>
> The fact that you can build ASIC for any kind of algorithm _in_theory_= doesn't mean you can't make it _arbitrary_hard_ in practice.
>
> So I would tone down the arrogance a bit.
>

ASIC-RESISTANCE is simply not possible, I'm sorry if tha= t position strikes you as arrogant. Note that I didn't say anything abo= ut memory-hard, which is possible (but not necessarily preferrable to simpl= e-to-implement-in-hardware pow algorithms).

--f46d0421a72317549805211d14dc-- 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 DAFC41A43 for ; Fri, 2 Oct 2015 16:38:34 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5C02D2CA for ; Fri, 2 Oct 2015 16:38:34 +0000 (UTC) Received: from [192.168.1.68] ([205.250.126.165]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MJjUO-1ZgxQA2mkm-001AEq; Fri, 02 Oct 2015 18:38:31 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_B09B6D8E-F20A-4C24-9DFF-87A28D609852" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Peter R In-Reply-To: Date: Fri, 2 Oct 2015 09:38:26 -0700 Message-Id: References:

To: =?utf-8?Q?Jorge_Tim=C3=B3n?= X-Mailer: Apple Mail (2.2104) X-Provags-ID: V03:K0:Cec5ZZ5mmQN7O7y7Uj4phS4LdJZhsuQDB4IYddVFJHopNYWMEhI H/tTyLSU8wvBR2lhFLnP8f+HXFPZljSkII4pNgthHGxizyQGHC26DHLAtQJeiaxw9uxRQgt sc3b+JsRUmgfsBBG937ADzwswGEAFsMCUqOdyJoheVxxYvljhqq7IucRfCG8fcs6HvsJyUI f2DPYg20CZF/cn32sVNsg== X-UI-Out-Filterresults: notjunk:1;V01:K0:UDXefhM2E4Q=:U9w5mhGUMIVnOUDjnJPYuB 0jvHf1w0i0boLCt1fCNGLq7INlF40oYdQ/Yjh9LfOPLwEhABgXLElXvyxz40bNyjMtarSMTFv 0KsXrarWE/kWyljIC4qDR9iQxBfBT6ffAnhEOiw3ZwJRDHlXCihJNRY3PzHpkEiA7ufOixV0t hkIDQSu4xHO28JpIktkJf+mfw6HLaSSmr29KqUQHTlbSQJ8Q/VFPia8zVcU+IKwHA1nY4g2GP KlE5q63MbvAhl+ddLaT9Qju8yhJfsSp2iInTae8DswXVMflhIzgLzJFnv9KEAih+5Ak0RyQXA SKaylRUc1+AIkLsi8u2iEdVY+/EjrNH64DQAPmdVTNo8T8NLLhog8tIbCrjeuOTxaaoUKXzVZ xb3tYfLEkKUPhwnqu4ncxfj9hk7rpKMqnN5ljgy9uEWIqGLqmX3bhVnvgRmwCzAzWb1vWk/WT J9SVojueM3bgml4afi/q3fjTYqzJCiIOu1n1OUL7ND+mx1cG550T8OXsSOztSWI/l5AybKjkh 9s+SFBVzz9SIMfcI47yD2D2lkgu6tQ6TpNsP+6lBWdPUThw/091mY3yz3FTSBvbz02fswYs7J X5EtdHfKnCR4T2YqUFt5jm1PW4ihyd72TAxT1AgiXZ+iIHs3JBcPxMM2Y79wpHZIS59Hw8RXB 7V/7EgUI4RCze2QBe/nByliJ+2YGjUTQEp8RSGCUYJQW/SnrzUwWW2cq6gMDcnH8RXLI9JQoX UerMAD9w0nT2bJD14FsIO5D/yUbGGfzURHOEgz0bObzi4RDV0HQ9LZzbzv/YlBYh+lajEZSMD 5UGNiNq X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM, HTML_MESSAGE, MIME_QP_LONG_LINE, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev , Daniele Pinna Subject: Re: [bitcoin-dev] Dev-list's stance on potentially altering the PoW algorithm X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 16:38:35 -0000 --Apple-Mail=_B09B6D8E-F20A-4C24-9DFF-87A28D609852 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 2, 2015, at 1:20 AM, Jorge Tim=C3=B3n via bitcoin-dev = wrote: > On Oct 2, 2015 10:03 AM, "Daniele Pinna via bitcoin-dev" = > wrote: > > should an algorithm that guarantees protection from ASIC/FPGA = optimization be found. > This is demonstrably impossible: anything that can be done with = software can be done with hardware. This is computer science 101. And = specialized hardware can always be more efficient, at least energy-wise. >=20 I encourage Alex and Dmitry to consider submitting their paper to = Ledger, where it will be reviewed objectively and with an open mind. = The authors have motivated their work, framed it in its scholarly = context, and made explicit the contributions their paper makes. Their = manuscript, "Asymmetric proof-of-work based on the Generalized Birthday = problem," clearly represents a great deal of work by the authors and I = commend them for their efforts. =20 In the link Adam Back provided, Greg Maxwell mentioned that =E2=80=9Cit = is far from clear that 'memory hardness' is actually a useful goal.=E2=80=9D= I agree with this statement; however, regardless of whether memory = hardness turns out to be a useful goal in regards to cryptocurrency or = not, a paper analyzing memory-hard proof-of-work schemes is certainly = useful in helping us to figure that out.=20 Best regards, Peter= --Apple-Mail=_B09B6D8E-F20A-4C24-9DFF-87A28D609852 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On = Oct 2, 2015, at 1:20 AM, Jorge Tim=C3=B3n via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> = wrote:

On Oct 2, 2015 10:03 AM, "Daniele Pinna via bitcoin-dev" = <bitcoin-dev@lists.linuxfoundation.org> = wrote:

> should an algorithm that guarantees protection from = ASIC/FPGA optimization be found.
This is demonstrably impossible: anything that can be done = with software can be done with hardware. This is computer science 101. = And specialized hardware can always be more efficient, at least = energy-wise.

I encourage Alex and Dmitry to = consider submitting their paper to Ledger, where it = will be reviewed objectively and with an open mind. The authors = have motivated their work, framed it in its scholarly context, and made = explicit the contributions their paper makes. Their manuscript, = "Asymmetric proof-of-work based on the Generalized Birthday problem," = clearly represents a great deal of work by the authors and I commend = them for their efforts.

In the link Adam Back provided, Greg Maxwell mentioned that = =E2=80=9Cit is far from clear that 'memory hardness' is actually a = useful goal.=E2=80=9D I agree with this statement; however, = regardless of whether memory hardness turns out to be a useful goal in = regards to cryptocurrency or not, a paper analyzing memory-hard = proof-of-work schemes is certainly useful in helping us to figure that = out.

Best = regards,

Peter

= --Apple-Mail=_B09B6D8E-F20A-4C24-9DFF-87A28D609852-- 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 38CC9213C for ; Fri, 2 Oct 2015 16:45:46 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com [209.85.213.175]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B325D2DD for ; Fri, 2 Oct 2015 16:45:45 +0000 (UTC) Received: by igcrk20 with SMTP id rk20so21396683igc.1 for ; Fri, 02 Oct 2015 09:45:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tCKoKXUM4DJF9J7QH3ueAEYrtKt79kbN51SNwhCj4Hw=; b=S9TZBOD4SPpwLKoohDnPkOut5iBRFyf/9gbKtM7n6GDvYoX+foCYCvQHlPCnBjf7F8 SoCvwypX29KUaq1dCoeVOhlQ7CjKHZvDY2uyPlfpFmkDgS+ekqXX9nHMnMwUKf9lTCS8 H4EAbOcX5SsE4VV9B1wsRWEs7D92IqN7HWOWeOp4H36TimdhidvWMniugmMdCHN7zJUw xk4kVoo/aoeomBLt8zWf0/uEbvyv9Ys+5DeecIiIlC90H0JaDkYEisDLuLRVR+0/lMUY CxD0YUoUNrDLPdpvUSHCK2nayBrLy3vg1fgvgJsiNZ4g1fiaNzts2TK1Bb0Bq/SfxB0b o1aA== MIME-Version: 1.0 X-Received: by 10.50.62.227 with SMTP id b3mr5109627igs.48.1443804345232; Fri, 02 Oct 2015 09:45:45 -0700 (PDT) Received: by 10.107.19.30 with HTTP; Fri, 2 Oct 2015 09:45:45 -0700 (PDT) In-Reply-To: References:

Date: Fri, 2 Oct 2015 16:45:45 +0000 Message-ID: From: Gregory Maxwell To: Daniele Pinna Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] Dev-list's stance on potentially altering the PoW algorithm X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 16:45:46 -0000 On Fri, Oct 2, 2015 at 8:30 AM, Daniele Pinna via bitcoin-dev wrote: > The recently published paper I referenced cite's the Cuckoo cycle algorithm, > discusses its limitations and explains how their proposed algorithm greatly > improves on it. They discuss a very old version of the Cuckoo cycle paper, and I believe none of their analysis is applicable to the most recent revision. :( In any case, I commented more about functions of this class here: https://www.reddit.com/r/Bitcoin/comments/3n5nws/research_paper_asymmetric_proofofwork_based_on/cvl922x I don't believe changing the POW function is impossible in principle, but I expect it would only happen due to problems with the composition of current hash-power and not even if it were universally agreed that some other construction were technically better (though that is a high bar.) 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 C54CD1B92 for ; Fri, 2 Oct 2015 21:31:53 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 6A99028F for ; Fri, 2 Oct 2015 21:31:53 +0000 (UTC) Received: from ishibashi.localnet (unknown [IPv6:2001:470:5:265:61b6:56a6:b03d:28d6]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id C123310801D0; Fri, 2 Oct 2015 21:31:23 +0000 (UTC) X-Hashcash: 1:25:151002:bitcoin-dev@lists.linuxfoundation.org::ibd/3nCGAhjAJdVl:1U1J X-Hashcash: 1:25:151002:daniele.pinna@gmail.com::ySYvcoT+wBuI+Xv9:Q1vF From: Luke Dashjr To: bitcoin-dev@lists.linuxfoundation.org, Daniele Pinna Date: Fri, 2 Oct 2015 21:31:21 +0000 User-Agent: KMail/1.13.7 (Linux/4.1.6-gentoo; KDE/4.14.8; x86_64; ; ) References: In-Reply-To: X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F X-PGP-Key-ID: BD02942421F4889F X-PGP-Keyserver: hkp://pgp.mit.edu MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201510022131.22411.luke@dashjr.org> X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Dev-list's stance on potentially altering the PoW algorithm X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 21:31:53 -0000 On Friday, October 02, 2015 8:02:43 AM Daniele Pinna via bitcoin-dev wrote: > I am however interested in the dev-list's stance on potentially > altering the bitcoin PoW protocol should an algorithm that guarantees > protection from ASIC/FPGA optimization be found. > > I assume that, given the large amount of money invested by some miners into > their industrial farms this would represent a VERY contentious hard fork. > > It is, however, also true that a novel optimization-resistant algorithm > could greatly ameliorate decentralization in the bitcoin network due to a > resurgence of desktop/cellphone mining. > > Where do the core devs stand on this matter, hypothetical as it may be? Besides ASIC-proof being even tehoretically impossible, assuming we had a PoW that worked using mere RAM-as-the-ASIC, this would probably not be good in the long term for decentralisation, as it is only a matter of time until botnets would bankrupt all the legitimate miners out of operation. Restarting the mining with a new algorithm as a reaction and defence against centralised hoarding of mining ASICs (as we are seeing now), would be acceptable. It would not necessarily be contentions *to the economy*, as such hoarding-miners do not participate in the economy in any meaningful way (they do not accept payments from other bitcoin users). Luke 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 583461B53 for ; Fri, 2 Oct 2015 21:37:12 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EA64F365 for ; Fri, 2 Oct 2015 21:37:10 +0000 (UTC) Received: by wicge5 with SMTP id ge5so50290189wic.0 for ; Fri, 02 Oct 2015 14:37:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=xEjy7YGGV7fBAhLmqEXVmTflv0PvCWpcfMP6UtRAygQ=; b=xX2zNTRm8edZ0y9r2lYVLTzDk8gHv18qeZEFUd1yexORnkN66URaUoIDf/IMabLv/H jxDvUcyxAepllftTuTyygoUKkk/FxG1QMRjmTmdVGWHT4LCcTHNo0PvnbAKm3Q6gYpwC ImLPX2077SPXOgGnXw5Wn2GjU4zGrhZlFJjfIZSa1Ugx5tcZGnJNAw0bBkFSU6Gn/zxm cK1PFLVBJnANYIfcwMWM7MM9g0kzt1KMwEdh3TTrKrdOpNI9s/uA4bKVGq//Pk3+kYek M6inyDK+95vlgn7QuXeALAHOPEV3zP97kDD5UWy9w7ry/yY4uEmcRJs3+08EEOwJnEiF qySQ== MIME-Version: 1.0 X-Received: by 10.194.76.67 with SMTP id i3mr20713569wjw.5.1443821829731; Fri, 02 Oct 2015 14:37:09 -0700 (PDT) Sender: dscotese@gmail.com Received: by 10.27.211.132 with HTTP; Fri, 2 Oct 2015 14:37:09 -0700 (PDT) In-Reply-To: References:

Date: Fri, 2 Oct 2015 14:37:09 -0700 X-Google-Sender-Auth: bJgJ5zGXgpFxqpSi2_xLdJwDejo Message-ID: From: Dave Scotese To: Bitcoin Dev Content-Type: multipart/alternative; boundary=047d7bdc87aa47bf7c052125f7de X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Dev-list's stance on potentially altering the PoW algorithm X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 21:37:12 -0000 --047d7bdc87aa47bf7c052125f7de Content-Type: text/plain; charset=UTF-8 If the PoW function is changed, it ought to change slowly so as not to drop a brick wall in front of the miners speeding toward the ever-receding goal of protecting the blockchain. Who's going to get on that path if the bitcoin community does that? But it can be done slowly. If most of the entries is the list of possible PoW functions are double-SHA256, then the few that aren't will offer the healthy goal sought by those who like the idea of changing it. The healthy goal is for general computing machines to help protect the blockchain in an incentivized way. There's a sick goal too, which is to destroy large investments in mining. I hope no one has that goal. At http://bitcoin.stackexchange.com/questions/35679/is-it-possible-to-make-pow-asic-resistant-through-dynamically-generated-hash-cha/40475#40475 I proposed that ongoing competitions for the creation of new hash algorithms could feed an ASIC-resistant PoW, defined using the as-yet-unknowable winners of such competitions. It is possible to make an ASIC resistant algorithm, but it isn't a programmable algorithm - it's one that requires human intervention. The hash of the next block is a good example - there's no programmable algorithm that can find it because too much human intervention is required, but it's an algorithm well-enough defined for us to build a billion dollar system on top of it. That being said, I've started looking at two different kinds of decentralization. The literal actually-in-different-places kind is categorically different than the much more important, virtual impervious-to-coercion kind. The behavior of the "centralized" oil cartel is a good example. The participants cheat. This is a fundamental principle in the debate between free-marketeers and authoritarians regarding the emergence of monopoly. Without coercion, monopolies fall apart. There's nothing coercive about our use of the double-SHA256, so in my mind, the centralization it has so far produced is not dangerous. It's scary, sure, but until coercion is used to prevent me and my friends from buying our own ASICs, it remains impervious to coercion. Sorry for the long email that didn't make any apparent progress. The thinking is what matters to me, and seeing two kinds of decentralization and recognizing that a change in PoW can be slow enough to avoid hurting existing miners are items I haven't seen anyone else recognize, so I had to bring them up. notplato On Fri, Oct 2, 2015 at 9:45 AM, Gregory Maxwell via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Fri, Oct 2, 2015 at 8:30 AM, Daniele Pinna via bitcoin-dev > wrote: > > The recently published paper I referenced cite's the Cuckoo cycle > algorithm, > > discusses its limitations and explains how their proposed algorithm > greatly > > improves on it. > > They discuss a very old version of the Cuckoo cycle paper, and I > believe none of their analysis is applicable to the most recent > revision. :( > > In any case, I commented more about functions of this class here: > > https://www.reddit.com/r/Bitcoin/comments/3n5nws/research_paper_asymmetric_proofofwork_based_on/cvl922x > > I don't believe changing the POW function is impossible in principle, > but I expect it would only happen due to problems with the composition > of current hash-power and not even if it were universally agreed that > some other construction were technically better (though that is a high > bar.) > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -- I like to provide some work at no charge to prove my value. Do you need a techie? I own Litmocracy and Meme Racing (in alpha). I'm the webmaster for The Voluntaryist which now accepts Bitcoin. I also code for The Dollar Vigilante . "He ought to find it more profitable to play by the rules" - Satoshi Nakamoto --047d7bdc87aa47bf7c052125f7de Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

If the PoW function is changed, i= t ought to change slowly so as not to drop a brick wall in front of the min= ers speeding toward the ever-receding goal of protecting the blockchain.=C2= =A0 Who's going to get on that path if the bitcoin community does that?=

But it can be done slowly.=C2=A0 If most of the entries is th= e list of possible PoW functions are double-SHA256, then the few that aren&= #39;t will offer the healthy goal sought by those who like the idea of chan= ging it.=C2=A0 The healthy goal is for general computing machines to help p= rotect the blockchain in an incentivized way.=C2=A0 There's a sick goal= too, which is to destroy large investments in mining.=C2=A0 I hope no one = has that goal.

At http://bitcoin.stackexchange.com/questio= ns/35679/is-it-possible-to-make-pow-asic-resistant-through-dynamically-gene= rated-hash-cha/40475#40475 I proposed that ongoing competitions for the= creation of new hash algorithms could feed an ASIC-resistant PoW, defined = using the as-yet-unknowable winners of such competitions.=C2=A0 It is possi= ble to make an ASIC resistant algorithm, but it isn't a programmable al= gorithm - it's one that requires human intervention.=C2=A0 The hash of = the next block is a good example - there's no programmable algorithm th= at can find it because too much human intervention is required, but it'= s an algorithm well-enough defined for us to build a billion dollar system = on top of it.

That being said, I've started looking at two= different kinds of decentralization.=C2=A0 The literal actually-in-differe= nt-places kind is categorically different than the much more important, vir= tual impervious-to-coercion kind.=C2=A0 The behavior of the "centraliz= ed" oil cartel is a good example.=C2=A0 The participants cheat.=C2=A0 = This is a fundamental principle in the debate between free-marketeers and a= uthoritarians regarding the emergence of monopoly.=C2=A0 Without coercion, = monopolies fall apart.=C2=A0 There's nothing coercive about our use of = the double-SHA256, so in my mind, the centralization it has so far produced= is not dangerous.=C2=A0 It's scary, sure, but until coercion is used t= o prevent me and my friends from buying our own ASICs, it remains imperviou= s to coercion.

Sorry for the long email that didn't make a= ny apparent progress.=C2=A0 The thinking is what matters to me, and seeing = two kinds of decentralization and recognizing that a change in PoW can be s= low enough to avoid hurting existing miners are items I haven't seen an= yone else recognize, so I had to bring them up.

notplato

On Fri, Oct 2= , 2015 at 9:45 AM, Gregory Maxwell via bitcoin-dev <bi= tcoin-dev@lists.linuxfoundation.org> wrote:

On Fri, Oct 2, 2015 at 8:30 AM, Daniele P= inna via bitcoin-dev
<bitcoin-dev@li= sts.linuxfoundation.org> wrote:
> The recently published paper I referenced cite's the Cuckoo cycle = algorithm,
> discusses its limitations and explains how their proposed algorithm gr= eatly
> improves on it.

They discuss a very old version of the Cuckoo cycle paper, and I
believe none of their analysis is applicable to the most recent
revision. :(

In any case, I commented more about functions of this class here:
https://www.reddit.com/r/Bitcoin/comments/3n5nws/research_paper_asymmetr= ic_proofofwork_based_on/cvl922x

I don't believe changing the POW function is impossible in principle, but I expect it would only happen due to problems with the composition
of current hash-power and not even if it were universally agreed that
some other construction were technically better (though that is a high
bar.)

___________________________________= ____________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev

I like to provide some work at no cha= rge to prove my value. Do you need a techie?=C2=A0
I own Litmocracy and Meme Racing (in alpha).
I= 'm the webmaster for The Voluntaryist which now accepts Bitcoin.
I also code for = The Dollar Vigila= nte.
"He ought to find it more profitable to play by the rules&= quot; - Satoshi Nakamoto

--047d7bdc87aa47bf7c052125f7de-- 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 C556516A0 for ; Fri, 2 Oct 2015 23:19:27 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.help.org (mail.help.org [70.90.2.18]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 458FD1AA for ; Fri, 2 Oct 2015 23:19:27 +0000 (UTC) Received: from [10.1.10.25] (B [10.1.10.25]) by mail.help.org with ESMTPA ; Fri, 2 Oct 2015 19:19:23 -0400 To: bitcoin-dev@lists.linuxfoundation.org References: <201510022131.22411.luke@dashjr.org> From: Milly Bitcoin Message-ID: <560F10EF.8020906@bitcoins.info> Date: Fri, 2 Oct 2015 19:19:11 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <201510022131.22411.luke@dashjr.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Dev-list's stance on potentially altering the PoW algorithm X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 23:19:27 -0000 > Restarting the mining with a new algorithm as a reaction and defence against > centralised hoarding of mining ASICs (as we are seeing now), would be > acceptable. It would not necessarily be contentions *to the economy*, as such > hoarding-miners do not participate in the economy in any meaningful way (they > do not accept payments from other bitcoin users). > > Luke I don't see any basis for these claims. Under this theory developers also do not "participate in the economy" either. These are questions for economists and not developers. Maybe "we" could change the language of Core to prevent the centralization of developers? Maybe switch over to FORTRAN? lol Russ