Merge pull request #63 from payjoin/docs

Use Docusaurus

.gitignore

@@ -1,5 +1,6 @@
 .DS_Store
 node_modules
+.docusaurus
 /build
 /.svelte-kit
 /package

.prettierignore

@@ -1,13 +1,11 @@
 .DS_Store
 node_modules
 /build
-/.svelte-kit
 /package
+.docusaurus
 .env
 .env.*
 !.env.example
 
-# Ignore files for PNPM, NPM and YARN
-pnpm-lock.yaml
-package-lock.json
+# Ignore files for YARN
 yarn.lock

README.md

@@ -1,6 +1,9 @@
-To run:
+# [payjoin.org](https://payjoin.org)
 
-```
-yarn
-yarn run dev
-```
+Official website for the Payjoin protocol.
+
+To run locally:
+```shell
+yarn install
+yarn start
+```

babel.config.js

@@ -0,0 +1,3 @@
+module.exports = {
+  presets: [require.resolve('@docusaurus/core/lib/babel/preset')],
+};

docs/faq/_category_.json

@@ -0,0 +1,8 @@
+{
+    "label": "Frequently Asked Questions",
+    "position": 2,
+    "link": {
+      "type": "generated-index"
+    }
+}
+

docs/faq/can-i-add-payjoin-to-my-wallet-right-now-using-payjoin-dev-kit.md

@@ -0,0 +1,5 @@
+---
+sidebar-position: 3
+title: Can I add Payjoin to my wallet right now using Payjoin Dev Kit?
+---
+[PDK](https://payjoindevkit.org/) is a Rust library to help your wallet use Payjoin. If your wallet uses another language, we are creating bindings to other languages so it can be used across all sorts of different applications, including mobile apps. The Python bindings are nearly complete.

docs/faq/does-payjoin-require-changes-to-bitcoin.md

@@ -0,0 +1,5 @@
+---
+sidebar-position: 1
+title: Does Payjoin require changes to Bitcoin?
+---
+No. Payjoin was designed with ease of adoption in mind, and requiring consensus changes would be slow and difficult. Payjoin works as a protocol on top of Bitcoin.

docs/faq/why-doesnt-my-wallet-support-payjoin-yet.md

@@ -0,0 +1,5 @@
+---
+sidebar-position: 2
+title: Why doesn’t my wallet support Payjoin yet?
+---
+One of the great things about Payjoin is that it doesn’t require any consensus changes to Bitcoin. The flip side is that it’s up to individual wallets to implement it, and historically there haven’t been many tools to assist developers. Payjoin Dev Kit (PDK) aims to solve this problem as the de-facto library for Payjoin, and it includes Payjoin-cli as a reference implementation. Another barrier has been that the first version of Payjoin required an HTTPS server for a receiver to be running at the time a sender wanted to make a payment. This practically limited Payjoin’s utility to always-online wallets such as merchants. But with the recent development of [Payjoin V2](https://github.com/bitcoin/bips/pull/1483), receivers can create Payjoin transactions asynchronously while offline. This opens up adoption to all types of wallets. If there is a wallet you’d like to see adopt Payjoin or you are a wallet developer and who’d like to integrate it, check out our tutorials or reach out to us for help!

docs/why-payjoin/_category_.json

@@ -0,0 +1,8 @@
+{
+    "label": "Why Payjoin",
+    "position": 1,
+    "link": {
+      "type": "generated-index"
+    }
+}
+

docs/why-payjoin/lightning.md

@@ -0,0 +1,22 @@
+---
+sidebar_position: 3
+title: 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.
+
+![Typical Lightning Channel Open Process](./img/typical-channel-open.png)
+
+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](https://river.com/learn/files/river-lightning-report-2023.pdf) 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](./img/pj-channel-open.png)
+
+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.

docs/why-payjoin/privacy.md

@@ -0,0 +1,11 @@
+---
+sidebar_position: 1
+title: 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 no consensus rule prevents transactions with inputs from multiple sources. Payjoin is the simplest solution.
+
+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.

docs/why-payjoin/scaling.md

@@ -0,0 +1,23 @@
+---
+sidebar_position: 2
+title: Scaling & Fees
+---
+# 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 are limited to around 2MB of data on [average](https://bitcoin.stackexchange.com/a/116350).
+
+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](https://bitcoin.stackexchange.com/questions/103194/confused-about-utxo-management-and-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.
+
+## 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.

docusaurus.config.ts

@@ -0,0 +1,178 @@
+import { themes as prismThemes } from "prism-react-renderer";
+import type { Config } from "@docusaurus/types";
+import type * as Preset from "@docusaurus/preset-classic";
+import tailwindPlugin from "./plugins/tailwind-config.cjs";
+
+const config: Config = {
+  title: "Payjoin",
+  tagline: "Scale Bitcoin, save fees, preserve privacy",
+  favicon: "img/monad.png",
+
+  // Set the production url of your site here
+  url: "https://payjoin.org",
+  // Set the /<baseUrl>/ pathname under which your site is served
+  // For GitHub pages deployment, it is often '/<projectName>/'
+  baseUrl: "/",
+
+  // GitHub pages deployment config.
+  // If you aren't using GitHub pages, you don't need these.
+  organizationName: "payjoin", // Usually your GitHub org/user name.
+  projectName: "payjoin.org", // Usually your repo name.
+
+  onBrokenLinks: "throw",
+  onBrokenMarkdownLinks: "warn",
+
+  // Even if you don't use internationalization, you can use this field to set
+  // useful metadata like html lang. For example, if your site is Chinese, you
+  // may want to replace "en" with "zh-Hans".
+  i18n: {
+    defaultLocale: "en",
+    locales: ["en"],
+  },
+  plugins: [tailwindPlugin,
+    [
+      '@docusaurus/plugin-client-redirects',
+      {
+        redirects: [
+          {
+            to: '/docs/why-payjoin/lightning', // New URL
+            from: '/lightning', // Old URL
+          },
+          {
+            to: '/docs/why-payjoin/scaling',
+            from: '/scale',
+          },
+          {
+            to: '/docs/why-payjoin/privacy',
+            from: '/privacy',
+          },
+        ],
+      },
+    ],
+  ],
+  presets: [
+    [
+      "classic",
+      {
+        docs: {
+          sidebarPath: "./sidebars.ts",
+          // Please change this to your repo.
+          // Remove this to remove the "edit this page" links.
+          editUrl:
+            "https://github.com/payjoin/payjoin.org",
+        },
+        blog: {
+          showReadingTime: true,
+          // Please change this to your repo.
+          // Remove this to remove the "edit this page" links.
+          editUrl:
+            "https://github.com/payjoin/payjoin.org",
+        },
+        theme: {
+          customCss: "./src/css/custom.css",
+        },
+      } satisfies Preset.Options,
+    ],
+  ],
+
+  themeConfig: {
+    // Replace with your project's social card
+    image: "img/monad.png",
+    colorMode: {
+      defaultMode: "dark",
+      disableSwitch: true,
+    },
+    navbar: {
+      style: "dark",
+      title: "Payjoin",
+      logo: {
+        alt: "Monad Logo",
+        src: "img/monad.png",
+      },
+      items: [
+        {
+          type: "docSidebar",
+          sidebarId: "learnSidebar",
+          position: "left",
+          label: "Learn",
+        },
+        { href: "https://payjoindevkit.org/", label: "Dev Kit", position: "right" },
+        {
+          href: "https://discord.gg/6rJD9R684h",
+          label: "Discord",
+          position: "right",
+        },
+        {
+          href: "https://payjoin.substack.com/",
+          label: "News",
+          position: "right",
+        },
+        {
+          href: "https://github.com/payjoin",
+          label: "GitHub",
+          position: "right",
+        },
+      ],
+    },
+    footer: {
+      style: "dark",
+      links: [
+        {
+          title: "Learn",
+          items: [
+            {
+              label: "Payjoin Dev Kit",
+              href: "https://payjoindevkit.org/",
+            },
+            {
+              label: "Case Study",
+              href: "https://bitcoin.design/guide/case-studies/payjoin/",
+            },
+          ],
+        },
+        {
+          title: "Community",
+          items: [
+            {
+              label: "Newsletter",
+              href: "https://payjoin.substack.com/",
+            },
+            {
+              label: "Discord",
+              href: "https://discord.gg/6rJD9R684h",
+            },
+            {
+              label: "Twitter",
+              href: "https://twitter.com/payjoindevkit",
+            },
+            {
+              label: "GitHub",
+              href: "https://github.com/payjoin",
+            },
+          ],
+        },
+        {
+          title: "More",
+          items: [
+            {
+              label: "Donate",
+              href: "https://geyser.fund/project/payjoin/"
+            },
+            {
+              label: "Roadmap",
+              href: "https://github.com/orgs/payjoin/projects/1"
+            }
+          ],
+        },
+      ],
+      copyright: `Copyright © ${new Date().getFullYear()} The Payjoin Developers`,
+    },
+    prism: {
+      theme: prismThemes.github,
+      darkTheme: prismThemes.dracula,
+      additionalLanguages: ["bash"]
+    },
+  } satisfies Preset.ThemeConfig,
+};
+
+export default config;