Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WwaLt-0003U0-Jl for bitcoin-development@lists.sourceforge.net; Mon, 16 Jun 2014 17:05:49 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of m.gmane.org designates 80.91.229.3 as permitted sender) client-ip=80.91.229.3; envelope-from=gcbd-bitcoin-development@m.gmane.org; helo=plane.gmane.org; Received: from plane.gmane.org ([80.91.229.3]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1WwaLr-0004DZ-S9 for bitcoin-development@lists.sourceforge.net; Mon, 16 Jun 2014 17:05:49 +0000 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WwaLl-0001eJ-6A for bitcoin-development@lists.sourceforge.net; Mon, 16 Jun 2014 19:05:41 +0200 Received: from 93-35-10-132.ip52.fastwebnet.it ([93.35.10.132]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 16 Jun 2014 19:05:41 +0200 Received: from lawrence by 93-35-10-132.ip52.fastwebnet.it with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 16 Jun 2014 19:05:41 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: bitcoin-development@lists.sourceforge.net From: Lawrence Nahum Date: Mon, 16 Jun 2014 17:05:27 +0000 (UTC) Message-ID: References:

Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 93.35.10.132 (Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36) X-Spam-Score: -2.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 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.91.229.3 listed in list.dnswl.org] -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 SPF_PASS SPF: sender matches SPF record -1.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1WwaLr-0004DZ-S9 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 17:05:49 -0000 Mike Hearn plan99.net> writes: > Sure. I buy this. Although the credit card market is a great example of what we don't want: a stagnant duopoly of trusted third parties who rampantly abuse their position. So I'd hope we see either (a) nobody really caring about this BIP because Bitcoin gives good enough double spend protection or (b) lots of anti-double-spend providers (hundreds seems fine). Maybe hundreds, maybe less. I can imagine there would/could be local ones. It's not the same as credit cards though: it's an open protocol with explicit intent from all parties and no forced fees for normal transactions - just for instant ones. > No, I will never wait. Neither me nor the merchant wants to me to be pointlessly hanging around for an hour. The alternative is to pay by credit card or cash. Outside of experiments there is no such thing as a shop that only accepts only Bitcoin and will require me to wait for a block because I didn't use a TTP to guarantee anti-double spends. I tend to agree but _today_ people are trying to use bitcoin and are waiting and waiting .. > So this seems like a fundamental problem to me: having the ability to say, "here is a proof I won't double spend" is fine, but it doesn't achieve anything if the merchant would have sold me the goods in return for a normal Bitcoin tx anyway, which in practice they always will because this system starts out from zero users and would have to work upwards. I especially will never use this system if I have to pay for it - I'd much rather just put my money into a wallet that can't generate these proofs and pay the sticker price. This is a cultural thing. In some places if you pay by cards you pay extra. I think it may be good to support both models but I like better the transparent one even if I'm going to admit that the least transparent one may be more attractive as it fools consumers. > Maybe what this BIP needs is an extra field that lets the merchant say, I will give you a discount of X satoshis if you give me a no-double-spends proof. In other words invert it: the sticker price is what normal Bitcoin transactions cost, and then your wallet shows you the regular BIP70 price minus the discount plus the third parties fee as what you finally pay. I compare it to the sticker price the merchant is asking and if it's lower I'm happy, and if it's higher my wallet would automatically avoid using the TTP because I don't want to ever pay more, only less. > The market would then figure out if the fees the TTP charges are worth the lower losses due to double spending fraud. I think this is worth discussing further. Would love also more input from other people on this.