From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WdGOL-0002ax-EI for bitcoin-development@lists.sourceforge.net; Thu, 24 Apr 2014 09:56:29 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.170 as permitted sender) client-ip=209.85.214.170; envelope-from=mh.in.england@gmail.com; helo=mail-ob0-f170.google.com; Received: from mail-ob0-f170.google.com ([209.85.214.170]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WdGOK-0006zZ-H6 for bitcoin-development@lists.sourceforge.net; Thu, 24 Apr 2014 09:56:29 +0000 Received: by mail-ob0-f170.google.com with SMTP id vb8so2423145obc.29 for ; Thu, 24 Apr 2014 02:56:23 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.132.75 with SMTP id os11mr697149oeb.70.1398333383225; Thu, 24 Apr 2014 02:56:23 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.96.180 with HTTP; Thu, 24 Apr 2014 02:56:23 -0700 (PDT) In-Reply-To: References: Date: Thu, 24 Apr 2014 11:56:23 +0200 X-Google-Sender-Auth: FFLPz7LTqPsAAVd1IxRRksxFk50 Message-ID: From: Mike Hearn To: Gregory Maxwell Content-Type: multipart/alternative; boundary=047d7b471e7095b8c504f7c6dcd4 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: 1WdGOK-0006zZ-H6 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 09:56:29 -0000 --047d7b471e7095b8c504f7c6dcd4 Content-Type: text/plain; charset=UTF-8 > > Yes, you can reorg out the blocks and actually remove them, but I > understood that you were _not_ proposing that quite specifically. But > instead proposed without reorging taking txouts that were previously > assigned to one party and simply assigning them to others. > Well, my original thought was just to delete the coinbases. But then some people don't like the idea of destroying money (equivalently, reducing the system's resolution) so I proposed reallocating it instead. I'm not sure which is better though. Deletion is closer to what the existing system allows, for sure. Would you feel differently if the consequence was UTXO deletion rather than reallocation? I think the difference makes no impact to the goal of discouraging double spending. > ... proposing the mechanism be used to claw back mining income from a > hardware vendor accused of violating its agreements on the amount of > self mining / mining on customers hardware. > I think this would not be doable in practice, unless there was a way to identify that a block was mined with pre-sold equipment. Peter points out that the pool in question is marking their blocks by reusing addresses - ditto for the double spending against dice sites - but that's a trivial thing for them to fix. Then it'd be difficult (impossible?) for miners to identify KnC blocks even if there was a strong majority consensus to delete their coinbases. The reason I think this particular change is doable is that it should be possible to quite reliably identify blocks that are Finney attacking for profit. That doesn't generalise to any policy though. Blocks are intended to be structurally identical to each other if best practices are followed and even with the dire pool situation a big chunk of mining hash power today is effectively anonymous. --047d7b471e7095b8c504f7c6dcd4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, you can reorg out the blocks and actually r= emove them, but I
understood that you were _not_ proposing that quite specifically. But
instead proposed without reorging taking txouts that were previously
assigned to one party and simply assigning them to others.
=

Well, my original thought was just to delete the coinba= ses. But then some people don't like the idea of destroying money (equi= valently, reducing the system's resolution) so I proposed reallocating = it instead. I'm not sure which is better though. Deletion is closer to = what the existing system allows, for sure.

Would you feel differently if the consequence was UTXO = deletion rather than reallocation? I think the difference makes no impact t= o the goal of discouraging double spending.
=C2=A0
... proposing the mechanism be used to claw back mining inc= ome from a
hardware vendor accused of violating its agreements on the amount of
self mining / mining on customers hardware.

=
I think this would not be doable in practice, unless there was a way t= o identify that a block was mined with pre-sold equipment. Peter points out= that the pool in question is marking their blocks by reusing addresses - d= itto for the double spending against dice sites - but that's a trivial = thing for them to fix. Then it'd be difficult (impossible?) for miners = to identify KnC blocks even if there was a strong majority consensus to del= ete their coinbases.

The reason I think this particular change is doable is = that it should be possible to quite reliably identify blocks that are Finne= y attacking for profit. That doesn't generalise to any policy though. B= locks are intended to be structurally identical to each other if best pract= ices are followed and even with the dire pool situation a big chunk of mini= ng hash power today is effectively anonymous.


--047d7b471e7095b8c504f7c6dcd4--