diff --git a/src/routes/+page.svelte b/src/routes/+page.svelte index 0c0397a..344c2d5 100644 --- a/src/routes/+page.svelte +++ b/src/routes/+page.svelte @@ -68,7 +68,7 @@ If there is a wallet you’d like to see adopt payjoin or you are a wallet devel >Payjoin preserves privacy by breaking common assumptions made for traditional transactions used to spy on bitcoin users - + Learn More @@ -78,7 +78,7 @@ If there is a wallet you’d like to see adopt payjoin or you are a wallet devel >Payjoin can settle many transactions at once, allowing higher throughput, time savings, and opportunistically lower fees - + Learn More @@ -88,7 +88,7 @@ If there is a wallet you’d like to see adopt payjoin or you are a wallet devel >Payjoin allows Lightning nodes to fund and open all their channels in one transaction while maintaining privacy - + Learn More diff --git a/src/routes/lightning/+page.svelte b/src/routes/lightning/+page.svelte new file mode 100644 index 0000000..f23d820 --- /dev/null +++ b/src/routes/lightning/+page.svelte @@ -0,0 +1,69 @@ + + + + Lightning + + +
+

How Payjoin Improves Lightning

+
+
+ The Lightning Network (LN) is a second-layer solution built on Bitcoin that takes transactions + off-chain to allow for near-instant, final settlements with far lower fees, tremendously + increasing transaction throughput, improving privacy, and allowing for new use cases for + Bitcoin such as micropayments. It uses a network of payment channels between nodes to route + payments from source to destination. These channels require node operators to lock up + “liquidity” (bitcoin that can flow between one node and its channel partner) between their + channel partners. How much bitcoin you can spend in a channel is limited by how much liquidity + exists on your side of that channel. +
+
+ Setting up and managing liquidity in a Lightning Node can be cumbersome and expensive. + Transactions can't be sent immediately after the node has synced with the blockchain. You + first have to conduct a two-step process of funding the node's on-chain wallet and then + opening a channel with another node, which involves constructing another on-chain transaction + to lock up the funds between you and your channel partner. This is a two-step process of funding + the node, waiting for at least one confirmation (~10 minutes), then sending a channel open transaction + and waiting another ~10 minutes, paying two fees along the way. This is unnecessarily slow and + expensive. The node operator will likely want to open multiple channels to help ensure against + routing failures and to increase liquidity, making this a repeat process. +
+ Normal Lightning Channel Open Process +
+ Many other technical difficulties in setting up a node can be abstracted away for end users, + but liquidity requirements remain a challenge for all self-custodial nodes. In fact, there is + estimated to be 1 non-custodial user for every 8 custodial users, simply due to the challenges of self-custodial user interfaces — liquidity issues being one + of the primary setbacks. +
+

With Payjoin, We Can Do Better

+
+ Payjoin can simplify this process, saving both money and time by allowing the node operator to + do both the funding and the opening transaction at once. Instead of having to wait for two + transactions to confirm to open one channel, they can wait for one transaction to confirm for + as many channels as they'd like, provided they have sufficient funds. Since payjoin can + create transactions with multiple UTXOs, it can effectively batch transactions and open + multiple channels at once. +
+ Lightning Channel Open with Payjoin +
+ Payjoin also preserves privacy by removing the on-chain footprint (the size of your channels + and who you open channels with) normally left by lightning channels. A transaction sent over a + lightning channel opened via a payjoin transaction has far greater privacy than a normal + on-chain transaction. +
+
+ In summary, payjoin makes channel opens simpler because users now only have to make one + transaction instead of two, faster because they only have to wait for one transaction + to be confirmed, and cheaper because they only have to pay one fee. +
+
+
diff --git a/src/routes/privacy/+page.svelte b/src/routes/privacy/+page.svelte new file mode 100644 index 0000000..7958978 --- /dev/null +++ b/src/routes/privacy/+page.svelte @@ -0,0 +1,35 @@ + + + + Payjoin Privacy + + +
+

Payjoin Privacy

+
+
+ Satoshi left exactly one privacy problem open in the whitepaper, that transactions with + multiple inputs "necessarily reveal that their inputs were owned by the same owner." In early + bitcoin software, this was true. But nothing prevents one from making a transaction with + inputs from multiple sources. Payjoin is the simplest way to do that. +
+
+
+ In a basic bitcoin transaction, a sender spends some bitcoin to a new transaction output + paying someone and makes change from their funds at the same time. A third party looking at + the transaction on chain could assume all input to a transaction must have come from that + sender. +
+
+
+ In Payjoin, the sender and receiver both contribute funds, breaking Satoshi's assumption. The + payment amount plus receiver input amount both go to the receiver and the sender gets change. + Because bitcoin is stored in distinct transaction outputs, and not accounts, such a + transaction looks the same as one where a sender spent multiple inputs to a receiver and made + change. By breaking the assumption from the whitepaper, payjoin makes it much harder to be + sure about who got paid how much. +
+
+
diff --git a/src/routes/scale/+page.svelte b/src/routes/scale/+page.svelte new file mode 100644 index 0000000..489c0fa --- /dev/null +++ b/src/routes/scale/+page.svelte @@ -0,0 +1,85 @@ + + + + Scaling + + +
+

How Does Payjoin Scale Bitcoin?

+
+
+ The Bitcoin blockchain is limited by block size. Approximately every ten minutes a new block + is added to the chain. New blocks add 2MB of data on average [[1]](). Blocks are limited by + transaction weight, or how much of each type of data is included in a transaction. +
+
+ The simplest way to scale any database is batching, which is exactly what Payjoin does. +
+
+ Payjoin enables multiple distinct parties to combine what would otherwise be distinct + transaction intents into a joint transaction which lets them share transaction data they would + otherwise both need to pay to add to the chain. +
+
+
+

Your Typical Payjoin

+
+ In a basic bitcoin transaction, a sender spends some bitcoin to a new transaction output + paying someone and makes change from their funds at the same time. A third party looking at + the transaction on chain could assume all input to a transaction must have come from that + sender. +
+
+ In Payjoin, the sender and receiver both contribute funds, breaking Satoshi's assumption. The + payment amount plus receiver input amount both go to the receiver and the sender gets change. + Because bitcoin is stored in distinct transaction outputs, and not accounts, such a + transaction looks the same as one where a sender spent multiple inputs to a receiver and made + change. By breaking the assumption from the whitepaper, payjoin makes it much harder to be + sure about who got paid how much. +
+
+ The Payjoin using exclusively Pay-to-Taproot addresses (P2TR) + [here](https://mutinynet.com/tx/3c5436f1edf7d4c32a5ccf2448c1e963f52bb8a0fb6f8688d7e78a14e1cbe80b) + is 211.75 vB. An analogous P2TR payment + [here](https://mutinynet.com/tx/2c45dc6fef9feb32b9741cc3e6197eda94e1b0c45675e18818bfadce9fa94e20) + is 152.25 vB and P2TR consolidation + [here](https://mutinynet.com/tx/ef9263ed05c07f7ba933389eee7bfd62372e3dc4d1e697f96b7c66a215cc9b46) + is 168.5 vB, for a total of 320.75 vB. The separate payment and consolidation have to pay for + 51% more block weight to be mined than the Payjoin. What other scaling solution achieves that + kind of savings? +
+ +
+

Opportunistic Consolidation

+ +
+ Payjoin got its start as a way to make a sort of [coinjoin] from a payment. A receiver + combines their input with the sender's, effectively joining a [consolidation]() transaction + with a simple transfer. An observer looking at the payjoin is cannot tell it apart from a + simple transfer where all of the inputs come from the same entity. +
+ +
+ + TODO: visuals +
+ +
not only does the total weight get shaved. wouldn't it be cool when wallet
+
+
+

Transaction Cut-Through

+
+ Payjoin not only creates opportunity to batch consolidation, but may create any output with + the incoming funds. Because payjoin involves live interaction, the receiver may open + lightning channels, forward funds to a different wallet, pay for goods and services, or + batch forward transactions with incoming funds without first taking them into a new UTXO. +
+ + + +
+
+
diff --git a/static/images/lightning-open-without-payjoin.png b/static/images/lightning-open-without-payjoin.png new file mode 100644 index 0000000..f0de248 Binary files /dev/null and b/static/images/lightning-open-without-payjoin.png differ diff --git a/static/images/lightning-payjoin.png b/static/images/lightning-payjoin.png new file mode 100644 index 0000000..24f5650 Binary files /dev/null and b/static/images/lightning-payjoin.png differ