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-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Uei1W-0001kE-Qy for bitcoin-development@lists.sourceforge.net; Tue, 21 May 2013 08:34:22 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of robbak.com designates 209.85.128.178 as permitted sender) client-ip=209.85.128.178; envelope-from=robbak@robbak.com; helo=mail-ve0-f178.google.com; Received: from mail-ve0-f178.google.com ([209.85.128.178]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Uei1V-0000wg-Pq for bitcoin-development@lists.sourceforge.net; Tue, 21 May 2013 08:34:22 +0000 Received: by mail-ve0-f178.google.com with SMTP id d10so230033vea.37 for ; Tue, 21 May 2013 01:34:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=M7OQbFXdu04UkGuxe6lxGyGk0ReWrj6mSwlEoyp8PR8=; b=ZIOat5GNRjUsH5GHRij9UjvgZ59+Ox0w3EIagJr+enEZbm5SW9LlVRgTTldA9MLK02 kS7Ms6sk0GX56DTrH5kmPpnvM9KjCtuE2JbR+Z3CYMUOIDT/iHUwAbFBINalKY+Bp7mx lDMA2fe5yeRoiY6PySEnB3ffOqZj9PIVoRd2iCCOy9YpR23TPiUUiu/GPHhvJFSp47K5 7dHxtV4QHo4csjSYem9H8/CSuQ1k9v0XkP0IknKAALigqMKQvEu3Um1WpZpQDS/28wo6 dsAOSQ1J3vDCtqKU6AcLhlntzHWPJlzrJXUB+IOc3g/M99C903EHQiq17yUSV6vOfMSK /czQ== MIME-Version: 1.0 X-Received: by 10.52.95.227 with SMTP id dn3mr373643vdb.111.1369123685110; Tue, 21 May 2013 01:08:05 -0700 (PDT) Received: by 10.52.88.172 with HTTP; Tue, 21 May 2013 01:08:04 -0700 (PDT) In-Reply-To: References: <519AC3A8.1020306@quinnharris.me> Date: Tue, 21 May 2013 18:08:04 +1000 Message-ID: From: Robert Backhaus To: Bitcoin Dev Content-Type: multipart/alternative; boundary=20cf307d04aee7d79204dd35f227 X-Gm-Message-State: ALoCoQmKwnNpNrXOgtoWXXdBq1sQVGcOsORY1y9Kl4fs4iEZlwfKQHn/mAm2eB29w0MCvkB3/sL0 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 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1Uei1V-0000wg-Pq Subject: Re: [Bitcoin-development] Double Spend Notification 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: Tue, 21 May 2013 08:34:23 -0000 --20cf307d04aee7d79204dd35f227 Content-Type: text/plain; charset=ISO-8859-1 Not at all - ACK from me, fwiw. Any attempt at a double spend should be shouted from the housetops. What Miners should do with that is still up for debate, it seems. My opinion is that they should hold on and attempt to confirm the first, letting it go only if a conflicting transaction is mined elsewhere. (Let your Yes mean Yes...) But I understand the contrary arguments. On 21 May 2013 17:04, Gregory Maxwell wrote: > On Mon, May 20, 2013 at 9:39 PM, Gavin Andresen > wrote: > > I'm very much in favor of double-spend propagation across the network. > > Absolutely. > > (to the list:) Is there anyone who is not? (assuming that it doesn't > allow arbitrary traffic multiplication, which is easily solved) > > > ------------------------------------------------------------------------------ > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > --20cf307d04aee7d79204dd35f227 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Not at all - ACK from me, fwiw. Any attempt at a double sp= end should be shouted from the housetops.=A0

What Miners= should do with that is still up for debate, it seems. My opinion is that t= hey should hold on and attempt to confirm the first, letting it go only if = a conflicting transaction is mined elsewhere. (Let your Yes mean Yes...) Bu= t I understand the contrary arguments.


On 21 M= ay 2013 17:04, Gregory Maxwell <gmaxwell@gmail.com> wrote:<= br>
On Mon, May 20, 2013 at 9:39 PM, Gavin Andresen <gavinandresen@gmail.com> wrote= :
> I'm very much in favor of double-spend propagation across the netw= ork.

Absolutely.

(to the list:) Is there anyone who is not? =A0(assuming that it doesn't=
allow arbitrary traffic multiplication, which is easily solved)

---------------------------------------------------------------------------= ---
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service=
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--20cf307d04aee7d79204dd35f227--