So I've been working on something for some time now. Like many here, I've long felt that one of the primary things holding Bitcoin back from mainstream adoption is that the actual payment procedures that we use currently are too cumbersome, too alien, and too difficult for a casual first time user to wrap their minds around.
Bitcoin as a payment system is a complex notion as it is; it doesn't need to also be complex to use.
Various efforts attempt to solve this problem, but users are still waiting for a user interface moment.
I present to you Nakapay. nakapay.com
Nakapay is a protocol that can be used by a Bitcoin wallet to request and send Bitcoin without involving QR codes, e-mail, hyperlinks, usernames, passwords, Bluetooth, or a specific location. It is also wallet agnostic, meaning any wallet developer who wishes to let their users use Nakapay may do so.
How will it look in a wallet?Using Nakapay means one takes on the role of either a merchant or customer. A merchant can simply be seen as an entity or wallet that is requesting Bitcoin; a customer is the party that sends Bitcoin.
A merchant simply uses a Nakapay compatible wallet to generate an invoice, which can be done by merely entering an amount of Bitcoin the merchant wishes to receive and a time limit on the invoice. The wallet will present a paycode to the merchant, consisting of 6 characters with numbers 0-9 and letters A-F. They look like this, 398F22, AA90CA, or 89DAA1. The merchant communicates the paycode generated to the customer in any manner the merchant desires.
The customer, using a wallet that has integrated Nakapay, enters the paycode into his wallet. His wallet then populates the amount and address the merchant is requesting. It also reveals how much time the customer has to pay the invoice before the merchant may consider it to be invalid. The customer verifies that everything looks correct and pays.
What kind of safety processes are in place?When pitching this concept to various wallet developers, I was met with a concern that such a system, while convenient, is unsafe because the paycode server can modify invoices. Customers entering a paycode thinking they are paying .1 BTC to their friend might inadvertently being paying 10 BTC to either Nakapay or some attacker. This is obviously a legitimate concern.
There are 3 layers of protection. The first layer is within the rules of the protocol itself. The way that a paycode is generated has to do with the contents of the invoice itself. Paycodes are truncated SHA-256 hashes, where the paycode consists of the first 6 characters of the hash. The data being hashed is the content of the invoice: the amount, address, name of merchant (not verified or needed), timestamp of invoice, and timestamp and expiration time. A server attempting to falsify invoices will be required to create and invoice that generates a paycode identical to the paycode entered by the customer.
Second, the invoice, including the paycode, is signed by the merchants wallet using the key of the receiving address. Any customer (or merchant, or anyone just entering random paycodes for that matter) will receive the signed invoice and can verify that the person who created the invoice has control of the address within. One cannot modify an invoice without invalidating the signature. Therefore, a merchant wallet that generates an invoice should also request the generated invoice from the paycode server and only treat the paycode as valid and unmodified if the signature returned is identical to the signature sent.
Third, Nakapay does not intend to run a exclusive paycode server. If a number of entities operate separate servers, wallets generating invoices may submit invoices to multiple paycode servers. Customers may submit identical paycodes to multiple paycode servers as well, and ideally, all servers should return identical invoice signatures. If, for example, four of five servers return identical signatures (invoice must be identical), and one returns a different signature, it may be inferred that either the invoice has been tampered with, the server is holding an old invoice, or a user submitted an invoice to that server alone before the subsequent user sent his invoice to the five servers.
Over time, which paycode servers are reliable, colluding, fraudulent, etc... will be sussed out.
At the present time, if you'd like to run your own paycode server, you may. If you'd like to purchase a copy of my software, please contact me and we can try to work out a deal.
How does Nakapay intend to make money?Initially, the service will be run for free. At some point in the future, if the service is seen as viable, convenient, and trustworthy, the plan is to charge users for revealing the merchant's receiving address. The fee that I have in mind is somewhere in the neighborhood of .1% to .25%, which means that if Nakapay receives an invoice for 1 BTC to merchant's address, it reveals everything to anyone using the paycode, save for the merchant's address until a fee of .0025 BTC is paid to a fee address controlled by Nakapay. After the fee is paid, the server reveals the entire invoice. No confirmations are necessary for the fee payment.
Other paycode servers are free to operate under any payment scheme they wish.
Where is your API documentation?https://mega.co.nz/#!QBImCbrC!xly7IS49gSuhvDzi5LtobVZXEiSsC7KcHoH8B-IqKjM
I'd like to use Nakapay, but there are no wallets that have integrated it. How can I help?If you are a Bitcoin user, encourage the developers of the wallets, merchants, and Bitcoin services you use to incorporate Nakapay into their systems.
If you are a Bitcoin developer, especially a wallet or payment processor developer, work to incorporate Nakapay into your wallet or invoice services.
One thing to keep in mind is that just as Bitcoin augments traditional payment systems, I envision Nakapay as augmenting the traditional methods of populating a Bitcoin wallet.
I'd like to talk more about this with you. How can I contact you?michael.nakapay@gmail.com
Show Posts
