Topic: Payment Address Validation - page 2. (Read 1757 times)

I'm currently working on a payment system. Why not just BitPay or similar? Because some of the content sold may violate their rules, either now or in the future, I honestly don't know and don't care because while the content is not illegal, there is a good chance now or in the future BitPay (or others) will tell me I can't use their service with it. It does violate PayPal rules, and only some credit card processing companies will allow it - and then only with really high TX fee.

Anyway private addresses do not belong anywhere on the server. So the payment addresses have to be generated elsewhere (on an offline computer) and then inserted into a database the web application fetches them from.

That opens it up to the possibility of SQL injection attack - meaning a hacker could inject their own payment addresses into the database.

So to combat that, the master ECDSA key used to generate all the payment addresses is used to create a signature for each payment address.

The web application then grabs both the payment address and the signature and uses the public key from the master ECDSA to verify the payment address before it goes on the invoice for the customer to pay.

That got me thinking - why isn't something like that already part of bitcoin?

What I mean is - a payment address includes a signature as part of the bitcoin uri

The client then fetches the public key used to create the signature via DNS where it is secured by DNSSEC (similar to how DANE works with TLSA records) and then verifies the payment address is valid.

Something like that wouldn't require any changes to the bitcoin protocol itself, just client support. Clients that do not want to do it don't can just ignore the signature.

It would be a form of two-factor authentication so that the end user can verify the address they are paying to does in fact belong to the website they are making a payment to and is not hacker injected.