From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 11362C0001 for ; Mon, 10 May 2021 15:01:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id E34E140217 for ; Mon, 10 May 2021 15:01:19 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp2.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B35qm66BPlj4 for ; Mon, 10 May 2021 15:01:18 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) by smtp2.osuosl.org (Postfix) with ESMTPS id AB716401CC for ; Mon, 10 May 2021 15:01:18 +0000 (UTC) Received: by mail-wr1-x436.google.com with SMTP id a4so16981615wrr.2 for ; Mon, 10 May 2021 08:01:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Vk9xZU7+Qt5tv4JAgwufE9Rx7h4KR7VN1wKZPirhR8c=; b=P1vPayk7kVICCRNDq3swQn4Tav1t1KvxARye5D/HOvz4JbuNR1YYcj8ma0R9y54DIw goAuBmTo9gClPevIZ0bSIT0gnOaOAWpDHUwunr5ZnVBEmWZtrjvHA5f/MDuKVgscE+pi JpXIXE+IwgkaUrw/OcKHa7aYjTcVFf7MITiA74NqQMAWaZs27Wud3SYWrH8ZYfjPnkb6 G/CjNy0XFYd6u5djp2nwVeTaI9WnRECpvyNNgzOE/Z/um12TDdHsTgMf8zFezb5oPjLG hXuyIiISXtDYm37AjKtuBUuzl30f5OAUvWnuZ4LKklZjpR8VunBfLyPnhF2pouxz0+e0 6gng== 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=Vk9xZU7+Qt5tv4JAgwufE9Rx7h4KR7VN1wKZPirhR8c=; b=V2NcYq7L9/TutIV6RamdwCuzUYMyQN58m5j5mxxOZahRj6fnld7uLF26zv7UQWfJlW 6p0ZcrwK2psakktL/7Z+U1RuoEhbUmvqeb2Yur3A3D5gxaNAFLhwXv8D4lL6LKRFyPK0 9GJhBW2fW2/rZ1mv7lZX622FSWFxhJlP5dtq0da0sK8RfyabMfJoughn4qWmn+WNinAt 15eXxZ1C7EbFERaHigopjRx7BtJ9zvM7kBVH/pGHLkJkNjeiBOzvpORmmD0HPSoseaRd ZK6xTNWo9tBGTnMONK4Q8tzZAoZynDo6a41+uQ3lIM/ypXZmIHbbhErxq4yJmfL6rLdX EQtQ== X-Gm-Message-State: AOAM530G4XI0DKBXNjHYGNy2hhe1A8HvD9UZk1AOR56VovOVELya0/7y 8Dn1IdGxNGBgqF1r+/qQpjxTo8AX+5IhebR02hzJcM1BpFE= X-Google-Smtp-Source: ABdhPJwLMChvd2yHV/D1Ix3S6xuIHLyIOwuhKSrnQURZKEXLA7DxGvQKFJNYoFgu/fVWVV5j2nvkZt3jKsVRNQ+i0/w= X-Received: by 2002:a5d:4d0b:: with SMTP id z11mr31885196wrt.164.1620658876433; Mon, 10 May 2021 08:01:16 -0700 (PDT) MIME-Version: 1.0 References: <6do5xN2g5LPnFeM55iJ-4C4MyXOu_KeXxy68Xt4dJQMhi3LJ8ZrLICmEUlh8JGfDmsDG12m1JDAh0e0huwK_MlyKpdfn22ru3zsm7lYLfBo=@protonmail.com> In-Reply-To: From: Keagan McClelland Date: Mon, 10 May 2021 09:01:05 -0600 Message-ID: To: Bitcoin Protocol Discussion , Erik Aronesty Content-Type: multipart/alternative; boundary="000000000000a1ca4e05c1fb0ca2" X-Mailman-Approved-At: Mon, 10 May 2021 18:56:26 +0000 Cc: SatoshiSingh Subject: Re: [bitcoin-dev] Opinion on proof of stake in future X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2021 15:01:20 -0000 --000000000000a1ca4e05c1fb0ca2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable To reiterate some of the points here. My problem with proof of stake is twofold. 1. It requires permission of coin holders to enter into the system. This is not true of proof of work. You may even attempt (though not successfully) a proof of work with pencil and paper and submit the block from a regular laptop if you so choose. Whether this level of permissionlessness is necessary is up to individual risk tolerance etc. but it is definitely the default preference of Bitcoin. 2. Proof of stake must have a trusted means of timestamping to regulate overproduction of blocks. This introduction of trust is generally considered to be a nonstarter in Bitcoin. Proof of Work regulates this by making blocks fundamentally difficult to produce in the first place. Like Jeremy, I=E2=80=99m always interested to learn about new attempts in c= onsensus algorithms, but the bar to clear is very high and proof of stake to date has not proposed much less demonstrated a set of properties that is consistent with Bitcoins objectives. Keagan On Mon, May 10, 2021 at 8:43 AM Erik Aronesty via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > personally, not speaking for anyone else, i think that proof-of-burn > has a much higher likelihood of being a) good enough security and b) > solving the nothing-at-stake problem > > the only issue i see with a quality PoB implementation is a robust > solution to the block-timing problem. > > https://grisha.org/blog/2018/01/23/explaining-proof-of-work/ > > i do think there *could* be other low-energy solutions to verifiable > timing, just haven't seen one > > > On Fri, May 7, 2021 at 6:50 PM SatoshiSingh via bitcoin-dev > wrote: > > > > Hello list, > > > > I am a lurker here and like many of you I worry about the energy usage > of bitcoin mining. I understand a lot mining happens with renewable > resources but the impact is still high. > > > > I want to get your opinion on implementing proof of stake for bitcoin > mining in future. For now, proof of stake is still untested and not battl= e > tested like proof of work. Though someday it will be. > > > > In the following years we'll be seeing proof of stake being implemented= . > Smaller networks can test PoS which is a luxury bitcoin can't afford. > Here's how I see this the possibilities: > > > > 1 - Proof of stake isn't a good enough security mechanism > > 2 - Proof of state is a good security mechanism and works as intended > > > > IF PoS turns out to be good after battle testing, would you consider > implementing it for Bitcoin? I understand this would invoke a lot of > controversies and a hard fork that no one likes. But its important enough > to consider a hard fork. What are your opinions provided PoS does work? > > > > Love from India. > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000a1ca4e05c1fb0ca2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To reiterate some of the points here. My problem with pro= of of stake is twofold.=C2=A0

1. It requires permission of coin holders to enter into the system. T= his is not true of proof of work. You may even attempt (though not successf= ully) a proof of work with pencil and paper and submit the block from a reg= ular laptop if you so choose. Whether this level of permissionlessness is n= ecessary is up to individual risk tolerance etc. but it is definitely the d= efault preference of Bitcoin.

2. Proof of stake must have a trusted means of timestamping to regula= te overproduction of blocks. This introduction of trust is generally consid= ered to be a nonstarter in Bitcoin. Proof of Work regulates this by making = blocks fundamentally difficult to produce in the first place.

Like Jeremy, I=E2=80=99m always inter= ested to learn about new attempts in consensus algorithms, but the bar to c= lear is very high and proof of stake to date has not proposed much less dem= onstrated a set of properties that is consistent with Bitcoins objectives.<= /div>

Keagan

On Mon, May 1= 0, 2021 at 8:43 AM Erik Aronesty via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
personally, not speaking for anyone = else, i think that proof-of-burn
has a much higher likelihood of being a) good enough security and b)
solving the nothing-at-stake problem

=C2=A0the only issue i see with a quality PoB implementation is a robust solution to the block-timing problem.

https://grisha.org/blog/2018/01/23/expla= ining-proof-of-work/

i do think there *could* be other low-energy solutions to verifiable
timing, just haven't seen one


On Fri, May 7, 2021 at 6:50 PM SatoshiSingh via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Hello list,
>
> I am a lurker here and like many of you I worry about the energy usage= of bitcoin mining. I understand a lot mining happens with renewable resour= ces but the impact is still high.
>
> I want to get your opinion on implementing proof of stake for bitcoin = mining in future. For now, proof of stake is still untested and not battle = tested like proof of work. Though someday it will be.
>
> In the following years we'll be seeing proof of stake being implem= ented. Smaller networks can test PoS which is a luxury bitcoin can't af= ford. Here's how I see this the possibilities:
>
> 1 - Proof of stake isn't a good enough security mechanism
> 2 - Proof of state is a good security mechanism and works as intended<= br> >
> IF PoS turns out to be good after battle testing, would you consider i= mplementing it for Bitcoin? I understand this would invoke a lot of controv= ersies and a hard fork that no one likes. But its important enough to consi= der a hard fork. What are your opinions provided PoS does work?
>
> Love from India.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000a1ca4e05c1fb0ca2--