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-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WdM9z-0006Ph-6D for bitcoin-development@lists.sourceforge.net; Thu, 24 Apr 2014 16:06:03 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.223.169 as permitted sender) client-ip=209.85.223.169; envelope-from=christophe.biocca@gmail.com; helo=mail-ie0-f169.google.com; Received: from mail-ie0-f169.google.com ([209.85.223.169]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WdM9x-0006F8-GG for bitcoin-development@lists.sourceforge.net; Thu, 24 Apr 2014 16:06:03 +0000 Received: by mail-ie0-f169.google.com with SMTP id to1so2617688ieb.0 for ; Thu, 24 Apr 2014 09:05:56 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.43.75.2 with SMTP id yy2mr2779637icb.54.1398355556138; Thu, 24 Apr 2014 09:05:56 -0700 (PDT) Received: by 10.64.102.136 with HTTP; Thu, 24 Apr 2014 09:05:55 -0700 (PDT) In-Reply-To: <20140424150337.GA24314@savin> References: <20140424134441.GE16884@savin> <20140424150337.GA24314@savin> Date: Thu, 24 Apr 2014 12:05:55 -0400 Message-ID: From: Christophe Biocca Cc: Bitcoin Dev Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.4 (/) 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 (christophe.biocca[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.2 MISSING_HEADERS Missing To: header -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: 1WdM9x-0006F8-GG 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 16:06:03 -0000 > Casting that vote does them no harm. > Every time another pool joins the blacklist, there's no harm to them to doing so. I actually agree that this is a problem, but that's actually not inherent in the proposed enforcement mechanism (just the current voting rules). Here's an alternate: - To start a vote, you set aside a part of your coinbase with amount X <= their entire coinbase amount. - Then you need 51 blocks with a "yes" vote before the coinbase maturity of the target for the vote to be considered a success. - Success means target coinbase has X coins reallocated/burned. - Failure means vote-initiating coinbase has X coins reallocated/burned. The incentives for voting miners are to vote yes if and only if they dislike the targeted miner more than the initiator (all other monetary effects are identical). That isn't a bulletproof way to force miners to only punish double spenders (rather than anything they dislike in general), but it removes the risk free nature of trying to take away another miner's coinbase. It means that you'll need a high level of confidence other miners are on your side before taking a risk, but, because you've got a much longer time frame than 10 minutes, you can get manual confirmation from other miners. On Thu, Apr 24, 2014 at 11:03 AM, Peter Todd wrote: > On Thu, Apr 24, 2014 at 10:47:35AM -0400, Christophe Biocca wrote: >> Actually Peter, coinbase confiscations are a much worse mechanism for >> enforcement of widespread censorship rules than simple orphaning. They >> lose their power when the transaction miners are punished for can >> build up over time without losing their usefulness: > >> Of course, in such a dystopian future, orphaning would be the >> enforcement mechanism. It would be stupid to rely on coinbase >> reallocation/burning to do this task when the existing tools work so >> much better. > > I don't disagree with you at an end stage, but the thing with coinbase > blacklists/confiscation is because it's a voting mechanism the initial > stages of enforcing widespread censorship rules with it are much easier. > For instance, if a 10% pool that has been forced/wants to blacklist > certain transactions can do so, and then vote to blacklist blocks that > do not abide by that blacklist. Casting that vote does them no harm. > Every time another pool joins the blacklist, there's no harm to them to > doing so. At some point they will reach a majority, which causes the > blacklist to actually apply. The whole process happens smoothly, letting > the blacklist be applied safely and easily. With orphaning/reorging on > the other hand you just can't be sure that the other miners will > actually adopt it, making adoption risky. > > Of course, that's above and beyond the fact that you can't prove a > Finney attack happened to a third-party, making it easy to attack > smaller miners with Sybil attacks, get them creating blocks with > double-spends in them, and using that as an excuse to punish them. > >> What's interesting is that this mechanism is especially tailored to >> blocking time sensitive transactions (that need to be confirmed >> now/soon, or are worthless), such that their total out-of-band fees >> can't build up over time. Double spending is one such category. I'm at >> a loss to come up with something else, but maybe someone has a good >> example? > > Decentralized markets are a great example: the bids and orders they > depend on are time-senstive and become much less valuable if they get > delayed greatly. > > -- > 'peter'[:-1]@petertodd.org > 0000000000000000091ae589c034bc0466e2feca51dc018bb2c3303e8ab8648b