This is in relation to the Flowee Pay research project (here).
Payment protocol is a way for two wallets to talk to each other and establish an agreement on an actual payment from one to the other. With the outcome that the receiver actually got the transaction as a file and probably it has also send to the network for mining.
This inter-wallet-conversation brings a lot of benefits which improve security and usability. These benefits we know can be had, so lets mark them our goal:
- Merchant gets notified about progress in steps instead of one “done”.
- makes social engineering near impossible.
- Payments are checked by merchant before sending to miners.
- Risky transactions are either rejected of a higher fee is demanded.
- Double Spend risk goes down considerably.
- Customer doesn’t require Internet connection.
- The customer wallet automatically records extra information like who is being paid.
- The customer wallet learns both the BCH value and the Euro/USD value and thus
can inform the customer if the exchange rate is fair.
- There is never any doubt, by both parties, if a payment has succeeded or failed.
- A return-address can automatically be included to refund within the law.
- Merchant can request payment to any script or use any transaction features.
The majority of these are rather easy to get already using the existing BIP70 spec. But BIP70 is showing its age. Specific issues with (pure) BIP70:
- transport layer is essentially impossible to change due to the security design. Specifically its x509 usage.
- wallet to wallet payments are unsupported.
- payments over NFC or bluetooth not supported.
- signing messages is required while the transport layer duplicates this. Overcomplicating things.
- offline payments need more work: if a merchant doesn’t have an UTXO we want to spent it should be possible to suply that.
- Requests unpack the transaction, overcomplicating things. Just send the transaction.
- the sending of a transaction from the wallet to the merchant uses a semi-hardcoded endpoint. Same server as the request but a hard-coded location for the call.
A better design can likely solve all of those quite easy while striving for our goals.