Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Qu6Vo-0006mF-Aa for bitcoin-development@lists.sourceforge.net; Thu, 18 Aug 2011 17:36:12 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.210.42 as permitted sender) client-ip=209.85.210.42; envelope-from=gavinandresen@gmail.com; helo=mail-pz0-f42.google.com; Received: from mail-pz0-f42.google.com ([209.85.210.42]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Qu6Vn-0001Vu-HD for bitcoin-development@lists.sourceforge.net; Thu, 18 Aug 2011 17:36:12 +0000 Received: by pzk37 with SMTP id 37so3332958pzk.1 for ; Thu, 18 Aug 2011 10:36:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.226.2 with SMTP id y2mr513860wfg.449.1313688965417; Thu, 18 Aug 2011 10:36:05 -0700 (PDT) Received: by 10.142.133.12 with HTTP; Thu, 18 Aug 2011 10:36:05 -0700 (PDT) In-Reply-To: References: <1313681783.14523.79.camel@mei> Date: Thu, 18 Aug 2011 13:36:05 -0400 Message-ID: From: Gavin Andresen To: Gregory Maxwell Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: -1.3 (-) 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 (gavinandresen[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -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 0.3 AWL AWL: From: address is in the auto white-list X-Headers-End: 1Qu6Vn-0001Vu-HD Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] From the forums: one-confirmation attack 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, 18 Aug 2011 17:36:12 -0000 Gregory said: "...if this causes people to wait less than the 6 blocks that the software currently waits for before leaving unconfirmed status then that would be sad." People are already considering transactions 'confirmed enough' at less than six blocks. I'm guilty, too-- 3 is/was the magic number for ClearCoin. And people are already experimenting with ways of safely accepting 0-confirmation transactions, like InstaWallet's "green" payments (sent from a trusted-not-to-double-spend address). Since there is definitely market demand for "as fast as possible" confirmation, I'm thinking adding a placeholder to the RPC interface might be a good idea. Although after thinking about it some more, maybe a signed integer "trust" rating for blocks/transactions would be a better way of doing it... RE: miners connecting themselves together in a semi-trusted "bitcoin backbone" : agreed. Matt submitted a patch to connect and stay-connected to a set of nodes, but I complained about the implementation. Seems to me the networking code needs an overhaul, to implement a priority queue of potential peers (trusted peers would be sorted to near the top of the queue, peers you think are badly-behaved would be sorted to the bottom, with lots of randomness so not everybody on the network is trying to connect to the same set of peers). With peer rotation to mitigate manipulate-time and other Sybil attacks. -- -- Gavin Andresen