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 1XmN7p-0001m6-RB for bitcoin-development@lists.sourceforge.net; Thu, 06 Nov 2014 13:29:21 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.217.177 as permitted sender) client-ip=209.85.217.177; envelope-from=michaelmclees@gmail.com; helo=mail-lb0-f177.google.com; Received: from mail-lb0-f177.google.com ([209.85.217.177]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1XmN7o-0006PV-Nx for bitcoin-development@lists.sourceforge.net; Thu, 06 Nov 2014 13:29:21 +0000 Received: by mail-lb0-f177.google.com with SMTP id z12so873165lbi.22 for ; Thu, 06 Nov 2014 05:29:14 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.152.30.33 with SMTP id p1mr4999666lah.78.1415280554376; Thu, 06 Nov 2014 05:29:14 -0800 (PST) Sender: michaelmclees@gmail.com Received: by 10.25.129.3 with HTTP; Thu, 6 Nov 2014 05:29:14 -0800 (PST) Date: Thu, 6 Nov 2014 07:29:14 -0600 X-Google-Sender-Auth: 5k-rQOkD6eoJMOiaa9Gow0LXWtM Message-ID: From: Michael McLees To: bitcoin-development@lists.sourceforge.net Content-Type: multipart/alternative; boundary=089e0160ad2ab3846d050730ae16 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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (michaelmclees[at]gmail.com) -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: 1XmN7o-0006PV-Nx Subject: [Bitcoin-development] Nakapay - Proposal for payment method using client generated paycodes and federated paycode servers 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: Thu, 06 Nov 2014 13:29:22 -0000 --089e0160ad2ab3846d050730ae16 Content-Type: text/plain; charset=UTF-8 I sent this yesterday but it is not showing in the archives, so I'm not sure if I did it correctly. I sent it prior to subscribing, so perhaps that mucked it up. nakapay.com I have developed a system whereby a person requesting Bitcoin can make a specific request (amount, address, timeframe, etc...) by only communicating a 6 character paycode to a payer. The system does not require that users sign up for the service; it is open to all. Users may submit information by POST via my API for which I have documentation on the website above. It is my intention to convince wallet developers, merchants, exchanges, and payment processors to integrate my system into their products. Common objections are a lack of use cases and a lack of security. I'd like to explore possible use cases and discuss security with this mailing list. When talking to wallet developers, I've gotten the impression that there is a chicken and egg problem with my product. If no one uses it, they won't develop for it, and if they don't develop for it ... on and on. There are possible monetary incentives for development as there is a possible revenue stream for paycode server operators. I've not used a mailing list like the before, so I'm not sure if this submission is getting where it needs to go. Thank you all for your time and continued efforts to improve Bitcoin. --089e0160ad2ab3846d050730ae16 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I sent this yesterday but it is not showing in the ar= chives, so I'm not sure if I did it correctly. I sent it prior to subsc= ribing, so perhaps that mucked it up.

nakapay.com

I have developed a system whereby a person requesting Bitcoin can make= a specific request (amount, address, timeframe, etc...) by only communicat= ing a 6 character paycode to a payer. The system does not require that user= s sign up for the service; it is open to all. Users may submit information = by POST via my API for which I have documentation on the website above. It = is my intention to convince wallet developers, merchants, exchanges, and pa= yment processors to integrate my system into their products.

Common objections are a lack of= use cases and a lack of security. I'd like to explore possible use cas= es and discuss security with this mailing list.

When talking to wallet developers, I've = gotten the impression that there is a chicken and egg problem with my produ= ct. If no one uses it, they won't develop for it, and if they don't= develop for it ... on and on.

There are possible monetary incentives for development as the= re is a possible revenue stream for paycode server operators.

I've not used a mailing li= st like the before, so I'm not sure if this submission is getting where= it needs to go.

= Thank you all for your time and continued efforts to improve Bitcoin.
=
--089e0160ad2ab3846d050730ae16--