-
Notifications
You must be signed in to change notification settings - Fork 4
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #45 from DanGould/scale
Add link text drafts
- Loading branch information
Showing
6 changed files
with
192 additions
and
3 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,69 @@ | ||
| <script lang="ts"> | ||
| import H1 from '@components/Header/H1.svelte'; | ||
| import H2 from '@components/Header/H2.svelte'; | ||
| import Link from '@components/Link.svelte'; | ||
| </script> | ||
|
|
||
| <svelte:head> | ||
| <title>Lightning</title> | ||
| </svelte:head> | ||
|
|
||
| <section class="text-white mt-24 w-2/3 flex flex-col gap-4 text-xl"> | ||
| <H1>How Payjoin Improves Lightning</H1> | ||
| <div class="flex flex-col gap-4"> | ||
| <div> | ||
| 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. | ||
| </div> | ||
| <div> | ||
| 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 <i>funding</i> the node's on-chain wallet and then | ||
| <i>opening a channel</i> 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. | ||
| </div> | ||
| <img | ||
| src="images/lightning-open-without-payjoin.png" | ||
| alt="Normal Lightning Channel Open Process" | ||
| /> | ||
| <div> | ||
| 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 | ||
| <Link href="https://river.com/learn/files/river-lightning-report-2023.pdf" | ||
| >estimated to be 1 non-custodial user for every 8 custodial users</Link | ||
| >, simply due to the challenges of self-custodial user interfaces — liquidity issues being one | ||
| of the primary setbacks. | ||
| </div> | ||
| <H2>With Payjoin, We Can Do Better</H2> | ||
| <div> | ||
| 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 | ||
| <i>as many channels as they'd like</i>, provided they have sufficient funds. Since payjoin can | ||
| create transactions with multiple UTXOs, it can effectively batch transactions and open | ||
| multiple channels at once. | ||
| </div> | ||
| <img src="images/lightning-payjoin.png" alt="Lightning Channel Open with Payjoin" /> | ||
| <div> | ||
| 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. | ||
| </div> | ||
| <div> | ||
| In summary, payjoin makes channel opens <i>simpler</i> because users now only have to make one | ||
| transaction instead of two, <i>faster</i> because they only have to wait for one transaction | ||
| to be confirmed, and <i>cheaper</i> because they only have to pay one fee. | ||
| </div> | ||
| </div> | ||
| </section> |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,35 @@ | ||
| <script lang="ts"> | ||
| import H1 from '@components/Header/H1.svelte'; | ||
| </script> | ||
|
|
||
| <svelte:head> | ||
| <title>Payjoin Privacy</title> | ||
| </svelte:head> | ||
|
|
||
| <section class="text-white mt-24 w-2/3 flex flex-col gap-4 text-xl"> | ||
| <H1>Payjoin Privacy</H1> | ||
| <div> | ||
| <div> | ||
| 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. | ||
| </div> | ||
| <br /> | ||
| <div> | ||
| 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. | ||
| </div> | ||
| <br /> | ||
| <div> | ||
| 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. | ||
| </div> | ||
| </div> | ||
| </section> |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,85 @@ | ||
| <script lang="ts"> | ||
| import H1 from '@components/Header/H1.svelte'; | ||
| import H2 from '@components/Header/H2.svelte'; | ||
| </script> | ||
|
|
||
| <svelte:head> | ||
| <title>Scaling</title> | ||
| </svelte:head> | ||
|
|
||
| <section class="text-white mt-24 w-2/3 flex flex-col gap-4 text-xl"> | ||
| <H1>How Does Payjoin Scale Bitcoin?</H1> | ||
| <div class="flex flex-col gap-4"> | ||
| <div> | ||
| 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. | ||
| </div> | ||
| <div> | ||
| The simplest way to scale any database is batching, which is exactly what Payjoin does. | ||
| </div> | ||
| <div> | ||
| 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. | ||
| </div> | ||
| </div> | ||
| <div class="flex flex-col gap-4"> | ||
| <H2>Your Typical Payjoin</H2> | ||
| <div> | ||
| 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. | ||
| </div> | ||
| <div> | ||
| 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. | ||
| </div> | ||
| <div> | ||
| 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? | ||
| </div> | ||
|
|
||
| <div class="flex flex-col gap-4"> | ||
| <H2>Opportunistic Consolidation</H2> | ||
|
|
||
| <div> | ||
| 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. | ||
| </div> | ||
|
|
||
| <div> | ||
| <!-- < need visuals > --> | ||
| TODO: visuals | ||
| </div> | ||
|
|
||
| <div>not only does the total weight get shaved. wouldn't it be cool when wallet</div> | ||
| </div> | ||
| <div class="flex flex-col gap-4"> | ||
| <H2>Transaction Cut-Through</H2> | ||
| <div> | ||
| 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. | ||
| </div> | ||
|
|
||
| <!-- https://chaincase.app/words/lightning-payjoin https://payjoin.substack.com/p/interactive-payment-batching-is-better --> | ||
| <!-- [1](https://bitcoin.stackexchange.com/a/116350) {#1} --> | ||
| </div> | ||
| </div> | ||
| </section> |
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.