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-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Wwa2o-0004a4-C8 for bitcoin-development@lists.sourceforge.net; Mon, 16 Jun 2014 16:46:06 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.219.53 as permitted sender) client-ip=209.85.219.53; envelope-from=mh.in.england@gmail.com; helo=mail-oa0-f53.google.com; Received: from mail-oa0-f53.google.com ([209.85.219.53]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Wwa2m-0003Xl-JO for bitcoin-development@lists.sourceforge.net; Mon, 16 Jun 2014 16:46:06 +0000 Received: by mail-oa0-f53.google.com with SMTP id l6so5951330oag.26 for ; Mon, 16 Jun 2014 09:45:59 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.47.77 with SMTP id b13mr21051639oen.40.1402937158956; Mon, 16 Jun 2014 09:45:58 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.71.162 with HTTP; Mon, 16 Jun 2014 09:45:58 -0700 (PDT) In-Reply-To: References: Date: Mon, 16 Jun 2014 18:45:58 +0200 X-Google-Sender-Auth: l7Fy0NlP_GIVlxPaCAXO6dwfJFs Message-ID: From: Mike Hearn To: Lawrence Nahum Content-Type: multipart/alternative; boundary=001a11c21116007d2704fbf6c333 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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 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: 1Wwa2m-0003Xl-JO Cc: Bitcoin Dev 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: Mon, 16 Jun 2014 16:46:06 -0000 --001a11c21116007d2704fbf6c333 Content-Type: text/plain; charset=UTF-8 > > I read the comments on the PR. I mean no disrespect but this patch can't > prevent double spends minutes apart and a solution is as good as it's > weakest link. > Actually Tom is running a page where he shows double spends detected by his node or relayed by mine (there are only two nodes in this little detection network currently), and it does show double spends that occur seconds, minutes or even days apart. Regardless, whether that approach helps or not is off topic for this thread. Let's all hope it does and discuss the details in some other thread, or on the pull request. > instant confirmation between exchanges can create huge arbitrage > opportunities and as such > liquidity. > Yes indeed, if you want to do high frequency trading then every millisecond counts and you probably don't want to rely on watching transactions propagate across the block chain. For inter-exchange traffic this BIP would probably be useful. I've been talking about the consumer case. > What do you expect for e-commerce and escrow to happen? Don't you think the > market will naturally converge to a handful of hubs that will helps with > refunds and things like that? No, I expect there to be many kinds of trades where dispute mediation is unnecessary, e.g. when I buy a drink at Starbucks or a burger at McDonalds the chances of me wanting to charge it back is basically zero. Same for sending between people who know each other, large corporate transactions where the threat of a lawsuit is more useful than mediation, etc. But for transactions where third parties are needed for dispute mediation, yes, I'd expect there to be a handful of well known trusted names for the majority of such transactions, and then a long tail of specialists who only mediate e.g. purchases of rare Aztec artifacts or other things where a generic company might be easily fooled. --001a11c21116007d2704fbf6c333 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I read the comments on the PR. I= mean no disrespect but this patch can't
prevent double spends minutes apart and a solution is as good as it's weakest link.

Actually Tom is running a= page where he shows double spends detected by his node or relayed by mine = (there are only two nodes in this little detection network currently), and = it does show double spends that occur seconds, minutes or even days apart.<= /div>

Regardless, whether that approach helps or not is off t= opic for this thread. Let's all hope it does and discuss the details in= some other thread, or on the pull request.
=C2=A0
instant confirmation between exchanges can create huge arbi= trage opportunities and as such
liquidity.

Yes indeed, if you want to d= o high frequency trading then every millisecond counts and you probably don= 't want to rely on watching transactions propagate across the block cha= in. For inter-exchange traffic this BIP would probably be useful. I've = been talking about the consumer case.
=C2=A0
What do you= expect for e-commerce and escrow to happen? Don't you think the
market will naturally converge to a handful of hubs that will helps with refunds and things like that?

No, I expect = there to be many kinds of trades where dispute mediation is unnecessary, e.= g. when I buy a drink at Starbucks or a burger at McDonalds the chances of = me wanting to charge it back is basically zero. Same for sending between pe= ople who know each other, large corporate transactions where the threat of = a lawsuit is more useful than mediation, etc.

But for transactions where third parties are needed for= dispute mediation, yes, I'd expect there to be a handful of well known= trusted names for the majority of such transactions, and then a long tail = of specialists who only mediate e.g. purchases of rare Aztec artifacts or o= ther things where a generic company might be easily fooled.
--001a11c21116007d2704fbf6c333--