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-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WdFC8-0005A5-EK for bitcoin-development@lists.sourceforge.net; Thu, 24 Apr 2014 08:39:48 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.178 as permitted sender) client-ip=209.85.214.178; envelope-from=mh.in.england@gmail.com; helo=mail-ob0-f178.google.com; Received: from mail-ob0-f178.google.com ([209.85.214.178]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WdFC7-0007Z2-9Y for bitcoin-development@lists.sourceforge.net; Thu, 24 Apr 2014 08:39:48 +0000 Received: by mail-ob0-f178.google.com with SMTP id wn1so2342180obc.9 for ; Thu, 24 Apr 2014 01:39:42 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.142.229 with SMTP id rz5mr479655obb.12.1398328781981; Thu, 24 Apr 2014 01:39:41 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.96.180 with HTTP; Thu, 24 Apr 2014 01:39:41 -0700 (PDT) In-Reply-To: References: Date: Thu, 24 Apr 2014 10:39:41 +0200 X-Google-Sender-Auth: TV3-HSS58ZxJldHVemZOQJ8GCVY Message-ID: From: Mike Hearn To: Gregory Maxwell Content-Type: multipart/alternative; boundary=001a11c362e654509804f7c5caab X-Spam-Score: -0.5 (/) 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 (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 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: 1WdFC7-0007Z2-9Y Cc: Bitcoin Dev 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: Thu, 24 Apr 2014 08:39:48 -0000 --001a11c362e654509804f7c5caab Content-Type: text/plain; charset=UTF-8 On Thu, Apr 24, 2014 at 10:19 AM, Gregory Maxwell wrote: > This is not voting. > It absolutely is! It was widely discussed as such at the time, here is a thread where people ask how to vote and the operator of Eclipse said he was removing his vote for P2SH: https://bitcointalk.org/index.php?topic=60937.0 You might not feel it's a particularly fair or representative vote, but it's still miners saying "I support enforcement of this new rule" or "I do not support this" where the majority of cast votes wins. Some miners have more votes than others, but it's still a vote. > Yes, making really distributed systems that work in a complex world is > hard. It certantly would be /easier/ to just declare miners "trusted > parties" > Miners *are* trusted parties, they are just not all trusted simultaneously. Bitcoin can tolerate a small number of dishonest miners whilst producing a degraded service. It cannot work if all miners are dishonest or decide to deviate from their intended operation, like if they all produce empty blocks. The white paper made this clear from the start, and it's also common sense. Allowing the majority of honest miners to keep the dishonest ones in check is what Bitcoin is all about. I don't understand this view that a very small change to the existing protocol is somehow terrible or impossible, but expecting everyone to simply build an entirely new system from scratch is easy and inevitable. I'd much prefer to just keep the existing system working as well as it has so far, and I think that is true of most users too. > Temporarily censoring transactions by orphaning otherwise valid blocks > that contain them for as long as you retain a majority is possible No, coinbases are deletable. If some miners fork the chain and build a longer one, the others will all switch to it and the coinbases blocks they previously mined will never become spendable (effectively they were "deleted" before maturity). Only if the other miners also blacklist the majorities fork and never join it, then the majority for some reason gives up and rejoins the minority, is what you described correct. But why would they do that? If they're the majority then all the other nodes will follow them. They have no incentive to throw away their fork and rejoin the minority chain ever again. I think the root of this disagreement is whether the block chain algorithm left by Satoshi is somehow immutable and itself the end, or whether it's (as I see it) just a means to an end and therefore an algorithm that can be tweaked and improved, to get us closer to the goal. If the end is a useful payments system, as decentralised as possible, that prevents double spending, then this proposal is a simple enhancement of the current system that ensures corrupt miners don't get paid by honest users for services they didn't provide, thus discouraging a particular kind of attack. --001a11c362e654509804f7c5caab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Apr 24, 2014 at 10:19 AM, Gregory Maxwell <gmaxwell@gmail.com>= wrote:
This is not voting.
=

It absolutely is! It was widely discussed as such at the tim= e, here is a thread where people ask how to vote and the operator of Eclips= e said he was removing his vote for P2SH:


You might not feel it's a particularly fair o= r representative vote, but it's still miners saying "I support enf= orcement of this new rule" or "I do not support this" where = the majority of cast votes wins. Some miners have more votes than others, b= ut it's still a vote.
=C2=A0
Yes= , making really distributed systems that work in a complex world is
hard. It certantly would be /easier/ to just declare miners "trusted parties"

Miners are=C2=A0tr= usted parties, they are just not all=C2=A0trusted simultaneously. Bitcoin c= an tolerate a small number of dishonest miners whilst producing a degraded = service. It cannot work if all miners are dishonest or decide to deviate fr= om their intended operation, like if they all produce empty blocks. The whi= te paper made this clear from the start, and it's also common sense.

Allowing the majority of honest miners to keep the dish= onest ones in check is what Bitcoin is all about. I don't understand th= is view that a very small change to the existing protocol is somehow terrib= le or impossible, but expecting everyone to simply build an entirely new sy= stem from scratch is easy and inevitable. I'd much prefer to just keep = the existing system working as well as it has so far, and I think that is t= rue of most users too.
=C2=A0
Temporarily censoring transactions by orphaning otherwise v= alid blocks
that contain them for as long as you retain a majority is possible

No, coinbases are deletable. If some miners fork th= e chain and build a longer one, the others will all switch to it and the co= inbases blocks they previously mined will never become spendable (effective= ly they were "deleted" before maturity). Only if the other miners= also blacklist the majorities fork and never join it, then the majority fo= r some reason gives up and rejoins the minority, is what you described corr= ect. But why would they do that? If they're the majority then all the o= ther nodes will follow them. They have no incentive to throw away their for= k and rejoin the minority chain ever again.

I think the root of this disagreement is whether the bl= ock chain algorithm left by Satoshi is somehow immutable and itself the end= , or whether it's (as I see it) just a means to an end and therefore an= algorithm that can be tweaked and improved, to get us closer to the goal.<= /div>

If the end is a useful payments system, as decentralise= d as possible, that prevents double spending, then this proposal is a simpl= e enhancement of the current system that ensures corrupt miners don't g= et paid by honest users for services they didn't provide, thus discoura= ging a particular kind of attack.
--001a11c362e654509804f7c5caab--