From mboxrd@z Thu Jan 1 00:00:00 1970 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 1WxMlV-0007bS-B6 for bitcoin-development@lists.sourceforge.net; Wed, 18 Jun 2014 20:47:29 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.212.169 as permitted sender) client-ip=209.85.212.169; envelope-from=natanael.l@gmail.com; helo=mail-wi0-f169.google.com; Received: from mail-wi0-f169.google.com ([209.85.212.169]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WxMlT-0000cQ-7B for bitcoin-development@lists.sourceforge.net; Wed, 18 Jun 2014 20:47:29 +0000 Received: by mail-wi0-f169.google.com with SMTP id hi2so9148684wib.0 for ; Wed, 18 Jun 2014 13:47:20 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.184.198 with SMTP id ew6mr560098wic.13.1403124440877; Wed, 18 Jun 2014 13:47:20 -0700 (PDT) Received: by 10.194.243.104 with HTTP; Wed, 18 Jun 2014 13:47:20 -0700 (PDT) Received: by 10.194.243.104 with HTTP; Wed, 18 Jun 2014 13:47:20 -0700 (PDT) In-Reply-To: <20140617155845.8177ADFC55C@quidecco.de> References: <20140617155845.8177ADFC55C@quidecco.de> Date: Wed, 18 Jun 2014 22:47:20 +0200 Message-ID: From: Natanael To: Isidor Zeuner Content-Type: multipart/alternative; boundary=001a11c3348cdfd5d304fc225d38 X-Spam-Score: -0.6 (/) 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 (natanael.l[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -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: 1WxMlT-0000cQ-7B Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension 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: Wed, 18 Jun 2014 20:47:29 -0000 --001a11c3348cdfd5d304fc225d38 Content-Type: text/plain; charset=UTF-8 Den 17 jun 2014 17:59 skrev "Isidor Zeuner" : > > quote: > > Mike Hearn, why don't we just have all nodes report attempted double spends > > through the node network. No need to involve the miners at all really, or > > do your suggestion but also report the double spend attempt. By waiting > > maybe 10-60 seconds (instead of 10 minutes for first conf), merchants can > > be more sure that a double spend attack was not tried. Attacker would have > > to hold back second tx by 10-60 seconds and hope that that second tx (with > > higher fee) get's into a solved block before the first one. This forced > > delay time ought to make the attack less successful (but not impossible). > > > > What prevents the following steps from happening: > > 1. attacker sends first transaction, paying to the merchant > > 2. merchant waits 10-60 seconds > > 3. merchant confirms the payment as received > > 4. attacker sees merchant's confirmation > > 5. attacker sends double spend > > The security improvement seems to be pretty much exactly the chance > that during the 10-60 seconds, a block is solved. Am I missing > something? > > Regarding "reporting double spends", this would only help if it comes > with some kind of penalty for the double spend. Now what if the double > spend was not done on malicious motives? Maybe someone posted a > transaction which does not confirm for some reason, and wants to > recover his funds? Should we regard transactions which do not confirm > as forever lost, in order to get to an "every double spend is a > misbehaviour" policy? > > Best regards, > > Isidor With 2-of-2 multisignature notaries, the doublespend (the set of conflicting transactions) would be published and propagated together as evidence of the notary being malicious. This is trivial and self-evident self-contained proof. But there should be no direct penalty IMHO in the Bitcoin protocol itself. If a transaction would have to be replaced honestly because of being wrong or simply not confirming, then I think there should be some means of showing the second transaction is "legitimate". Don't ask me how exactly it would work in practice, but one method could be through showing the original recipients have signed off on it (showing they agree it should be reversed). If you can't get the original recipient to sign, then you're stuck with either not replacing it or the notary trying to prove the replacing transaction was legitimate. --001a11c3348cdfd5d304fc225d38 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Den 17 jun 2014 17:59 skrev "Isidor Zeuner" <cryptocurrencies@quidecco.de<= /a>>:
>
> quote:
> > Mike Hearn, why don't we just have all nodes report attempted= double spends
> > through the node network. No need to involve the miners at all re= ally, or
> > do your suggestion but also report the double spend attempt. By w= aiting
> > maybe 10-60 seconds (instead of 10 minutes for first conf), merch= ants can
> > be more sure that a double spend attack was not tried. Attacker w= ould have
> > to hold back second tx by 10-60 seconds and hope that that second= tx (with
> > higher fee) get's into a solved block before the first one. T= his forced
> > delay time ought to make the attack less successful (but not impo= ssible).
> >
>
> What prevents the following steps from happening:
>
> 1. attacker sends first transaction, paying to the merchant
>
> 2. merchant waits 10-60 seconds
>
> 3. merchant confirms the payment as received
>
> 4. attacker sees merchant's confirmation
>
> 5. attacker sends double spend
>
> The security improvement seems to be pretty much exactly the chance > that during the 10-60 seconds, a block is solved. Am I missing
> something?
>
> Regarding "reporting double spends", this would only help if= it comes
> with some kind of penalty for the double spend. Now what if the double=
> spend was not done on malicious motives? Maybe someone posted a
> transaction which does not confirm for some reason, and wants to
> recover his funds? Should we regard transactions which do not confirm<= br> > as forever lost, in order to get to an "every double spend is a > misbehaviour" policy?
>
> Best regards,
>
> Isidor

With 2-of-2 multisignature notaries, the doublespend (the se= t of conflicting transactions) would be published and propagated together a= s evidence of the notary being malicious. This is trivial and self-evident = self-contained proof.

But there should be no direct penalty IMHO in the Bitcoin pr= otocol itself.

If a transaction would have to be replaced honestly because = of being wrong or simply not confirming, then I think there should be some = means of showing the second transaction is "legitimate". Don'= t ask me how exactly it would work in practice, but one method could be thr= ough showing the original recipients have signed off on it (showing they ag= ree it should be reversed).

If you can't get the original recipient to sign, then yo= u're stuck with either not replacing it or the notary trying to prove t= he replacing transaction was legitimate.

--001a11c3348cdfd5d304fc225d38--