From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Wwe3J-0006Gb-Sf for bitcoin-development@lists.sourceforge.net; Mon, 16 Jun 2014 21:02:53 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of greenmangosystems.com designates 209.85.220.174 as permitted sender) client-ip=209.85.220.174; envelope-from=drice@greenmangosystems.com; helo=mail-vc0-f174.google.com; Received: from mail-vc0-f174.google.com ([209.85.220.174]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Wwe3I-00086x-3q for bitcoin-development@lists.sourceforge.net; Mon, 16 Jun 2014 21:02:53 +0000 Received: by mail-vc0-f174.google.com with SMTP id hy4so5573188vcb.33 for ; Mon, 16 Jun 2014 14:02:45 -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=1VCyTBcvbMsnfe0NdIr2GiCTgPnoYmB0/s8RyfJrKTs=; b=h68SS5kJgbL8wn7saOURkaV1URWv+0EJ+nx4WH3jA9VvHII3AMzvTUL8cbMVaYZZIW fw4Voh+JqegiZIuC0joZr1iaIZTreq5OzdVQVfsdt7+ry1PBTaKPeUPaWcmepFcAuybt fJKWzRlJSchjSsBFOH2CHX1evSxYxIFUAdBkBF4AzV+UklFBzw+NedfYLtO8GU/L97N/ SvqJn6bYTLVaWygQVmvdPgjHfAxz3cagpbrbd4bQIJ/mMaQ+tNyYcEJoiRRvXHThgz64 CdlEUb4AnCAEXTRdjqfbZC3wRSo63aoNEUHENOqQ7ZNt6izsGScLS/nJoqaEOED75Y22 stZg== X-Gm-Message-State: ALoCoQlUdxaNE9VwhqP4kbFqu8ltwwXqOX4T4u0Q53xVfNXZLrW2b2fY0KpiayW8NCRdnakxTWg1 MIME-Version: 1.0 X-Received: by 10.52.232.133 with SMTP id to5mr15131098vdc.16.1402952565713; Mon, 16 Jun 2014 14:02:45 -0700 (PDT) Received: by 10.58.123.35 with HTTP; Mon, 16 Jun 2014 14:02:45 -0700 (PDT) In-Reply-To: References: Date: Mon, 16 Jun 2014 14:02:45 -0700 Message-ID: From: Daniel Rice To: Mike Hearn Content-Type: multipart/alternative; boundary=089e011764d15100e204fbfa597c 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: 1Wwe3I-00086x-3q 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 21:02:54 -0000 --089e011764d15100e204fbfa597c Content-Type: text/plain; charset=UTF-8 Mike Hearn wrote: >> 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? Lawrence Nahum wrote: > I think you are wrong here. > Just because up to date credit cards charged the merchant which in turn > charged you and the ordinary cash payer doesn't mean a newer and better > system can't be transparent from day one. I don't think a whitelist of trust is a practical approach because you are going to want to have varying levels of trust in different instant providers. This would be based on how large their past transaction volume has been. For that reason maybe another approach is an additional negotiation message between the merchant and wallet. Merchant sends payment details -> wallet responds with their instant information requesting if an instant transaction will be accepted for this transaction. Merchant weighs the risk based on historical data about this particular instant provider and the amount of the requested transaction -> Merchant responds yes or no. That approach avoids the scaling issue, but also allows for Lawrence's use case of charging the user a fee only in the case where the instant transaction is supported. On Mon, Jun 16, 2014 at 1:29 PM, Daniel Rice wrote: > I'm trying to think through how to encourage the maximum number of instant > signature providers and avoid the VISA monopoly. Ideal case would be that > people can even be their own instant provider. > > What if the protocol allowed multiple instant signatures on a transaction? > Would it encourage more instant providers? For example, a new instant > provider could bootstrap their own trust by paying an already trusted > instant provider to co-sign the same transaction. This would be useful in > the case that a new company tries to release a new wallet once the trust > ring is already established. Nobody will use that wallet because it does > not have the trusted history to do instant transactions, but if they can > pay a small amount per transaction to a third party to cosign, they can > build trust in their own signature till they can eventually have enough > trust on their own. This could be how an individual user could grow trust > in their own instant signature as well. > > > On Mon, Jun 16, 2014 at 11:09 AM, Mike Hearn wrote: > >> I think many of us feel it'd be better if this kind of thing were not >> needed at all, however, the best way to ensure it doesn't end up being used >> is to write code, not to try and block alternative approaches. If Bitcoin >> is robust the market should sort it out. If it's robust for some >> transactions and not others, that makes for a fun project for a future >> generation of hackers to sort out. >> >> OK, enough philosophy - let's try and keep this thread just for >> discussion of the BIP itself from now on. If you'd like to continue >> debating the Future of Bitcoin please change the subject line and break it >> out into a new thread. >> >> >> ------------------------------------------------------------------------------ >> 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 >> >> > --089e011764d15100e204fbfa597c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mike Hearn <mike@plan99.net> wr= ote:
>> A= more scalable approach would be for the user to send the name and
>&= gt; signature of their "instant provider" every time and the merc= hant just
>> chooses whether to ignore it or not, but as Lawrence points out, t= his is
>> incompatible with the provider charging extra fees for &= quot;instantness". But
>> should we care? I'm trying to i= magine what the purchasing experience is like
>> with optional paid-for third party anti-double-spend protection. U= ltimately
>> it's the merchant who cares about this, not me, s= o why would I ever pay?

<= /div>
Lawrence Nahum <lawrence@greenaddress.it&g= t; wrote:
> I think you are wrong here.> Jus= t because up to date credit cards charged the merchant which in turn=
> charged you and the ordinary cash = payer doesn't mean a newer and better
> system can't be transpa= rent from day one.

=
I don't think a whit= elist of trust is a practical approach because you are going to want to hav= e varying levels of trust in different instant providers. This would be bas= ed on how large their past transaction volume has been. For that reason may= be another approach is an additional negotiation message between the mercha= nt and wallet. Merchant sends payment details -> wallet responds with th= eir instant information requesting if an instant transaction will be accept= ed for this transaction. Merchant weighs the risk based on historical data = about this particular instant provider and the amount of the requested tran= saction -> Merchant responds yes or no.

That approach avoids the scaling issue, but also allows f= or Lawrence's use case of charging the user a fee only in the case wher= e the instant transaction is supported.


On Mon,= Jun 16, 2014 at 1:29 PM, Daniel Rice <drice@greenmangosystems.c= om> wrote:
I'm trying to thin= k through how to encourage the maximum number of instant signature provider= s and avoid the VISA monopoly. Ideal case would be that people can even be = their own instant provider.

What if the protocol allowed multiple instant signatures on = a transaction? Would it encourage more instant providers? For example, a ne= w instant provider could bootstrap their own trust by paying an already tru= sted instant provider to co-sign the same transaction. This would be useful= in the case that a new company tries to release a new wallet once the trus= t ring is already established. Nobody will use that wallet because it does = not have the trusted history to do instant transactions, but if they can pa= y a small amount per transaction to a third party to cosign, they can build= trust in their own signature till they can eventually have enough trust on= their own. This could be how an individual user could grow trust in their = own instant signature as well.


On Mon, Jun 16, 2014 at 11:09 AM, Mike Hearn <mike@plan99.net> wrote:
I think many of us feel it'd be better if this ki= nd of thing were not needed at all, however, the best way to ensure it does= n't end up being used is to write code, not to try and block alternativ= e approaches. If Bitcoin is robust the market should sort it out. If it'= ;s robust for some transactions and not others, that makes for a fun projec= t for a future generation of hackers to sort out.

OK, enough philosophy - let's try and ke= ep this thread just for discussion of the BIP itself from now on. If you= 9;d like to continue debating the Future of Bitcoin please change the subje= ct line and break it out into a new thread.

-------------------------------------------------= -----------------------------
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-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment



--089e011764d15100e204fbfa597c--