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-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WwZL4-0005wD-4r for bitcoin-development@lists.sourceforge.net; Mon, 16 Jun 2014 16:00:54 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of greenmangosystems.com designates 209.85.220.182 as permitted sender) client-ip=209.85.220.182; envelope-from=drice@greenmangosystems.com; helo=mail-vc0-f182.google.com; Received: from mail-vc0-f182.google.com ([209.85.220.182]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WwZL2-0002JS-97 for bitcoin-development@lists.sourceforge.net; Mon, 16 Jun 2014 16:00:54 +0000 Received: by mail-vc0-f182.google.com with SMTP id il7so5160121vcb.13 for ; Mon, 16 Jun 2014 09:00:46 -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=XCYy2bCAAuUjyURn3R93xkBiVctM9EUAH9GY0VQbZsI=; b=CPNSfGZG4aDwBRmJOWstDOj8GkwdAA4ZICDl+rOsD76zaQxhMbsKfbKi/wZO4GvLiX 4apLrgIm1WhIVyhwN8vz3tKUzhWrWAAOqy631DeHvOuafvJxNEQeLEifUV16dY373bJm Ws+Kd7GA4NlrLK2ud1g/beK/V3joXZTOrMw7YKrIbT1sZnDZSJtmDjjRW2q5k5hDPNiy ul4qLk63WynMF8jEurtxpGA2pdkqYFSuTE2KksuzCzpoKL5UQ6RwmP4uWVnAR5CqmcHw Ws2mYgGKkIBNhjxOjv8Lz2OZ5hmArcZz8E78zVvm02meJUe3q1EoH74zftM/p9h8Y/Vd 3gpA== X-Gm-Message-State: ALoCoQkX8ni4QvNOOhxVW0HxjAo3PVDccX9SkmvkJltJR1Nbct3Dm3eZrsbtVj76pSgyS8T0HwGy MIME-Version: 1.0 X-Received: by 10.52.184.164 with SMTP id ev4mr14083092vdc.15.1402934445861; Mon, 16 Jun 2014 09:00:45 -0700 (PDT) Received: by 10.58.123.35 with HTTP; Mon, 16 Jun 2014 09:00:45 -0700 (PDT) In-Reply-To: References: Date: Mon, 16 Jun 2014 09:00:45 -0700 Message-ID: From: Daniel Rice To: Lawrence Nahum Content-Type: multipart/alternative; boundary=bcaec54865d84a05ed04fbf621eb 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: 1WwZL2-0002JS-97 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:00:54 -0000 --bcaec54865d84a05ed04fbf621eb Content-Type: text/plain; charset=UTF-8 > Any reason you think people will spread trust instead of consolidating of a bunch of instant transaction providers when time is critical? Maybe you're right, but if you are, that's a huge reason not to implement this. We should encourage proliferation of instant providers otherwise we start becoming VISA all over again. That's a future for Bitcoin I'm not excited about: "Use one of these 4 companies, or you need to wait an impractical amount of time before your transaction will go through." Come to think of it, is the payment protocol really the place to put this instant provider signature or should it be in the actual Bitcoin transaction? If we don't believe there is a valid practical solution to doublespends (some people have already emailed me critical feedback on my proposal) then we absolutely need a trust network, but we would also want it to be part of the public ledger for everyone to see. On Mon, Jun 16, 2014 at 8:26 AM, Lawrence Nahum wrote: > Daniel Rice greenmangosystems.com> writes: > > > 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. > > I am not sure if double spends can be resolved, at the moment they are not > and I highly doubt you will see millions instant providers just like I > don't > see millions Certificate Authorities and I don't see Million Credit Card > networks. > > Any reason you think people will spread trust instead of consolidating of a > bunch of instant transaction providers when time is critical? > > > > > ------------------------------------------------------------------------------ > 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 > --bcaec54865d84a05ed04fbf621eb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>=C2=A0Any reason you think people will spread trust instead of consol= idating of a
bunch of inst= ant transaction providers when time is critical?

Maybe yo= u're right, but if you are, that's a huge reason not to implement t= his. We should encourage proliferation of instant providers otherwise we st= art becoming VISA all over again. That's a future for Bitcoin I'm n= ot excited about: "Use one of these 4 companies, or you need to wait a= n impractical amount of time before your transaction will go through."=

=
Come to think of it, is the payment protocol really the place to put thi= s instant provider signature or should it be in the actual Bitcoin transact= ion? If we don't believe there is a valid practical solution to doubles= pends (some people have already emailed me critical feedback on my proposal= ) then we absolutely need a trust network, but we would also want it to be = part of the public ledger for everyone to see.


On Mon,= Jun 16, 2014 at 8:26 AM, Lawrence Nahum <lawrence@greenaddress.it<= /a>> wrote:
Daniel Rice <drice <at= > greenmangos= ystems.com> writes:

> =C2=A0If double spends are not resolved, there will be a million insta= nt
providers in the long run and if double spends are resolved then this BIP extension is completely unnecessary.

I am not sure if double spends can be resolved, at the moment they ar= e not
and I highly doubt you will see millions instant providers just like I don&= #39;t
see millions Certificate Authorities and I don't see Million Credit Car= d
networks.

Any reason you think people will spread trust instead of consolidating of a=
bunch of instant transaction providers when time is critical?



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

--bcaec54865d84a05ed04fbf621eb--