BIP Draft: Internet Payment Protocol for Bitcoin Payments

shivaenigma commented at 10:28 am on March 4, 2026: none

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

Added BIPS proposal files aad4d1cf29

in bips-x402b.mediawiki:21 in aad4d1cf29

16+
17+==Motivation==
18+
19+[https://www.coinbase.com/en-sg/developer-platform/discover/launches/x402 x402 Protocol] was announced in May 2025. It allows APIs, apps, and AI agents to transact seamlessly, unlocking a faster, automated internet economy. It has been widely adopted in the crypto / ecommerce ecosystem validating the need of crypto powered internet payment protocol. However, bitcoin support has been missing.
20+
21+Given some historical context, support of HTTP status code 402 has been discussion in bitcoin since 2011 [https://bitcointalk.org/index.php?topic=3895.0 [1]] [https://www.reddit.com/r/Bitcoin/comments/27g1z0/402_payment_required_this_code_is_reserved_for/ [2]]. The community though hasn't formally published a protocol thus impeding its usage.

murchandamus commented at 2:24 pm on March 4, 2026:

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 commented at 2:09 am on March 5, 2026:

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)

in bips-x402b.mediawiki:27 in aad4d1cf29

22+
23+==Challenges==
24+Implementing x402 in bitcoin has various challenges, which we delve into: 
25+
26+# Address Generation:
27+## In bitcoin wallets, unique address is generated for each ecommerce order. This doesn't scale in case of agentic payments as in a hour there could be thousands of order requests that cannot be rate limited with human captcha. Adddress generation without actual payments can only continue till BIP44 gap limit (default 20). High gap limit values result in slowing down funds discovery of the BIP44 wallet.

murchandamus commented at 2:27 pm on March 4, 2026:

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 commented at 1:50 am on March 5, 2026:

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.

jonatack commented at 2:35 pm on March 4, 2026: member

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.”

jonatack closed this on Mar 4, 2026

in bips-x402b.mediawiki:38 in aad4d1cf29

33+===Core Payment Flow===
34+We retain the core concepts and nomenclature of [https://github.com/coinbase/x402/blob/main/specs/x402-specification-v1.md x402 specification] making modifications where necessary. This helps existing x402 clients to easily add bitcoin support
35+
36+# Client Request: Client makes a request to a resource server
37+# Payment Required Response: If no valid payment is attached, the server responds with a payment required signal and payment requirements
38+# Payment Payload Request: Client submits hex encoded data of bitcoin transaction signed with SIGHASH_SINGLE flag in the subsequent request. All inputs and one change output is signed. Client doesn't broadcast the transaction. Client also adds a unique nonce to uniquely identify the request

murchandamus commented at 2:41 pm on March 4, 2026:

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 commented at 1:58 am on March 5, 2026:

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 :smile_cat:

murchandamus commented at 3:51 pm on March 5, 2026:

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

murchandamus commented at 2:43 pm on March 4, 2026: member

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

shivaenigma commented at 2:12 am on March 5, 2026: none

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 commented at 3:54 pm on March 5, 2026: member

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.

BIP Draft: Internet Payment Protocol for Bitcoin Payments #2112