Discrete Payments through Wabisabi coinjoins and Nostr ecnrypted communication.md

Author: Kukks

New protocol design: Discrete Payments through Wabisabi coinjoins and Nostr ecnrypted communication

1. Merchant creates invoice of 0.1BTC
2. Merchant generates a unique key for invoice
3. Merchant shows the pubkey of (2), a recommended nostr relay uri
4. Customer generates a unique key for this invoice payment
5. Customer posts an encrypted event addressed to pubkey of (3) with a message stating intent to pay invoice of 0.1BTC using a specific wabisabi coordinator
6. Merchant replies with an encrypted event with acknowledgement (or rejects)
7. Customer joins next round, adds inputs >0.1 BTC, gets credentials
8. Customer reissues credentials, gets one credential of 0.1BTC
9. Customer posts an encrypted event addressed to pubkey of (3) with the credential in a text format
10. Merchant reissues credentials
11. Merchant replies with an encrypted event with acknowledgement (or rejects)
12. Round enters output registration stage
13. Merchant registers outputs
14. Round enters tx signing stage
15. Merchant verifies output is there
16. Merchant replies with an encrypted event stating payment is present in tx hash
17. Customer verifies round tx equals hash
18. Customer signs

Notes:

• a pseudo nostr relay will connect to multiple relays and retrieve all relelavnt events and aggregate. This will then serve them in a unified entrypoint, allowing users to not leak their ip to a dedicated nostr relay for private payments
• Customer specifies which coordinator to use, not tied to only one
• Merchant can provide own coins to same coinjoin to increase anonymity
• Can theoretically chain the payments to other hops within the same coinjoin, serves as a trustless, private layer 3 equivalent to ecash systems, without the custodians (but with a much stricter time horizon)

Savings analysis when applying this tech towards fee savings for businesses (no privacy decomposition done). (yes I used ai to fluff up the text around the formulas)

Detailed Formulas and Analysis of Batching Bitcoin Transactions

Batching transactions in Bitcoin involves combining multiple deposits and withdrawals into fewer transactions to save on fees and reduce UTXO bloat. This process can significantly optimize transaction costs and improve network efficiency. Below, we outline the formulas for calculating transaction sizes and savings across three modes: Single Transaction Mode, Withdrawal Batching Mode, and Full Batching Mode.

Variables and Constants

• N_d: Number of deposits.
• N_w: Number of withdrawals.
• I: Input size in bytes (approximately 148 bytes per input).
• O: Output size in bytes (approximately 34 bytes per output).
• H: Overhead size per transaction (approximately 10 bytes).
• F: Fee rate per byte.
• T: Time interval for batching transactions (e.g., in seconds or minutes).
• λ_d: Average rate of deposit requests per time interval T.
• λ_w: Average rate of withdrawal requests per time interval T.

Transaction Modes

1. Single Transaction Mode
   In Single Transaction Mode, each deposit and each withdrawal are processed as separate transactions. This mode represents the highest cost due to the repeated overhead of many small transactions.

   Transaction Size Calculation:

   • For Deposits: Each deposit transaction has 1 input, 1 output to the business, and 1 change output.
   • For Withdrawals: Each withdrawal transaction has 1 input from the business, 1 output to the user, and 1 change output.

   Total Size for Single Transaction Mode:

   Total Size_single = N_d × (I + O + O + H) + N_w × (I + O + O + H)
   

   Where:

   • The terms account for the input, main output, change output, and transaction overhead for both deposits and withdrawals.

2. Withdrawal Batching Mode
   In Withdrawal Batching Mode, deposits remain as individual transactions, but all withdrawals are combined into a single batched transaction. This mode reduces the overhead cost associated with processing multiple withdrawals separately.

   Transaction Size Calculation:

   • Deposits: Handled individually, with each deposit contributing its inputs and outputs.
   • Withdrawals: All withdrawals are batched into a single transaction, which minimizes the overhead.

   Total Size for Withdrawal Batching Mode:

   Total Size_batch_withdrawal = N_d × (I + O + O + H) + (N_w × I + N_w × O + O + H)
   

   Where:

   • The first part represents individual deposit transactions.
   • The second part combines multiple withdrawals into one transaction with a single overhead.

3. Full Batching Mode
   Full Batching Mode represents the most efficient strategy, where deposits and withdrawals are combined into a single transaction. This mode minimizes the total number of inputs and outputs by using deposits directly to fund withdrawals and consolidating change outputs.

   Transaction Size Calculation:

   • Inputs: Inputs come from user-funded deposits.
   • Outputs: Include outputs for each withdrawal, deposit change outputs, and a single final change output if needed.

   Total Size for Full Batching Mode:

   Total Size_full_batching = N_d × I + (N_w × O + N_d × O + O + H)
   

   Where:

   • Inputs are reduced to the necessary user inputs, and the output count is minimized.

Calculating Savings
To determine the savings achieved by batching methods compared to the baseline single transaction approach, we use the following formulas:

1. Savings Between Single Transaction and Withdrawal Batching:

   Savings_batch_withdrawal = 1 - (Total Size_batch_withdrawal / Total Size_single)
   

2. Savings Between Single Transaction and Full Batching:

   Savings_full_batching = 1 - (Total Size_full_batching / Total Size_single)
   

3. Savings Between Withdrawal Batching and Full Batching:

   Savings_full_vs_withdrawal = 1 - (Total Size_full_batching / Total Size_batch_withdrawal)
   

Forward-Facing Savings and Efficiency Gains
Batching not only provides immediate savings but also leads to forward-facing benefits, including:

1. Reduced UTXO Bloat:

   • Fewer transactions mean fewer UTXOs, simplifying management and lowering future costs.
   • Minimizes the need for costly UTXO consolidation operations.

2. Elimination of Dust Outputs:

   • Efficient batching reduces or eliminates small, unspendable dust outputs, optimizing wallet performance.
   • Prevents clutter and inefficiencies in the UTXO set, contributing to long-term savings.

3. Long-Term Transaction Efficiency:

   • Lower future transaction fees due to fewer required inputs in future transactions.
   • Enhanced wallet performance and reduced blockchain growth, supporting overall network health.

Conclusion
Batching Bitcoin transactions significantly reduces transaction costs by minimizing redundant inputs, outputs, and overhead. Full batching, in particular, achieves the greatest savings by directly utilizing deposits to fund withdrawals and optimizing UTXO management. These savings are compounded over time, making batching a crucial strategy for sustainable and efficient Bitcoin transaction processing.