From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WxIHA-0003nd-DU for bitcoin-development@lists.sourceforge.net; Wed, 18 Jun 2014 15:59:52 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of greenmangosystems.com designates 209.85.220.173 as permitted sender) client-ip=209.85.220.173; envelope-from=drice@greenmangosystems.com; helo=mail-vc0-f173.google.com; Received: from mail-vc0-f173.google.com ([209.85.220.173]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WxIH8-000437-Kj for bitcoin-development@lists.sourceforge.net; Wed, 18 Jun 2014 15:59:52 +0000 Received: by mail-vc0-f173.google.com with SMTP id lf12so1005810vcb.32 for ; Wed, 18 Jun 2014 08:59:44 -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=hzYnIv2b4WRni6+zmXZwjeFF+h9IjR842s5KcO/R3r8=; b=iBN4EjBq4tejB02NQwkDhtbjDESx0e/ymRXaJTNjnvZE+RLgsgurXi2DFpvJ2K20ep aT7gERwPm8dCeleocS8vnK3Xt5jQVW5CE0SniknlKU90WhT0qtRB4qQWl0/NJLeOuU78 QyPDI9TIPszj+e2fBCga8kqiwg1kmk0ALkSTsOL0zYNsryo0+2/oKD9trvwoch8dJfea NSP4gk8zfZS5QEUFDUbDNGww3udsPEg3USt+uHh3NvTC2OaY4ouHZ1lsGm3BuwopPG+3 d4p7Zd7mmboLe4FHmudfv+vnnJ5peka4WwzjsuFn+AOL/sRbQJHlwJqz+IiBh99moihm 4QFg== X-Gm-Message-State: ALoCoQkckWvOzOF+hzyqbDTCt7yDh5XXCvLqF/K8WgPPeYJntHQmvmqjN8W/1uqoZrx7caqs/tnt MIME-Version: 1.0 X-Received: by 10.58.115.229 with SMTP id jr5mr598161veb.74.1403107184282; Wed, 18 Jun 2014 08:59:44 -0700 (PDT) Received: by 10.58.123.35 with HTTP; Wed, 18 Jun 2014 08:59:44 -0700 (PDT) In-Reply-To: References: Date: Wed, 18 Jun 2014 08:59:44 -0700 Message-ID: From: Daniel Rice To: Mike Hearn Content-Type: multipart/alternative; boundary=047d7b672d324d251e04fc1e59fe 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: 1WxIH8-000437-Kj 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: Wed, 18 Jun 2014 15:59:52 -0000 --047d7b672d324d251e04fc1e59fe Content-Type: text/plain; charset=UTF-8 > I'm not sure this is actually important or useful; trusting someone not to double spend is a pretty binary thing I think that's true if you assume that the instant provider list is based on a by hand created list of accepted instant providers. That's how VISA works now and that's why I was asking for an approach where the trusted_instant_providers list is scalable because that seems very dangerous. Since you can detect when a double spend happens, the entire instant provider list could be automatically generated based on a 3rd party network that shares information between vendors and also monitors double spends. In that scenario, there is no hand written exclusive list of accepted instant providers. There is just a database of past history on all instant providers. That database can be used to give a confidence score for a specific instant provider for a given transaction amount. In this scenario, a new wallet company would be able to earn trust over time. If the list is made by hand, "Bitpay accepts Circle, Coinbase, and GreenAddress for instant transactions", then new wallet providers have to go around bribing Bitpay and the other large merchant transaction providers to get on their instant provider list. Allowing more than one instant signature on a transaction is supposed to help avoid that scenario. For example, lets say I want to establish my own instant signature. I use a wallet that already has an accepted instant signature, but it also allows me to add my own instant signature. I do this so that I can start establishing trust in my own instant signature while relying on their instant signature. On Wed, Jun 18, 2014 at 6:25 AM, Mike Hearn wrote: > - allowing multiple signatures ? > > > I'm not sure this is actually important or useful; trusting someone not to > double spend is a pretty binary thing. I'm not sure saying "you need to get > three independent parties to sign off on this" is worth the hassle, > especially because the first signature is obvious (your risk analysis > provider or hardware) but the second and third are ..... who? Special > purpose services you have to sign up for? Seems like a hassle. > > But it's up to you. > > > ------------------------------------------------------------------------------ > 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 > > --047d7b672d324d251e04fc1e59fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>=C2=A0I'm not sure this is actually important or useful; trusting= someone not to double spend is a pretty binary thing

I think that's true = if you assume that the instant provider list is based on a by hand created = list of accepted instant providers. That's how VISA works now and that&= #39;s why I was asking for an approach where the trusted_instant_providers = list is scalable because that seems very dangerous.

Since you can detect when a double spend happens, the ent= ire instant provider list could be automatically generated based on a 3rd p= arty network that shares information between vendors and also monitors doub= le spends. In that scenario, there is no hand written exclusive list of acc= epted instant providers. There is just a database of past history on all in= stant providers. That database can be used to give a confidence score for a= specific instant provider for a given transaction amount. In this scenario= , a new wallet company would be able to earn trust over time. If the list i= s made by hand, "Bitpay accepts Circle, Coinbase, and GreenAddress for= instant transactions", then new wallet providers have to go around br= ibing Bitpay and the other large merchant transaction providers to get on t= heir instant provider list.

Allowing more than one instant signature on a transaction= is supposed to help avoid that scenario. For example, lets say I want to e= stablish my own instant signature. I use a wallet that already has an accep= ted instant signature, but it also allows me to add my own instant signatur= e. I do this so that I can start establishing trust in my own instant signa= ture while relying on their instant signature.


On Wed, Jun 1= 8, 2014 at 6:25 AM, Mike Hearn <mike@plan99.net> wrote:
- allowing multiple signatures ?
I'm not sure this is actually important or useful; trusting someon= e not to double spend is a pretty binary thing. I'm not sure saying &qu= ot;you need to get three independent parties to sign off on this" is w= orth the hassle, especially because the first signature is obvious (your ri= sk analysis provider or hardware) but the second and third are ..... who? S= pecial purpose services you have to sign up for? Seems like a hassle.

But it's up to you.

-----------------------------------------------------------------------= -------
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


--047d7b672d324d251e04fc1e59fe--