diff options
| author | Daniel Rice <drice@greenmangosystems.com> | 2014-06-16 13:29:54 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2014-06-16 20:30:03 +0000 |
| commit | 955b6eba82c1740eb8cd8995b357e846d837ee4c (patch) | |
| tree | 234d6392146d48f247557a66c291b8acd6013f89 | |
| parent | cdecd2202dcbc9d0e213b7a3a8b80cdbd6bead0b (diff) | |
| download | pi-bitcoindev-955b6eba82c1740eb8cd8995b357e846d837ee4c.tar.gz pi-bitcoindev-955b6eba82c1740eb8cd8995b357e846d837ee4c.zip | |
Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension
| -rw-r--r-- | 6d/882a50c228b8188260092bed1d7c7c233551cd | 190 |
1 files changed, 190 insertions, 0 deletions
diff --git a/6d/882a50c228b8188260092bed1d7c7c233551cd b/6d/882a50c228b8188260092bed1d7c7c233551cd new file mode 100644 index 000000000..8fcbbc3a0 --- /dev/null +++ b/6d/882a50c228b8188260092bed1d7c7c233551cd @@ -0,0 +1,190 @@ +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 <drice@greenmangosystems.com>) 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 <bitcoin-development@lists.sourceforge.net>; + 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: <CANEZrP384LFKaCbAL-p06FQdHHp1bqmcRs+XZDbwVXVrPRDS7g@mail.gmail.com> +References: <CAKrJrGOBSiY5V59eko6g796j3wh9V9ZLjPbyHeS5=zyX6j3Wdw@mail.gmail.com> + <CANEZrP0Euc1mPhRc9e41tU4zMDrWesvVyiBpAPq6M3m7K=aU=A@mail.gmail.com> + <CAFDyEXgKpbE4WGAqROJ4J1UST=tXWgfn7uKhRO_tngJfVK_Czw@mail.gmail.com> + <CADE3-jA8LizD8cjdqKm0pFc8OV7JqPBGhs4uvp6=VhEU2emV6w@mail.gmail.com> + <CANEZrP3KKSkD7_R0Dvt600b7vh0oia78vHhPrPqSGBbwf9DsSQ@mail.gmail.com> + <loom.20140616T181739-326@post.gmane.org> + <CANEZrP3er1NVoAiVmROTxQ3TC80r7enKaHkWjOYTbKehf7qJjQ@mail.gmail.com> + <loom.20140616T184930-521@post.gmane.org> + <CANEZrP2fg9k9fC+QAO2GQS7VC-JCtbEjubHB9j1TJtR9vuaDSQ@mail.gmail.com> + <loom.20140616T190550-931@post.gmane.org> + <CALDj+Bbvvs4rkrSOndk4rbt9JGwSwF1VeFk2XPjFy7Ro4O9heg@mail.gmail.com> + <CANEZrP384LFKaCbAL-p06FQdHHp1bqmcRs+XZDbwVXVrPRDS7g@mail.gmail.com> +Date: Mon, 16 Jun 2014 13:29:54 -0700 +Message-ID: <CAFDyEXg8OnoYCNLT1WeX2tBPTB_zcXsZ6ujP_8YmPvGyf4pzkw@mail.gmail.com> +From: Daniel Rice <drice@greenmangosystems.com> +To: Mike Hearn <mike@plan99.net> +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 <bitcoin-development@lists.sourceforge.net>, + Lawrence Nahum <lawrence@greenaddress.it> +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: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 <mike@plan99.net> 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 + +<div dir=3D"ltr"><div>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.</di= +v> +<div><br></div>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.</div> +<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Mon, Jun 1= +6, 2014 at 11:09 AM, Mike Hearn <span dir=3D"ltr"><<a href=3D"mailto:mik= +e@plan99.net" target=3D"_blank">mike@plan99.net</a>></span> wrote:<br><b= +lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px = +#ccc solid;padding-left:1ex"> +<div dir=3D"ltr"><div>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.</div> + +<div class=3D"gmail_extra"><br>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.<br> + +</div></div> +<br>-----------------------------------------------------------------------= +-------<br> +HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions<b= +r> +Find What Matters Most in Your Big Data with HPCC Systems<br> +Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.<br> +Leverages Graph Analysis for Fast Processing & Easy Data Exploration<br= +> +<a href=3D"http://p.sf.net/sfu/hpccsystems" target=3D"_blank">http://p.sf.n= +et/sfu/hpccsystems</a><br>_______________________________________________<b= +r> +Bitcoin-development mailing list<br> +<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo= +pment@lists.sourceforge.net</a><br> +<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development= +" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de= +velopment</a><br> +<br></blockquote></div><br></div> + +--047d7bdc1a9cd34a9004fbf9e33a-- + + |