Simple Ledger Postage Protocol

[vinarmani]

This protocol enables wallets to be "pure" SLP, not needing to manage additional BCH as "gas" (called "postage" in this spec). This protocol is fully compatible with the existing Simple Ledger Payment Protocol in the official specs.

[imaginaryusername]

Immediate thoughts after a quick look:

1. Thanks for working on this! Such a spec is much needed.
2. It seems useful to include a version field in the response just for convenience. That can be ignored right now for the most part, but will be useful in the future (for smart contracts, different signatures, different address formats, different transaction formats etc)
3. Client side is clearly not broadcasting here - thank goodness
4. Re: JSON Merchant data return: It seems like a possible implementation impediment for the wallet to get the data back, and then forward to another server; would it not be simpler to do that in the background among the servers instead of involving clients? This might involve also shooting the payment protocol data over to the stamp server.
5. In the examples section: Can you include more on the behavior when multiple inputs are included?

[vinarmani]

2. It seems useful to include a version field in the response just for convenience. That can be ignored right now for the most part, but will be useful in the future (for smart contracts, different signatures, different address formats, different transaction formats etc)

Agreed. That is both wise and unobtrusive. It has been added.

4. Re: JSON Merchant data return: It seems like a possible implementation impediment for the wallet to get the data back, and then forward to another server; would it not be simpler to do that in the background among the servers instead of involving clients? This might involve also shooting the payment protocol data over to the stamp server.

This was my initial thought as well. My concern was for privacy and censorship. I have added notes on that topic toward the end of the document.

• Privacy: If the post office is passing transactions on to the merchant payment protocol server, it should be assumed a record of that transaction will be made in the post office's database. This leaves a third party with a potentially sensitive record of a purchase made with a particular merchant. I can see this as being abused at some point
• Censorship: On a similar note, if a post office sees that the transaction is going to pay a business competitor, they may be incentivized to prevent that transaction by making it appear that an error occurred at the payment protocol server. An early example of this is already at play with BitPay, who have locked their BIP70 integrations in their wallets and publicly availble libraries to their own servers, even though this means they are out of spec.

I have added a section on Simple Ledger Payment Protocol servers also offering postage services for their buyers. This will hopefully become the industry standard, but I do think it is important for buyers to be able to get their raw signed tx back to forward it on themselves in edge cases. I don't want to cut that capability out of the spec.

I hope that makes sense.

5. In the examples section: Can you include more on the behavior when multiple inputs are included?

Added.

[imaginaryusername]

Sounds good to me - will love to see if other people can try to poke holes in this as well.

[vinarmani]

Are additional reviews needed before this PR can be merged? I am eager to start getting this added to wallets. I already have it working in a fork of Badger, but I don't want to start releasing these until it's part of the official spec.

Here is a link to a video demo of the protocol working with Badger Chrome Extension for current and future reviewers.

[jcramer]

How is postage paid for a token that doesn't have any value? In the video, there was a postage-paid for, and resulted in the payment of 0.04 USDH to the postage server.

[fyookball]

@vinarmani I should be able to have a look tonight. This wasn't really on our radar, so your patience is appreciated :)

[vinarmani]

James, a postage protocol provider would likely not support a token that had no exchange value. However, there is nothing preventing them from doing so. One example could be a token creator or maintainer offering the service as a loss leader to incentivize usage.

For instance, I could imagine a company providing "free" postage for their rewards point system.

There is a functional post office endpoint at https://pay.cointext.io/postage

[fyookball]

I'd like more time to read and digest slp-postage-protocol.md but I don't see why we shouldn't merge this as it looks well thought out. Unlike SLP token consensus rules, we can easily update this spec later as needed. @jcramer

[jcramer]

@vinarmani thank you for the clarification. That makes sense.

Is there any reason why we might want to allow wallet users to utilize the postage payment service even if they do have BCH, and paying postage using BCH? I was thinking that using a postage-paid with BCH could introduce entropy to provide some additional transaction privacy? Therefore, could this be a good reason to specify how a BCH based postage payment would look like in the "stamps" array of the Postage Rate object?

[vinarmani]

...my main viewpoint is coming from an optimizing UX around allowing a wallet to shop between multiple post-offices.

@jcramer The post office could certainly choose to show different addresses and collect fees on those different addresses. However, having run a business that accepts our revenue as fees on a per transaction basis for a couple of years now, keeping a single fee address ends up being highly preferable for accounting purposes. That being said, if a post office wanted to, for instance, cycle through various addresses associated with a single xPub, they totally could. The post office then would, upon receiving a payment to the server, verify that one of the outputs was associated with some address they had previously responded with (standard behavior for HD wallets) and then make sure it had sufficient postage.

I fully hope that there is an entire ecosystem of post offices and wallets shop around for the best rates. Once they find the best rate, they would simply use that address and endpoint as they proceeded to construct the transaction.

I want to address two of your comments, because I think they are important:

Is there a reason why not to allow BCH as a form of stamp payment?

Stamps are BCH inputs. This would be the equivalent of "paying for BCH with the same amount of BCH" which doesn't really make sense. Unless I am missing something.

Is there any reason why we might want to allow wallet users to utilize the postage payment service even if they do have BCH, and paying postage using BCH?

This is actually not prohibited by the existing protocol spec. It could be done, but this would be quite unadvisable for the user. The user has maximum security and trustlessness if they broadcast an otherwise invalid transaction to the post office. In that case, the only way the post office can receive its fee is to include enough BCH to make the transaction valid. In that case, all incentives are aligned for good behavior. On the other hand, if a user broadcasts a transaction that is actually valid (due to having the requisite amount of native BCH already included as an input), then the post office's incentive is to simply forward on the transaction, receiving a "donation" from the user, without having to provide stamps at all. The user would have neither any recourse nor even the ability to prove that the post office had done anything shady.