Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WeEPo-0005SM-Ez for bitcoin-development@lists.sourceforge.net; Sun, 27 Apr 2014 02:02:00 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.223.172 as permitted sender) client-ip=209.85.223.172; envelope-from=gacrux@gmail.com; helo=mail-ie0-f172.google.com; Received: from mail-ie0-f172.google.com ([209.85.223.172]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WeEPn-0007I6-A1 for bitcoin-development@lists.sourceforge.net; Sun, 27 Apr 2014 02:02:00 +0000 Received: by mail-ie0-f172.google.com with SMTP id at1so1876231iec.31 for ; Sat, 26 Apr 2014 19:01:54 -0700 (PDT) X-Received: by 10.50.112.167 with SMTP id ir7mr14801104igb.27.1398564113988; Sat, 26 Apr 2014 19:01:53 -0700 (PDT) Received: from [192.168.1.2] (60-240-212-53.tpgi.com.au. [60.240.212.53]) by mx.google.com with ESMTPSA id rt10sm11343204igb.15.2014.04.26.19.01.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 26 Apr 2014 19:01:53 -0700 (PDT) User-Agent: K-9 Mail for Android In-Reply-To: <535C5BBF.30709@monetize.io> References: <1398382335.20219.YahooMailNeo@web160503.mail.bf1.yahoo.com> <20140425073334.GV3180@nl.grid.coop> <535C1980.7000505@monetize.io> <535C5BBF.30709@monetize.io> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Gareth Williams Date: Sun, 27 Apr 2014 12:01:44 +1000 To: bitcoin-development@lists.sourceforge.net Message-ID: <3b9c0704-32da-4b83-844f-7fa2d685f538@email.android.com> X-Spam-Score: -1.6 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (gacrux[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1WeEPn-0007I6-A1 Subject: Re: [Bitcoin-development] Proof-of-Stake branch? X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2014 02:02:00 -0000 Who said anything about a re-org? The original block remains valid, your block reward is just zero, upon maturity, in light of a valid fraud proof. ie. the "coinbase confiscation" that I was just arguing against in another thread :P but of course here based on cryptographic proof, not human judgement. On 27 April 2014 11:22:07 AM AEST, Mark Friedenbach wrote: >That makes double-spends trivially easy: sign two blocks, withholding >one. Then at a later point in time reveal the second signed block >(demonstrating your own fraud) and force a reorg. > >On 04/26/2014 04:44 PM, Gareth Williams wrote: >> What about using fraud proofs? Your coinbase only matures if nobody >publishes proof that you signed a competing block. >> >> Then something is at least at stake. When it's your chance to sign a >block, attempting to sign and publish more than one at the same height >reliably punishes you (you effectively waste your chance and receive no >reward.) >> >> I can't remember who I saw discussing this idea. Might have been >Vitalik Buterin? >> >> On 27 April 2014 6:39:28 AM AEST, Mark Friedenbach >wrote: >>> There's no need to be confrontational. I don't think anyone here >>> objects >>> to the basic concept of proof-of-stake. Some people, myself >included, >>> have proposed protocols which involve some sort of proof of stake >>> mechanism, and the idea itself originated as a mechanism for >>> eliminating >>> checkpoints, something which is very much on topic and of concern to >>> many here. >>> >>> The problems come when one tries to *replace* proof-of-work mining >with >>> proof-of-stake "mining." You encounter problems related to the fact >>> that >>> with proof-of-stake nothing is actually at stake. You are free to >sign >>> as many different forks as you wish, and worse have incentive to do >so, >>> because whatever fork does win, you want it to be yours. In the >worst >>> case this results in double-spends at will, and in the best case >with >>> any of the various proposed protections deployed, it merely reduces >to >>> proof-of-work as miners grind blocks until they find one that names >>> them >>> or one of their sock puppets as the signer of the next block. >>> >>> I sincerely doubt you will find a solution to this, as it appears to >be >>> a fundamental issue with proof-of-stake, in that it must leverage an >>> existing mechanism for enforced scarcity (e.g. proof-of-work) in >order >>> to work in a consensus algorithm. Is there some solution that you >have >>> in mind for this? >>> >>> Mark >>> >>> On 04/25/2014 12:33 AM, Troy Benjegerdes wrote: >>>> Do it. Someone will scream harm. The loudest voices screaming how >it >>> would >>>> be harmful are doing the most harm. >>>> >>>> The only way to know is build it, and test it. If the network >breaks, >>> then >>>> it is better we find out sooner rather than later. >>>> >>>> My only suggestion is call it 'bitstake' or something to clearly >>> differentiate >>>> it from Bitcoin. This also might be an interesting application of >the >>> side >>>> chains concept Peter Todd has discussed. >>>> >>>> On Thu, Apr 24, 2014 at 04:32:15PM -0700, Stephen Reed wrote: >>>>> Hello all. >>>>> >>>>> I understand that Proof-of-Stake as a replacement for >Proof-of-Work >>> is a prohibited yet disputed change to Bitcoin Core. I would like to >>> create a Bitcoin branch that provides a sandboxed testbed for >>> researching the best PoS implementations. In the years to come, >perhaps >>> circumstances might arise, such as shifting of user opinion as to >>> whether PoS should be moved from the prohibited list to the >hard-fork >>> list. >>>>> ----- >>>>> >>>>> A poll I conducted today on bitcointalk, >>> https://bitcointalk.org/index.php?topic=581635.0 with an >>> attention-grabbing title suggests some minority support for Bitcoin >>> Proof-of-Stake. I invite any of you to critically comment on that >>> thread. >>>>> >>>>> "Annual 10% bitcoin dividends can be ours if Proof-of-Stake full >>> nodes outnumber existing Proof-of-Work full nodes by three-to-one. >What >>> is your choice?" >>>>> >>>>> "I do not care or do not know enough." - 5 (16.1%) >>>>> "I would download and run the existing Proof-of-Work program to >>> fight the change." - 14 (45.2%) >>>>> "I would download and run the new Proof-of-Stake program to favor >>> the change. " - 12 (38.7%) >>>>> Total Voters: 31 >>>>> ----- >>>>> >>>>> Before I branch the source code and learn the proper way of doing >>> things in this community, I ask you simply if creating the branch is >>> harmful? My goal is to develop, test and document PoS, while >exploring >>> its vulnerabilities and fixing them in a transparent fashion. >>>>> >>>>> Thanks for taking a bit of your time to read this message. >>>> >>>> >>>> >>>> >>> >>> >------------------------------------------------------------------------------ >>> Start Your Social Network Today - Download eXo Platform >>> Build your Enterprise Intranet with eXo Platform Software >>> Java Based Open Source Intranet - Social, Extensible, Cloud Ready >>> Get Started Now And Turn Your Intranet Into A Collaboration Platform >>> http://p.sf.net/sfu/ExoPlatform >>> _______________________________________________ >>> Bitcoin-development mailing list >>> Bitcoin-development@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> > >------------------------------------------------------------------------------ >Start Your Social Network Today - Download eXo Platform >Build your Enterprise Intranet with eXo Platform Software >Java Based Open Source Intranet - Social, Extensible, Cloud Ready >Get Started Now And Turn Your Intranet Into A Collaboration Platform >http://p.sf.net/sfu/ExoPlatform >_______________________________________________ >Bitcoin-development mailing list >Bitcoin-development@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Sent from my Android device with K-9 Mail. Please excuse my brevity.