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 1WwdXW-0000CK-VZ for bitcoin-development@lists.sourceforge.net; Mon, 16 Jun 2014 20:30:03 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of greenmangosystems.com designates 209.85.220.176 as permitted sender) client-ip=209.85.220.176; envelope-from=drice@greenmangosystems.com; helo=mail-vc0-f176.google.com; Received: from mail-vc0-f176.google.com ([209.85.220.176]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WwdXU-0002Vg-Ry for bitcoin-development@lists.sourceforge.net; Mon, 16 Jun 2014 20:30:02 +0000 Received: by mail-vc0-f176.google.com with SMTP id ik5so5401080vcb.7 for ; Mon, 16 Jun 2014 13:29:54 -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=Wchs0fLdy4AxEuAwdTpKp7gyeZfffMvgfoO0PrS09Sw=; b=DgUH+3K/a/Ut3iNVivgxH76D3sjJYkNUBPm8tNhnlrENzHO6OCVngDKX8aLf1Ccvim uqfgkv/dI8Om4aWmdX65EDq0W5eF0mpfOg/NoirkJor3OgjcZOihUMXHDezpyYCtB3IU Xv7b249D5Cs0VgnzGoCULbXLHkud97+aOS7/W9T5DaFS8nXSVvGfGJ77qg6BZ0Z3Y5oe CFBhiPtXBmADbR/Dfz/oqTeZLMJ7omQ/6w/5gxyYzoGXJ1B/KQA5CPj+ZF39Ot/BTqfV CZEiAfXkMqk28jBJZUxOr8D+0QYES/dfW1EpjpkPGYtnOA3tQvaj6U1EH7cgmmx0Ucrs lYJg== X-Gm-Message-State: ALoCoQm7gRDTGZ96SEXz8J+3V2nHEYqqlKyQn7YcwAaU8f5DqCRjx+Ar6X6xYF8dNRVRuP7QRzY7 MIME-Version: 1.0 X-Received: by 10.58.236.170 with SMTP id uv10mr3288356vec.31.1402950594537; Mon, 16 Jun 2014 13:29:54 -0700 (PDT) Received: by 10.58.123.35 with HTTP; Mon, 16 Jun 2014 13:29:54 -0700 (PDT) In-Reply-To: References: Date: Mon, 16 Jun 2014 13:29:54 -0700 Message-ID: From: Daniel Rice To: Mike Hearn Content-Type: multipart/alternative; boundary=047d7bdc1a9cd34a9004fbf9e33a 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: 1WwdXU-0002Vg-Ry 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 20:30:03 -0000 --047d7bdc1a9cd34a9004fbf9e33a Content-Type: text/plain; charset=UTF-8 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 > > --047d7bdc1a9cd34a9004fbf9e33a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 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 1= 6, 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-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--047d7bdc1a9cd34a9004fbf9e33a--