DPP Proxy

Introduction

According to current Google network statistics, IPv6 adoption is still at around 40% adoption worldwide and nowhere near ideal adoption. The reason why IPv6 has taken this long to be adopted is that even though it is entirely superior to IPv4, so much has been built on top of IPv4 that it has been very hard to change. This is another reason why it is so important for the Bitcoin protocol to remain stable and unchanged so that so much can be built on top of it as well.
When IPv4 was designed, it was not anticipated that there would be so many devices connected to the internet. As a result of the limited amount of IP addresses available with IPv4 along with the billions of devices that need to be and are connected to the internet, we have had to resort to work-around solutions such as IP address mapping and Network Address Translation (NAT). Even though these workarounds do work and get the job done, they are not ideal and do not offer the security and mobility that IPv6 does.
Understanding the IP layer is a prerequisite to answering the question of what this proxy service is and why it is in needed. If IPv6 were used ubiquitously then there would be little need for such a proxy service. However, until we are at that point, we need a proxy service on the receiving end in order for the receiver to be easily publicly accessible on the internet. In order to connect to the receiver device, you need their IP address. First of all, with IPv4 it is not easy to get a public address that can easily connected to because of address exhaustion. The reason for that is that there are not enough addresses to go around and as a result most devices online use private IP addresses and so are forced to connect to hub where connections are routed through. Also, unlike with IPv6 with security built in with extensions such as CGA, with IPv4, TLS and DNS are needed in order to protect against any MITM attacks.
If IPv6 is used then technically this proxy is not exactly needed because it mainly solves the issues present with IPv4. However, another feature that this proxy can offer is the ability to receive payments when offline.
The DPP (Direct Payment Protocol) Proxy allows payments to be made between a sender and a receiver running a DPP proxy. A typical payment process would be as follows:
  • a sender-receiver interaction
  • a four-message interaction as shown below:
    • PaymentTerms
    • Payment
    • PaymentACK (payment acknowledgement)
    • Receipt (Merkle Proof)
Direct Payment Protocol Rest API

Endpoints

The endpoints used by the DPP Proxy are listed below:
Endpoint
Method
Description
Payment
GET
Fetches an invoice based on a unique id
Payment
POST
Submits a payment based on an invoice
Proofs
POST
Returns the Merkle proofs for a transaction once it is included in a block

Source Code

GitHub - bitcoin-sv/dpp-proxy
GitHub