From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Wd2ND-00068E-0b for bitcoin-development@lists.sourceforge.net; Wed, 23 Apr 2014 18:58:23 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.216.41 as permitted sender) client-ip=209.85.216.41; envelope-from=tier.nolan@gmail.com; helo=mail-qa0-f41.google.com; Received: from mail-qa0-f41.google.com ([209.85.216.41]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Wd2NB-0007Ac-Vb for bitcoin-development@lists.sourceforge.net; Wed, 23 Apr 2014 18:58:22 +0000 Received: by mail-qa0-f41.google.com with SMTP id j5so1262266qaq.14 for ; Wed, 23 Apr 2014 11:58:16 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.224.125.74 with SMTP id x10mr22343806qar.99.1398279496492; Wed, 23 Apr 2014 11:58:16 -0700 (PDT) Received: by 10.140.25.86 with HTTP; Wed, 23 Apr 2014 11:58:16 -0700 (PDT) In-Reply-To: References: <5357D394.7010908@gmail.com> <5357F634.2070300@gmail.com> <5357FD32.40200@gmail.com> <535800C1.9060604@gmail.com> <20140423181545.GA5434@savin> <53580452.3030705@gmail.com> Date: Wed, 23 Apr 2014 19:58:16 +0100 Message-ID: From: Tier Nolan To: Bitcoin Dev Content-Type: multipart/alternative; boundary=001a11c30886af6a0904f7ba5038 X-Spam-Score: -0.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 (tier.nolan[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -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: 1Wd2NB-0007Ac-Vb Subject: Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks 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: Wed, 23 Apr 2014 18:58:23 -0000 --001a11c30886af6a0904f7ba5038 Content-Type: text/plain; charset=UTF-8 Bitcoin has various checks and balances that help keep everything honest. Even if a pool had 60% of the hashing power, they couldn't reverse 6 blocks without anyone noticing that it had happened. There are sites which monitor the blocks and estimate the percentage of the blocks found by each pool. In a way, bitcoin doesn't depend on the majority of miners following the protocol, it depends on miners believing that a majority of the other miners will follow the protocol. If a miner has 5% of the hashing power and believes that the other 95% will follow the protocol, then the system should be set up so that it is in that miner's interests to follow the protocol too. This is why soft forks work. The formal process convinces all the miners that the new rules are locked in. In a system where miners can vote to cancel coinbases, each pool has an incentive to vote to reject everyone else's blocks. Pools on the receiving end will be less profitable and lose customers. It is possible that "predatory" pools would lose hashing power as miners switch to other pools, in protest. The proposal allows "established" pools to vote to disallow new entrants. They could even justify it by saying that those pools haven't invested in "anti-double spending" infrastructure. The proposal doesn't suddenly give the majority the ability to do it, but it isn't clear that making the process less disruptive is a good thing. On Wed, Apr 23, 2014 at 7:37 PM, Mike Hearn wrote: > If you want to try and argue that the development list is the wrong place > to discuss development, please do so on another thread (or your blog). > Let's keep this thread for discussion of the original proposal - ideally, > discussed with the dryness that a topic as nerdy as distributed consensus > algorithms deserves ;) > > > ------------------------------------------------------------------------------ > 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 > > --001a11c30886af6a0904f7ba5038 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Bitcoin has various checks and balances tha= t help keep everything honest.

Even if a pool had 60% of the h= ashing power, they couldn't reverse 6 blocks without anyone noticing th= at it had happened.

There are sites which monitor the blocks and estimate the percent= age of the blocks found by each pool.

In a way= , bitcoin doesn't depend on the majority of miners following the protoc= ol, it depends on miners believing that a majority of the other miners will= follow the protocol.

If a miner has 5% of the hashing power and believes that the= other 95% will follow the protocol, then the system should be set up so th= at it is in that miner's interests to follow the protocol too.

This is why soft forks work.=C2=A0 The formal process convinces = all the miners that the new rules are locked in.

In a system where miners can vote to cancel coinbases, each pool has an = incentive to vote to reject everyone else's blocks.

Pools on the receiving end will be less profitable and lose = customers.

It is possible that "predatory" pool= s would lose hashing power as miners switch to other pools, in protest.

The proposal allows "established" pools to vote to= disallow new entrants.=C2=A0 They could even justify it by saying that tho= se pools haven't invested in "anti-double spending" infrastru= cture.

The proposal doesn't suddenly give the majority the abil= ity to do it, but it isn't clear that making the process less disruptiv= e is a good thing.



On Wed, Apr 23, 2014 at 7:37 PM, Mike He= arn <mike@plan99.net> wrote:
If you want to try and argue that the development list is = the wrong place to discuss development, please do so on another thread (or = your blog). Let's keep this thread for discussion of the original propo= sal - ideally, discussed with the dryness that a topic as nerdy as distribu= ted consensus algorithms deserves ;)

-----------------------------------------------------------------------= -------
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.n= et/sfu/ExoPlatform
_______________________________________________ Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--001a11c30886af6a0904f7ba5038--