From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WdI7U-0007MN-4H for bitcoin-development@lists.sourceforge.net; Thu, 24 Apr 2014 11:47:12 +0000 Received: from mail-oa0-f49.google.com ([209.85.219.49]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WdI7S-0001sa-8X for bitcoin-development@lists.sourceforge.net; Thu, 24 Apr 2014 11:47:12 +0000 Received: by mail-oa0-f49.google.com with SMTP id o6so2441034oag.8 for ; Thu, 24 Apr 2014 04:47:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=f56UfBoneh0X+wb40lfl4phH+3JEqq3iDti72sYwrFU=; b=V8dMHpi9YEn/KYnw+UmaEnTUoSaGBZ8gqtwZodG4P/zQcyo/GhkJz3bMZJfOdTgqw+ zQBQZlWxRb8CafQlwGAT3R2G4gNlnJzRz6mx8LD2RR5nbMFAy9a8EKAm9VEFyDW8oKA1 Lrr6cuxT3YFS6oO1lCQsXeuCpoS0lhPSzN/evcR47GqOEbQXSMhqIBF/kqjLma2o82jD ZgjLdMU2yXrfcqZGUdh6PQDI0KE52o9fY4svwKWCaXk7PdAOVvAzdlqxXApSjXwQ9GLX oxg7ebB++8QpLlvo/75nXTiYbPja8GcujlCL5ILjkkhVuXSN8Fomv7de2GIdE3HQc5np /fKw== X-Gm-Message-State: ALoCoQm/yspiRhqPIHULGxo2OpjkSryzPww+Po7qLzjDZEETB8qcGQv5MFtotoVt9bMAyGXUp+HZ MIME-Version: 1.0 X-Received: by 10.60.77.35 with SMTP id p3mr906228oew.46.1398336534373; Thu, 24 Apr 2014 03:48:54 -0700 (PDT) Received: by 10.76.114.193 with HTTP; Thu, 24 Apr 2014 03:48:54 -0700 (PDT) X-Originating-IP: [85.59.56.59] Date: Thu, 24 Apr 2014 12:48:54 +0200 Message-ID: From: =?ISO-8859-1?Q?Jorge_Tim=F3n?= To: Bitcoin Development Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1WdI7S-0001sa-8X Subject: [Bitcoin-development] 0 confirmation txs using replace-by-fee and game theory 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 11:47:12 -0000 Here is a solution to the problem of having 0 confirmation transactions that relies on game theory and most miners implementing replace-by-fee and child-pays-for-paren= t. This has been proposed before http://sourceforge.net/p/bitcoin/mailman/message/30876033/ I'm just going to describe the general idea in more detail. Here's a small draft on how this could work: Alice goes to Bob's store and wants to buy something cheaper than a car, say a smartphone. So Bob says, "it's 200 usd in btc, please pay me 400 usd in btc" So Alice signs a tx with 400 and no fee with her old phone and she just sends it to Bob rather than the network. Bob creates a child transaction keeping 200 and giving 199.9 (0.1 usd fee) back to Alice. But you know, Alice wants to double spend. She double spends 399.8 to herself (0.2 fee) Bob thinks "last chance", he double-spends the child: 200 to Bob, back 199 to Alice (1 usd fee). Alice is stubborn: 398 to Alice (2 usd fee). Bob is really pissed off, double spends the child: 400 in fees. So, ok, Bob lost the phone and got nothing but Alice has paid twice as she needed for the phone. Nobody's happy thus everybody's happy. This is similar to the general game theory "stag hunt" case. The payoff matrix could be something like this: Bob returns change Bob burns in fees ---------------------+--------------------+------------------- Alice behaves + 1 , + 1 - 1, + 1 ---------------------+--------------------+------------------- Alice double-spends + 3, - 1 - 1, - 1 The game has two Nash equilibria, but cooperation is Pareto efficient. Replace-by-fee and child-pays-for parent cannot be prohibited by a protocol rule. I believe all miners will eventually implement these policies because it is the more rational way for them to prioritize transactions. Finally I hope they do because it would make 0-confirmation transactions possible as described in this post. So I can't find any reasoning against replace-by-fee unless my example is terribly flawed. Am I missing something? --=20 Jorge Tim=F3n http://freico.in/