Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UFTUC-00034x-W7 for bitcoin-development@lists.sourceforge.net; Tue, 12 Mar 2013 17:59:41 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of coinlab.com designates 209.85.216.54 as permitted sender) client-ip=209.85.216.54; envelope-from=peter@coinlab.com; helo=mail-qa0-f54.google.com; Received: from mail-qa0-f54.google.com ([209.85.216.54]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UFTU7-0005zf-Vf for bitcoin-development@lists.sourceforge.net; Tue, 12 Mar 2013 17:59:40 +0000 Received: by mail-qa0-f54.google.com with SMTP id hg5so158529qab.20 for ; Tue, 12 Mar 2013 10:59:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=nqJ6md9TfwI32JfAvPHoo9rsWDMYnM+ioYeFZTLSvWU=; b=PDcP3BwNlk4sFUq6u8ktlNNLzKj7eWdsGCefXkdlV7iMzsQqkGoUFkwUP/t7D5o86D 93PPhlJPO78Yhz8DGQzqJxuW+WTtind3fkndgX1X0LZiH/wLoqEgZjSwiq3fT9ep8L3n +5Ug97C3TEIP2/lNWCTr3GJego9pMHUHQuDBQSLjDSYm58MYZCgOPH4D5qSEdRWlEPEE ZlyramiEuseWMZ1BbvIQWJtO2JP0li0QdA+QlTVff9r2xYNLp1R5cx8MhujL/wapixsC HR5C8J4W4op8LnsRE9NRVx+RoR09LStRveELC35UJRtT90SVgA0lSi+SlIgajVRMKNaa H7cw== X-Received: by 10.224.189.10 with SMTP id dc10mr23566187qab.55.1363109741389; Tue, 12 Mar 2013 10:35:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.104.138 with HTTP; Tue, 12 Mar 2013 10:35:21 -0700 (PDT) In-Reply-To: References: <513ED35A.8080203@gmail.com> <201303121210.34515.luke@dashjr.org> From: Peter Vessenes Date: Tue, 12 Mar 2013 10:35:21 -0700 Message-ID: To: Alan Reiner Content-Type: multipart/alternative; boundary=20cf30334667ed1ac404d7bdb735 X-Gm-Message-State: ALoCoQmMNr8d8ILFfCW/COGag0yQ/nslDE7JXMRUZLh2wD978CYhPRIiK8qv5ZxM5XfCTB8FqHct 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: 1UFTU7-0005zf-Vf Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Some PR preparation 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, 12 Mar 2013 17:59:41 -0000 --20cf30334667ed1ac404d7bdb735 Content-Type: text/plain; charset=ISO-8859-1 Can some enterprising soul determine if there were any double-spend attempts? I'm assuming no, and if that's the case, we should talk about that publicly. Either way, I think it's generally another test well done by everyone; people pitched in on PR, tech, communication, yay Bitcoin! On Tue, Mar 12, 2013 at 9:55 AM, Alan Reiner wrote: > On Tue, Mar 12, 2013 at 8:10 AM, Luke-Jr wrote: > >> >> >> I think we should be careful not to downplay the reality either. >> For a number of hours, transactions could have received up to N >> confirmations >> and then still been reversed. While we could contact the bigger payment >> processors, I saw people still trying to buy/sell on OTC, whom could have >> been >> scammed even by taking standard precautions. >> >> > I don't want to misrepresent what happened, but how much of that was > really a risk? The block was rejected, but the transactions were not. Any > valid transactions to hit the network would get added to everyone's memory > pool and mined in both chains. Thus all nodes would still reject > double-spend attempts. As far as I understood it, you would've had to have > majority mining power on one of the chains (and both had non-negligible > computing power on them), so double-spending still required an exceptional > amount of resources -- just not the normal 50% that is normally needed. > Perhaps... 10%? But how many people can even have 10%? In addition to > that, a victim needs to be found that hasn't seen the alert, is willing to > execute a large transaction, and is on the wrong side of the chain. > > Is this incorrect? Yes, there was less resources needed to execute an > attack -- but it still required a very powerful attacker, way outside the > scope of "regular users." > > > > ------------------------------------------------------------------------------ > Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester > Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the > endpoint security space. For insight on selecting the right partner to > tackle endpoint security challenges, access the full report. > http://p.sf.net/sfu/symantec-dev2dev > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > -- ------------------------------ [image: CoinLab Logo]PETER VESSENES CEO *peter@coinlab.com * / 206.486.6856 / SKYPE: vessenes 811 FIRST AVENUE / SUITE 480 / SEATTLE, WA 98104 --20cf30334667ed1ac404d7bdb735 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Can some enterprising soul determine if there were any dou= ble-spend attempts?

I'm assuming no, and if that'= ;s the case, we should talk about that publicly.

Either way, I think it's generally another test well done by everyone; = people pitched in on PR, tech, communication, yay Bitcoin!=A0



On Tue, Mar 12, 2013 at 9:55 AM, Alan Reiner <etotheipi@gmail.com&g= t; wrote:
On Tue, Mar 12, 2013 at 8:10 AM, Luke-Jr &l= t;luke@dashjr.org&= gt; wrote:


I think we should be careful not to downplay the reality either.
For a number of hours, transactions could have received up to N confirmatio= ns
and then still been reversed. While we could contact the bigger payment
processors, I saw people still trying to buy/sell on OTC, whom could have b= een
scammed even by taking standard precautions.


<= /div>
I don't want to misrepresent what happened, but how much of = that was really a risk? =A0The block was rejected, but the transactions wer= e not. =A0Any valid transactions to hit the network would get added to ever= yone's memory pool and mined in both chains. =A0Thus all nodes would st= ill reject double-spend attempts. =A0As far as I understood it, you would&#= 39;ve had to have majority mining power on one of the chains (and both had = non-negligible computing power on them), so double-spending still required = an exceptional amount of resources -- just not the normal 50% that is norma= lly needed. =A0Perhaps... 10%? =A0 But how many people can even have 10%? = =A0In addition to that, a victim needs to be found that hasn't seen the= alert, is willing to execute a large transaction, and is on the wrong side= of the chain.

Is this inc= orrect? =A0Yes, there was less resources needed to execute an attack -- but= it still required a very powerful attacker, way outside the scope of "= ;regular users."
=A0

-----------------------------------------------------------------------= -------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" = in the
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p= .sf.net/sfu/symantec-dev2dev
_______________________________________= ________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment




--

3D=PETER=A0VESSE= NES=A0
CEO

peter@coinlab.com=A0=A0/=A0=A0206.486.6856 = =A0/=A0SKYPE:=A0vessenes=A0
811 FIRST AVENUE =A0/=A0 SUITE 480 =A0/=A0 SEATTLE, WA 98104

--20cf30334667ed1ac404d7bdb735--