BIP Draft: Internet Payment Protocol for Bitcoin Payments

[shivaenigma]

This BIP defines a protocol by which any actor can perform ecommerce over HTTP using bitcoin payments. It uses HTTP 402 status code

[jonatack]

Thank you for your proposal. It doesn't appear to have followed the workflow described in the README and in https://github.com/bitcoin/bips/blob/master/bip-0003.md#workflow, and particularly the sections below. Please let us know if that is not correct. Closing for now.

---

README:

"People wishing to submit a BIP should first describe their idea to the bitcoindev@googlegroups.com mailing list to gather feedback on viability and community interest before working on a formal description. Please open a pull request to this repository only when substantial progress on the draft has been made, preferably when the draft is nearing completion."

---

BIP 3 workflow:

"After some investigation, the novelty and viability of the idea should be tested by posting a new, dedicated thread about the idea to the Bitcoin Development Mailing List. Prior correspondence can be found in the mailing list archive.

It is recommended that authors establish before or at the start of working on a draft whether their idea may be of interest to the Bitcoin community. Authors should avoid opening a pull request with a BIP draft out of the blue. Vetting an idea publicly before investing time and effort to formally describe the idea is meant to save time for both the authors and the community. Not only may someone point out relevant discussion topics that were missed in the authors’ research, or that an idea is guaranteed to be rejected based on prior discussions, but describing an idea publicly also tests whether it is of interest to more people beside the authors.

As a first sketch of the proposal is taking shape, the authors should present it to the Bitcoin Development Mailing List. This gives the authors a chance to collect initial feedback and address fundamental concerns. If the authors wish to work in public on the proposal at this stage, it is recommended that they open a pull request against one of their forks of the BIPs repository instead of the main BIPs repository."

[murchandamus]

Thanks for your submission. I don’t think this proposal makes sense as proposed.

[murchandamus]

Bitcoin on-chain payments are expected to take up to an hour to be confirmed. It is not clear to me what problem this BIP is addressing and especially it does not explain how the proposed idea improves the situation at all.

[shivaenigma]

This BIP is trying to standardize the use of HTTP 402 for bitcoin payments. In case of USDC x402 the tx confirms in a second or two and the resource is delivered synchronously as part of the HTTP response. For bitcoin, we add a unique nonce to the request. The client polls for transaction confirmation and then retries with nonce (Ref: x402bflow-1.png)

[murchandamus]

The gap limit is more of an end-user problem. Businesses generally just register and track millions of addresses without much problem. The more crucial limitation is that it is unreasonable to expect that you will be able to add thousands of payments per hour to the Bitcoin network on chain.

[shivaenigma]

Tracking millions of addresses is only possible for big exchanges. Try opening electrum for >100,000 addresses and it hangs or take more than hour to sync. Just to clarify out of millions of addresses, transaction will be only present on maybe 10-100 address. So the overhead lies in BIP 44 account discovery .

This is not a big problem currently for human e commerce as the store order system is captcha rate limited. However, in case of agents creating unique address for each request creates many unused addresses which we are trying to avoid.

[murchandamus]

This is technically unsound. If there are multiple inputs, each input with a SIGHASH_SINGLE flag would commit to a different output. Using SIGHASH_SINGLE is also completely insecure and would allow anyone that sees the transaction to attempt diverting the funds to their own wallet by creating a conflicting transactions. The expected outcome is that the sender has no guarantee that the payment actually goes to the recipient.

[shivaenigma]

Thanks for the feedback. I understand now why it is wrong. What I am trying to basically do is to have the agent partially sign the transaction with only its own outputs and have merchant later add his address. With this wallet address generation is deferred to only when a payment is made.

If something like this is possible with PSBT please suggest. I would be glad to incorporate it 😸

[murchandamus]

Part of your proposal is basically trying to reinvent BIP 77 Async Payjoin.

[shivaenigma]

Thank you for your proposal. It doesn't appear to have followed the workflow described in the README and in https://github.com/bitcoin/bips/blob/master/bip-0003.md#workflow, and particularly the sections below. Please let us know if that is not correct. Closing for now.

README:

"People wishing to submit a BIP should first describe their idea to the bitcoindev@googlegroups.com mailing list to gather feedback on viability and community interest before working on a formal description. Please open a pull request to this repository only when substantial progress on the draft has been made, preferably when the draft is nearing completion."

BIP 3 workflow:

"After some investigation, the novelty and viability of the idea should be tested by posting a new, dedicated thread about the idea to the Bitcoin Development Mailing List. Prior correspondence can be found in the mailing list archive.

It is recommended that authors establish before or at the start of working on a draft whether their idea may be of interest to the Bitcoin community. Authors should avoid opening a pull request with a BIP draft out of the blue. Vetting an idea publicly before investing time and effort to formally describe the idea is meant to save time for both the authors and the community. Not only may someone point out relevant discussion topics that were missed in the authors’ research, or that an idea is guaranteed to be rejected based on prior discussions, but describing an idea publicly also tests whether it is of interest to more people beside the authors.

As a first sketch of the proposal is taking shape, the authors should present it to the Bitcoin Development Mailing List. This gives the authors a chance to collect initial feedback and address fundamental concerns. If the authors wish to work in public on the proposal at this stage, it is recommended that they open a pull request against one of their forks of the BIPs repository instead of the main BIPs repository."

Thanks, I understand. I posted on the bitcoin dev mailing 7 days ago and still haven't seen my post appear. Not sure if the post was declined. Please suggest course of action on this. Should I repost ?

[murchandamus]

I think this proposal is fundamentally incompatible with the reality of on-chain transactions. It would be a better fit for a system that is capable of instant payments such as the Lightning Network. However, LN already has L402: https://docs.lightning.engineering/the-lightning-network/l402

So, I don’t think it is necessary to repeat your submission, unless you find a novel way of how your proposal improves on an existing problem.