Nakapay - Looking for feedback and discussion

[michaelmclees]

I've developed a system through which one can request payment and/or pay with Bitcoin using a 6 character paycode. I call it Nakapay.

I'd like to get eyes on it, but not sure if I'm doing it correctly. The prior announcement is below. Is this the kind of thing that would merit a BIP?

"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 and details can be found at 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"

[1714944833]

1714944833

[1714944833]

1714944833

[CIYAM]

With only 6 hex digits it would be way too easy for someone to "mine" an equivalent "address" so I don't see how this can work at all.

IMO QR codes are the best approach by far.

[michaelmclees]

But what they cannot do is mine a collision paycode and create an identical signature of the invoice as a whole.

Further, with the federated paycode server model, they'd need to overwrite the existing invoice on multiple servers simultaneously in order for it to be effective.

[btchris]

With only 6 hex digits it would be way too easy for someone to "mine" an equivalent "address" so I don't see how this can work at all.

IMO QR codes are the best approach by far.

My thoughts exactly. My 3 year old GPU can generate SHA256 hashes at a rate of about 70M/s. 6 hex digits == 2^24 combinations. 70M / 2^23 (combinations on average to find a collision) equals about 0.1 seconds time to fake a paycode.

The signature doesn't seem to help, either. It only proves that an invoice is signed by someone. Of course if a paycode server were to fake an invoice, they would create a perfectly valid signature signed by themselves.

Maybe, if the invoice and the paycode both covered the exact same set of data, such an attack would be more difficult, but at first glance this doesn't seem very safe from MITM.

[CIYAM]

The issue is going to be MITM attacks.

You are going to have to rely upon the CA system and OpenSSL (and you might have noticed the various serious issues with that in recent months).

[btchris]

Further, with the federated paycode server model, they'd need to overwrite the existing invoice on multiple servers simultaneously in order for it to be effective.

An attacker would only need to DOS the other servers such that the attacker's server is the only working server that remains (this is similar to what can happen with Electrum clients that don't do full SPV; the Electrum client does do full SPV but there's at least one client I'm aware of that uses Electrum servers but doesn't do SPV).

[michaelmclees]

With only 6 hex digits it would be way too easy for someone to "mine" an equivalent "address" so I don't see how this can work at all.

IMO QR codes are the best approach by far.

My thoughts exactly. My 3 year old GPU can generate SHA256 hashes at a rate of about 70M/s. 6 hex digits == 2^24 combinations. 70M / 2^23 (combinations on average to find a collision) equals about 0.1 seconds time to fake a paycode.

The signature doesn't seem to help, either. It only proves that an invoice is signed by someone. Of course if a paycode server were to fake an invoice, they would create a perfectly valid signature signed by themselves.

Maybe, if the invoice and the paycode both covered the exact same set of data, such an attack would be more difficult, but at first glance this doesn't seem very safe from MITM.

It does actually. The paycode itself is derived from the contents of the invoice and generated by the merchant himself. The paycode is then incorporated into the body of the invoice and the entire thing is signed using the receiving address of the merchant.

[michaelmclees]

Further, with the federated paycode server model, they'd need to overwrite the existing invoice on multiple servers simultaneously in order for it to be effective.

An attacker would only need to DOS the other servers such that the attacker's server is the only working server that remains (this is similar to what can happen with Electrum clients that don't do full SPV; the Electrum client does do full SPV but there's at least one client I'm aware of that uses Electrum servers but doesn't do SPV).

This is interesting, but it can easily be written into the logic of the paying wallet that if such a thing were to happen, no one gets paid. For example, suppose that there are 5 paycode servers running. If 4 are unresponsive and one is left - the wallet will know that something is amiss and the wallet simply doesn't allow any payment with this method at all.

[CIYAM]

Again you are not handling MITM attacks.

The client may *think* they have 4 valid servers - but they may be actually all be MITM attacks.

How do you *verify* the servers?

[michaelmclees]

The wallet determines which paycode servers from which to pull invoices. If 4 servers are altering the contents of invoices, there are 2 possibilities. Either all the signatures match, meaning they are all being attacked in the same way at the same time by the same person ... or the signatures are all different, in which case no one is paid because no wallet developer would write his app in such a way that when a paycode is sent, and 5 different signatures are received, a random one is chosen.

Further, a good wallet developer would be picky about which servers he uses. So instead of using the Nakapay server, plus 4 others of unknown origin, he's using 5 servers that are tenuously presumed to be trustworthy.

[CIYAM]

Again - I don't think you have *stopped* the attack vectors but I do wish you the best of luck with this.

My personal opinion is that you should consider "stealth" and how that might be able to be used with your idea.

[michaelmclees]

Just a quick question - suppose that the server itself also signed the invoice. So when you enter a code, your wallet is presented not only with the signature of the merchant, but also the signature of the paycode server based on a known, static, receiving address. Would such a thing stop the attack?

Now anyone impersonating Nakapay, for example, would also need to control the publicly known Nakapay address.

Same with all the other paycode servers. So the invoice signatures generated by the merchants are all returned identically, but the paycode server signatures all need to match their respective receiving addresses.

[CIYAM]

But again *how are you securing this*?

My guess is via https and the CA system (how else?).

There have been many recent attacks made upon https and the CA system so I would be very wary about promoting the safety of it.

[michaelmclees]

Well SSL is a given, but with the signature system I'm proposing, I'm not sure it is even necessary.

The goal is to know that a particular paycode corresponds to a particular invoice AND that the invoice hasn't been modified. If multiple servers are returning identical merchant signatures and they are all returning valid server signatures, whether the certificate is valid doesn't seem to matter. So if you were running a server, you'd simply publish a receiving address and sign all valid invoices with it. Anyone with the ability to mimic your signature also controls your wallet.

Even this, assuming multiple servers are used, isn't enough to divert payment - they need to do this to other servers as well to convince wallets that such invoices are legitimate.

[CIYAM]

But how does the client *get the valid signatures* of the servers in the first place?

(this is the attack vector most likely to be used)

[michaelmclees]

The signature isn't published, but rather the receiving address that is always used by that particular server. All this is relayed via POST in my API.

So for example, let's suppose an invoice looks like this...

1BsxY5CntmGxhiG6oRoWMQH46NJGzFbhdm
CIYAM
1BTC
24hours
123ABC
HIqMau/YWyWnWDqdtCwDvpKgNg3esXRij6C8bYoSqjrN7bAvUJRsK0epASyzug65ilC3CTMfrDX7M9fznWLbLM0=
HPCymODWJcKkiM351czoB6uBIaKHMHueKpO2uGbvCAtjTBdD1F0yJ0/PWHMMNh/H7gIkUjsmuLLC6ZB4aTHmCLM=

There are two signatures. The first lines 1-5 signed by 1BsxY5CntmGxhiG6oRoWMQH46NJGzFbhdm, which might be your receiving address in the above example. The second is lines 1-6 signed by Nakapay's publicly known receiving address that is hard coded into the wallets that pull invoices from Nakapay.

You can verify that 1MDwHwniq6qnbieBhhU1kZbgZuhoajc7MD signed it.

[CIYAM]

Okay - well that makes a bit more sense.

I don't have time to look into it more now but hope I've helped at least let you explain your system a bit better.

[michaelmclees]

No problem. Like I said before, I don't even think the 2nd signature is necessary... but what I've learned pitching this is that developers are cautious in the extreme, so if the 2nd signature needs to be part of the protocol before they'll integrate it, then that's what needs to be done.

[michaelmclees]

Bumping for more discussion.

[NanoAkron]

Could you maybe illustrate your idea graphically or with pictures, rather than a text-based description?

Might help me get my head around it.