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 1WwYX0-0007MI-5h for bitcoin-development@lists.sourceforge.net; Mon, 16 Jun 2014 15:09:10 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of greenmangosystems.com designates 209.85.220.169 as permitted sender) client-ip=209.85.220.169; envelope-from=drice@greenmangosystems.com; helo=mail-vc0-f169.google.com; Received: from mail-vc0-f169.google.com ([209.85.220.169]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WwYWy-00006J-Co for bitcoin-development@lists.sourceforge.net; Mon, 16 Jun 2014 15:09:10 +0000 Received: by mail-vc0-f169.google.com with SMTP id la4so5183318vcb.28 for ; Mon, 16 Jun 2014 08:09:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=CP5ElzyZJdd7XBVcIVSgAu6KjEyGwU6rzpr/UMyWD8c=; b=ON7EWF/w73E9cECbcXtl23j4lqSryYlYg2mt71Fp5l/lGerwzpgA58JYI8xFIeeDH9 8YD6/LOyPz3OfPjhAa9/dNEEnHRc9U9yoUQRwo8N4qWGSFGYId+z6TIGEVdFfj5turer B3Aiw9V7vSg+FL7PaEbhmI7NIjwqW9qwjAgWIw3Ys0DOTAxGOenX2ymOCKUvAVjbXbDN n2w26O/C5PeqxMhw5dXH6f/qwherQKgTBQzlqVd0M/pCS01UZ2KhHkgTsLWhpf/6aUpf NVHnTOnNu77X9Af6a3tzIitGjbaTKePodJBxLxOkbLTXBm+54DtFpJtaDDnqNqYuQtDe DRdQ== X-Gm-Message-State: ALoCoQkbq7Ng8X+xyhnyOt5Y0tSKQdYGpsA33+9ze/hn18KjMmsgxhHUCMmyhvKt3PIjKH4qf5+e MIME-Version: 1.0 X-Received: by 10.52.252.226 with SMTP id zv2mr12610941vdc.19.1402931341824; Mon, 16 Jun 2014 08:09:01 -0700 (PDT) Received: by 10.58.123.35 with HTTP; Mon, 16 Jun 2014 08:09:01 -0700 (PDT) In-Reply-To: References: Date: Mon, 16 Jun 2014 08:09:01 -0700 Message-ID: From: Daniel Rice To: Mike Hearn Content-Type: multipart/alternative; boundary=001a1135ed2246297f04fbf5685c 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 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: 1WwYWy-00006J-Co Cc: Bitcoin Dev , Lawrence Nahum 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 15:09:10 -0000 --001a1135ed2246297f04fbf5685c Content-Type: text/plain; charset=UTF-8 If you're hoping the instant providers list won't need to scale then you're essentially saying that we need a solution to the double spend problem. That is a good point. Double spends are one of the biggest issues remaining in the protocol. I've seen so many people talk about bad experiences trying to spend Bitcoin at a restaurant and waiting an hour for confirmations. This entire BIP extension is a band aid for double spends. If double spends are not resolved, there will be a million instant providers in the long run and if double spends are resolved then this BIP extension is completely unnecessary. Is solving doublespends off the table? What if we solved doublespends like this: If a node receives 2 transactions that use the same input, they can put both of them into the new block as a proof of double spend, but the bitcoins are not sent to the outputs of either transactions. They are instead treated like a fee and given to the block solver node. This gives miners the needed incentive and tools to end doublespends instead of being forced to favor one transaction over the other. I will write up a BIP if this seems like a practical approach. On Mon, Jun 16, 2014 at 5:19 AM, Mike Hearn wrote: > Looking good! I think this is much better than the original draft. Agree > with Andreas that supports_instant is simply equal to > (supported_instant_providers.size() > 1) which makes it redundant. > > Daniel is right that putting every possible provider in the Payment > message might not scale in a world where there are huge numbers of > instant-confirmation providers, but I'm hoping that we never have to scale > to that size, because if we did that'd rather imply that Bitcoin has become > useless for in-person payments without trusted third parties and avoiding > that is rather the whole point of the project :) So I'm OK with some > theoretical lack of scalability for now. > > A more scalable approach would be for the user to send the name and > signature of their "instant provider" every time and the merchant just > chooses whether to ignore it or not, but as Lawrence points out, this is > incompatible with the provider charging extra fees for "instantness". But > should we care? I'm trying to imagine what the purchasing experience is > like with optional paid-for third party anti-double-spend protection. > Ultimately it's the merchant who cares about this, not me, so why would I > ever pay? It makes no sense for me to pay for double spend protection for > the merchant: after all, I'm honest. This is why it doesn't make sense for > me to pay miners fees either, it's the *receiver* who cares about > confirmations, not the sender. > > So I wonder if a smarter design is that the user always submits the > details of their instantness provider and we just don't allow for optional > selection of instantness. I'm not sure that works, UX wise, so is having a > less scalable design to support it worthwhile? > > > ------------------------------------------------------------------------------ > HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions > Find What Matters Most in Your Big Data with HPCC Systems > Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. > Leverages Graph Analysis for Fast Processing & Easy Data Exploration > http://p.sf.net/sfu/hpccsystems > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > --001a1135ed2246297f04fbf5685c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If you're hoping the instant providers list won&#= 39;t need to scale then you're essentially saying that we need a soluti= on to the double spend problem. That is a good point. Double spends are one= of the biggest issues remaining in the protocol. I've seen so many peo= ple talk about bad experiences trying to spend Bitcoin at a restaurant and = waiting an hour for confirmations. This entire BIP extension is a band aid = for double spends. If double spends are not resolved, there will be a milli= on instant providers in the long run and if double spends are resolved then= this BIP extension is completely unnecessary. Is solving doublespends off = the table?

What if we solved doublespends like this: If a node rec= eives 2 transactions that use the same input, they can put both of them int= o the new block as a proof of double spend, but the bitcoins are not sent t= o the outputs of either transactions. They are instead treated like a fee a= nd given to the block solver node. This gives miners the needed incentive a= nd tools to end doublespends instead of being forced to favor one transacti= on over the other.

I will write up a BIP if this seems like a practical ap= proach.


On Mon, Jun 16, 2014 at 5:19 AM, Mike Hearn <mike@plan99.net> wrote:
= Looking good! I think this is much better than the original draft. Agree wi= th Andreas that supports_instant is simply equal to (supported_instant_prov= iders.size() > 1) which makes it redundant.

Daniel is r= ight that putting every possible provider in the Payment message might not = scale in a world where there are huge numbers of instant-confirmation provi= ders, but I'm hoping that we never have to scale to that size, because = if we did that'd rather imply that Bitcoin has become useless for in-pe= rson payments without trusted third parties and avoiding that is rather the= whole point of the project :) So I'm OK with some theoretical lack of = scalability for now.

A more scal= able approach would be for the user to send the name and signature of their= "instant provider" every time and the merchant just chooses whet= her to ignore it or not, but as Lawrence points out, this is incompatible w= ith the provider charging extra fees for "instantness". But shoul= d we care? I'm trying to imagine what the purchasing experience is like= with optional paid-for third party anti-double-spend protection. Ultimatel= y it's the merchant who cares about this, not me, so why would I ever p= ay? It makes no sense for me to pay for double spend protection for the mer= chant: after all, I'm honest. This is why it doesn't make sense for= me to pay miners fees either, it's the receiver=C2=A0who cares = about confirmations, not the sender.

So I wonder= if a smarter design is that the user always submits the details of their i= nstantness provider and we just don't allow for optional selection of i= nstantness. I'm not sure that works, UX wise, so is having a less scala= ble design to support it worthwhile?

-----------------------------------------------------------------------= -------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.n= et/sfu/hpccsystems
_______________________________________________ Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--001a1135ed2246297f04fbf5685c--