From d8e5966a501410ae8547ca39787a1325ec5870ec Mon Sep 17 00:00:00 2001 From: mojoX911 Date: Wed, 8 Jan 2025 21:24:49 +0530 Subject: [PATCH 1/4] readme update and remove dev book --- README.md | 2 +- docs/dev-book.md | 271 ----------------------------------------------- 2 files changed, 1 insertion(+), 272 deletions(-) delete mode 100644 docs/dev-book.md diff --git a/README.md b/README.md index d4d0ba18..9f774458 100644 --- a/README.md +++ b/README.md @@ -92,7 +92,7 @@ taker --help `maker-cli`: The RPC controler of the server deamon. This can be used to manage the server, access internal wallet, see swap statistics, etc. App demo [here](https://github.com/citadel-tech/coinswap/blob/master/docs/app%20demos/maker-cli.md) - `taker`: The swap client app. This acts as a regular bitcoin wallet with swap capability. App demo [here](https://github.com/citadel-tech/coinswap/blob/master/docs/app%20demos/taker-tutorial.md) + `taker`: The swap client app. This acts as a regular bitcoin wallet with swap capability. App demo [here](https://github.com/citadel-tech/coinswap/blob/master/docs/app%20demos/taker.md) All the apps will require a Bitcoin Core RPC connection running on testnet4. For running bitcoin instrcutions, see [here](https://github.com/citadel-tech/coinswap/blob/master/docs/app%20demos/bitcoind.md) diff --git a/docs/dev-book.md b/docs/dev-book.md deleted file mode 100644 index 5a3d9821..00000000 --- a/docs/dev-book.md +++ /dev/null @@ -1,271 +0,0 @@ -# Developer resources - - - - [What it is](#what-it-is) - - [How CoinSwap works](#how-coinswap-works) - - [Notes on architecture](#notes-on-architecture) - - [Protocol between takers and makers](#protocol-between-takers-and-makers) - - [Code Structure](#code-structure) - - [Further reading](#further-reading) - - -## What it is -The Coinswap protocol enhances privacy on the Bitcoin network, specifically addressing transaction ownership traceability through chain analysis. - -Imagine Alice wants to send bitcoin with maximum privacy. She initiates a unique transaction that appears ordinary on the blockchain, with her coins seemingly moving from address A to B. However, the coins actually end up in an unrelated address Z. This process confounds any attempt to trace ownership. - -This protocol also benefits users like Carol, who use regular wallets. Her transactions appear the same as Alice's, adding uncertainty to any analysis. Even users unaware of this software enjoy improved privacy. - -In a world where privacy is vital due to data collection by advertisers and institutions, this enhancement is significant. Moreover, it bolsters Bitcoin's fungibility, making it a more effective form of currency. - -## How CoinSwap works - -In a two-party coinswap, Alice and Bob can swap a coin in a non-custodial way, where neither party can steal from each other. At worst, they can waste time and miner fees. - -To start a coinswap, Alice will obtain one of Bob's public keys and use that to create a 2-of-2 multisignature address (known as Alice's coinswap address) made from Alice's and Bob's public keys. Alice will create a transaction (known as Alice's funding transaction) sending some of her coins (known as the coinswap amount) into this 2-of-2 multisig, but before she actually broadcasts this transaction she will ask Bob to use his corresponding private key to sign a transaction (known as Alice contract transaction) which sends the coins back to Alice after a timeout. Even though Alice's coins would be in a 2-of-2 multisig not controlled by her, she knows that if she broadcasts her contract transaction she will be able to get her coins back even if Bob disappears. - -Soon after all this has happened, Bob will do a similar thing but mirrored. Bob will obtain one of Alice's public keys and from it Bob's coinswap address. Bob creates a funding transaction paying to it the same coinswap amount, but before he broadcasts it he gets Alice to sign a contract transaction which sends Bob's coins back to him after a timeout. - -At this point both Alice and Bob are able to broadcast their funding transactions paying coins into multisig addresses, and if they want they can get those coins back by broadcasting their contract transactions and waiting for the timeout. The trick with coinswap is that the contract transaction script contains a second clause: it is also possible for the other party to get the coins by providing a hash preimage (e.g. HX = sha256(X)) without waiting for a timeout. The effect of this is that if the hash preimage is revealed to both parties then the coins in the multisig addresses have transferred possession off-chain to the other party who originally didn't own those coins. - -When the preimage is not known, Alice can use her contract transaction to get coins from Alice's multisig address after a timeout, and Bob can use his contract transaction to get coins from the Bob multisig address after a timeout. After the preimage is known, Alice can use Bob's contract transaction and the preimage to get coins from Bob's multisig address, and also Bob can use Alice's contract transaction and the preimage to get the coins from Alice's multisig address. - -Here is a diagram of Alice and Bob's coins and how they swap possession after a coinswap: -``` - Alice after a timeout - / - / -Alice's coins ------> Alice coinswap address - \ - \ - Bob with knowledge of the hash preimage - - - Bob after a timeout - / - / -Bob's coins ------> Bob coinswap address - \ - \ - Alice with knowledge of the hash preimage -``` - -If Alice attempts to take the coins from Bob's coinswap address using her knowledge of the hash preimage and Bob's contract transaction, then Bob will be able to read the value of the hash preimage from the blockchain, and use it to take the coins from Alice's coinswap address. This happens in the worst case, but in virtually all real-life situations it will never get to that point. The contracts usually always stay unbroadcasted. - -So at this point we've reached a situation where if Alice gets paid then Bob cannot fail to get paid, and vice versa. Now to save time and miner fees, the party which started with knowledge of the hash preimage will reveal it, and both parties will send each other their private keys corresponding to their public keys in the 2-of-2 multisigs. After this private key handover Alice will know both private keys in the relevant multisig address, and so those coins are in her sole possession. The same is true for Bob. - -``` -Alice's coins ----> Bob's address - -Bob's coins ----> Alice's address -``` - -In a successful coinswap, Alice's and Bob's coinswap addresses transform off-chain to be possessed by the other party - - -[Bitcoin's script](https://en.bitcoin.it/wiki/Script) is used to code these timelock and hashlock conditions. Diagrams of the transactions: -``` -= Alice's funding transaction = -Alice's inputs -----> multisig (Alice pubkey + Bob pubkey) - -= Bob's funding transaction = -Bob's inputs -----> multisig (Bob pubkey + Alice pubkey) - -= Alice's contract transaction= -multisig (Alice pubkey + Bob pubkey) -----> contract script (Alice pubkey + timelock OR Bob pubkey + hashlock) - -= Bob's contract transaction= -multisig (Bob pubkey + Alice pubkey) -----> contract script (Bob pubkey + timelock OR Alice pubkey + hashlock) -``` - -The contract transactions are only ever used if a dispute occurs. If all goes well the contract transactions never hit the blockchain and so the hashlock is never revealed, and therefore the coinswap improves privacy by delinking the transaction graph. - -The party which starts with knowledge of the hash preimage must have a longer timeout, this means there is always enough time for the party without knowledge of the preimage to read the preimage from the blockchain and get their own transaction confirmed. - -This explanation describes the simplest form of coinswap. On its own it isn't enough to build a really great private system. For more building blocks read the [design document of this project](https://gist.github.com/chris-belcher/9144bd57a91c194e332fb5ca371d0964). - -## Notes on architecture - -Makers are servers which run Tor hidden services (or possibly other hosting solutions in case Tor ever stops working). Takers connect to them. Makers never connect to each other. - -Diagram of connections for a 4-hop coinswap: -``` - ---- Bob - / - / -Alice ------ Charlie - \ - \ - ---- Dennis -``` - -The coinswap itself is multi-hop: - -``` -Alice ===> Bob ===> Charlie ===> Dennis ===> Alice -``` - -Makers are not even meant to know how many other makers there are in the route. They just offer their services, offer their fees, protect themselves from DOS, complete the coinswaps and make sure they get paid those fees. We aim to have makers have as little state as possible, which should help with DOS-resistance. - -All the big decisions are made by takers (which makes sense because takers are paying, and the customer is always right.) -Decisions like: -* How many makers in the route -* How many transactions in the multi-transaction coinswap -* How long to wait between funding txes -* The bitcoin amount in the coinswap - -In this protocol it's always important to as much as possible avoid DOS attack opportunities, especially against makers. - - -## Protocol between takers and makers - -Alice is the taker, Bob, Charlie and Dennis are makers. For a detailed explanation including definitions see the mailing list email [here](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-October/018221.html). That email should be read first and then you can jump back to the diagram below when needed while reading the code. - -Protocol messages are defined by the structs found in `src/messages.rs` and serialized into json with rust's serde crate. - -``` - | Alice | Bob | Charlie | Dennis | message, or (step) if repeat - |=================|=================|=================|=================| -0. AB/A htlc ----> | | | sign senders contract -1. <---- AB/A htlc B/2 | | | senders contract sig -2. ************** BROADCAST AND MINE ALICE FUNDING TX *************** | -3. A fund ----> | | | proof of funding -4. <----AB/B+BC/B htlc | | | sign senders and receivers contract -5. BC/B htlc ----------------------> | | (0) -6. <---------------------- BC/B htlc C/2 | | (1) -7. AB/B+BC/B A+C/2---> | | | senders and receivers contract sig -8. ************** BROADCAST AND MINE BOB FUNDING TX *************** | -A. B fund ----------------------> | | (3) -B. <----------------------BC/C+CD/C htlc | | (4) -C. CD/C htcl ----------------------------------------> | (0) -D. <---------------------------------------- CD/C htlc D/2 | (1) -E. BC/C htlc ----> | | | sign receiver contract -F. <---- BC/C htlc B/2 | | | receiver contract sig -G.BC/C+CD/C B+D/2-----------------------> | | (7) -H. ************** BROADCAST AND MINE CHARLIE FUNDING TX ************** | -I. C fund ----------------------------------------> | (3) -J. <----------------------------------------CD/D+DA/D htlc | (4) -K. CD/D htlc ----------------------> | | (E) -L. <---------------------- CD/D htlc C/2 | | (F) -M.CD/D+DA/D C+D/2----------------------------------------> | (7) -N. ************** BROADCAST AND MINE DENNIS FUNDING TX *************** | -O. DA/A htlc ----------------------------------------> | (E) -P. <---------------------------------------- DA/A htlc D/2 | (F) -Q. hash preimage ----> | | | hash preimage -R. <---- privB(B+C) | | | privkey handover -S. privA(A+B) ----> | | | (R) -T. hash preimage ----------------------> | | (Q) -U. <---------------------- privC(C+D) | | (R) -V. privB(B+C) ----------------------> | | (R) -W. hash preimage ----------------------------------------> | (Q) -X <---------------------------------------- privD(D+A) | (R) -Y. privC(C+D) ----------------------------------------> | (R) -``` - -## Code Structure - -In the codebase and protocol documentation the words "Sender" and "Receiver" are used. These refer -to either side of a coinswap hop. The entity which created a transaction paying into a coinswap -address is called the sender, because they sent the coins into the coinswap address. The other -entity is called the receiver, because they will receive the coins after the coinswap is complete. - -Protocol messages are defined in two enums in the `src/messages.rs`. The individual message names -use `Send` and `Recv` in them to identify their context as per the above definition. - -```rust -pub(crate) enum MakerToTakerMessage { - /// Protocol Handshake. - MakerHello(MakerHello), - /// Send the Maker's offer advertisement. - RespOffer(Offer), - /// Send Contract Sigs **for** the Sender side of the hop. The Maker sending this message is the Receiver of the hop. - RespContractSigsForSender(ContractSigsForSender), - /// Request Contract Sigs, **as** both the Sending and Receiving side of the hop. - ReqContractSigsAsRecvrAndSender(ContractSigsAsRecvrAndSender), - /// Send Contract Sigs **for** the Receiver side of the hop. The Maker sending this message is the Sender of the hop. - RespContractSigsForRecvr(ContractSigsForRecvr), - /// Send the multisig private keys of the swap, declaring completion of the contract. - RespPrivKeyHandover(PrivKeyHandover), -} -``` -```rust -pub(crate) enum TakerToMakerMessage { - /// Protocol Handshake. - TakerHello(TakerHello), - /// Request the Maker's Offer advertisement. - ReqGiveOffer(GiveOffer), - /// Request Contract Sigs **for** the Sender side of the hop. The Maker receiving this message is the Receiver of the hop. - ReqContractSigsForSender(ReqContractSigsForSender), - /// Respond with the [ProofOfFunding] message. This is sent when the funding transaction gets confirmed. - RespProofOfFunding(ProofOfFunding), - /// Request Contract Sigs **for** the Receiver and Sender side of the Hop. - RespContractSigsForRecvrAndSender(ContractSigsForRecvrAndSender), - /// Request Contract Sigs **for** the Receiver side of the hop. The Maker receiving this message is the Sender of the hop. - ReqContractSigsForRecvr(ReqContractSigsForRecvr), - /// Respond with the hash preimage. This settles the HTLC contract. The Receiver side will use this preimage unlock the HTLC. - RespHashPreimage(HashPreimage), - /// Respond by handing over the Private Keys of coinswap multisig. This denotes the completion of the whole swap. - RespPrivKeyHandover(PrivKeyHandover), -} -``` - -A step-by-step communication sequence for a typical 3-hop-swap with the above messages is provided in [`src/messages.rs`](https://github.com/citadel-tech/coinswap/blob/master/src/protocol/messages.rs#L1-L55), as below. - -``` -//! The simplest 3 hop Coinswap communication, between a Taker and two Makers in a multi-hop coinswap is shown below. -//! -//! Taker -----> Maker1 -----> Maker2 ------> Taker -//! -//! ********* Initiate First Hop ********* -//! (Sender: Taker, Receiver: Maker1) -//! Taker -> Maker1: [TakerToMakerMessage::ReqContractSigsForSender] -//! Maker1 -> Taker: [MakerToTakerMessage::RespContractSigsForSender] -//! Taker -> Maker1: [TakerToMakerMessage::RespProofOfFunding] (Funding Tx of the hop Taker-Maker1) -//! -//! ********* Initiate Second Hop ********* -//! Taker -> Maker1: Share details of next hop. (Sender: Maker1, Receiver: Maker2) -//! Maker1 -> Taker: [MakerToTakerMessage::ReqContractSigsAsRecvrAndSender] -//! Taker -> Maker2: [`TakerToMakerMessage::ReqContractSigsForSender`] (Request the Receiver for it's sigs) -//! Maker2 -> Taker: [MakerToTakerMessage::RespContractSigsForSender] (Receiver sends the sigs) -//! Taker puts his sigs as the Sender. -//! Taker -> Maker1: [TakerToMakerMessage::RespContractSigsForRecvrAndSender] (send both the sigs) -//! Maker1 Broadcasts the funding transaction. -//! Taker -> Maker2: [TakerToMakerMessage::RespProofOfFunding] (Funding Tx of swap Maker1-Maker2) -//! -//! ********* Initiate Third Hop ********* -//! Taker -> Maker2: Shares details of next hop. (Sender: Maker2, Receiver: Taker) -//! Maker2 -> Taker: [MakerToTakerMessage::ReqContractSigsAsRecvrAndSender] -//! Taker -> Maker1: [TakerToMakerMessage::ReqContractSigsForRecvr] (Request the Sender for it's sigs) -//! Maker1 -> Taker: [MakerToTakerMessage::RespContractSigsForRecvr] (Sender sends the the sigs) -//! Taker puts his sigs as the Receiver. -//! Taker -> Maker2: [TakerToMakerMessage::RespContractSigsForRecvrAndSender] -//! Broadcast Maker2-Taker Funding Transaction. -//! Taker -> Maker2: [TakerToMakerMessage::ReqContractSigsForRecvr] -//! Maker2 -> Taker: [MakerToTakerMessage::RespContractSigsForRecvr] -//! Maker2 Broadcasts the funding transaction. -//! -//! ********* Settlement ********* -//! Taker -> Maker1: [TakerToMakerMessage::RespHashPreimage] (For Taker-Maker1 HTLC) -//! Maker1 -> Taker: [MakerToTakerMessage::RespPrivKeyHandover] (For Maker1-Maker2 funding multisig). -//! Taker -> Maker1: [TakerToMakerMessage::RespPrivKeyHandover] (For Taker-Maker1 funding multisig). -//! Taker -> Maker2: [TakerToMakerMessage::RespHashPreimage] (for Maker1-Maker2 HTLC). -//! Taker -> Maker2: [TakerToMakerMessage::RespPrivKeyHandover] (For Maker1-Maker2 funding multisig, received from Maker1 in Step 16) -//! Taker -> Maker2: [`TakerToMakerMessage::RespHashPreimage`] (for Maker2-Taker HTLC). -//! Maker2 -> Taker: [`MakerToTakerMessage::RespPrivKeyHandover`] (For Maker2-Taker funding multisig). -``` - -The `Taker` carries out all the heavy lifting of the protocol. `Maker`s work like simple state-machine responding to `TakerToMakerMessage`s. - -`src/taker/api.rs` : describes the Taker protocol, which is the workflow defined in the [section above](#protocol-between-takers-and-makers). This is the core of the protocol implementation and the most security-critical section of the library. - -`src/maker/api.rs` : describes the Maker state-machine. This is a simple server responding to various `TakerToMakerMessage`s depending on a `ConnectionState`. Each `ConnectionState` will have specific messages as "allowed". The Maker will terminate the protocol if a received message doesn't match the allowed messages of a specific state. - -## Further reading - -* [Waxwing's blog post from 2017 about CoinSwap](https://web.archive.org/web/20200524041008/https://joinmarket.me/blog/blog/coinswaps/) - -* [gmaxwell's original coinswap writeup from 2013](https://bitcointalk.org/index.php?topic=321228.0). It explains how CoinSwap actually works. If you already understand how Lightning payment channels work then CoinSwap is similar. - -* [Design for improving JoinMarket's resistance to sybil attacks using fidelity bonds](https://gist.github.com/chris-belcher/18ea0e6acdb885a2bfbdee43dcd6b5af/). Document explaining the concept of fidelity bonds and how they provide resistance against sybil attacks. - - From b846f708f7100287fb4ab2a66b716d7b732235c1 Mon Sep 17 00:00:00 2001 From: mojoX911 Date: Wed, 8 Jan 2025 22:14:42 +0530 Subject: [PATCH 2/4] fix license --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 9f774458..bb30171d 100644 --- a/README.md +++ b/README.md @@ -11,7 +11,7 @@ Crate Info API Docs --> - MIT or Apache-2.0 Licensed + MIT or Apache-2.0 Licensed CI Status CI Status CI Status From 656873fda8c2d7d6cdefb4bd9fbb4706c66cdd38 Mon Sep 17 00:00:00 2001 From: mojoX911 Date: Wed, 8 Jan 2025 22:20:03 +0530 Subject: [PATCH 3/4] replace signet with testnet4 --- docs/app demos/bitcoind.md | 2 +- docs/app demos/maker-cli.md | 6 +----- docs/app demos/makerd.md | 8 ++++---- docs/app demos/taker.md | 6 +++--- 4 files changed, 9 insertions(+), 13 deletions(-) diff --git a/docs/app demos/bitcoind.md b/docs/app demos/bitcoind.md index 8252e754..4a9ec2da 100644 --- a/docs/app demos/bitcoind.md +++ b/docs/app demos/bitcoind.md @@ -61,7 +61,7 @@ After setting up the configuration file, our node will be ready to run in `regte > **NOTE**: `Regtest` is a toy network that allows for creating custom blocks and generating coins, making it ideal for easy integration testing of applications. -> For actual swap markets, use `Signet`. Switch to `Signet` by setting `signet=1` in the configuration. +> For actual swap markets, use `testnet4`. Switch to `testnet4` by setting `testnet4=1` in the configuration. --- ### **3. Basic Operations** diff --git a/docs/app demos/maker-cli.md b/docs/app demos/maker-cli.md index 49b32490..03167b0e 100644 --- a/docs/app demos/maker-cli.md +++ b/docs/app demos/maker-cli.md @@ -359,11 +359,7 @@ Next, let's send `10,000 sats` from the maker's wallet to an external address. #### **Step 1**: Derive an External Address Using `bitcoin-cli`'s `deriveaddresses` Command ```bash -$ bitcoin-cli deriveaddresses "[0,0]" - -[ - -] +$ bitcoin-cli getnewaddress ``` #### **Step 2**: Use `maker-cli`'s `send-to-address` Command to Send the Amount to the Derived Address diff --git a/docs/app demos/makerd.md b/docs/app demos/makerd.md index 4f30144a..3c14ca80 100644 --- a/docs/app demos/makerd.md +++ b/docs/app demos/makerd.md @@ -71,10 +71,10 @@ This section focuses on `Makerd`, walking you through the process of starting an ### 1. Start Bitcoin Core (Pre-requisite) -`Makerd` requires a **Bitcoin Core** RPC connection running on **Signet** for its operation. To get started, you need to start `bitcoind`: +`Makerd` requires a **Bitcoin Core** RPC connection running on **testnet4** for its operation. To get started, you need to start `bitcoind`: > **Important:** -> All apps are designed to run on **Signet** for testing purposes. The DNS server that Maker connects to will also be on Signet. While you can run these apps on other networks, there won't be any DNS available, so Maker won’t be able to connect to the DNS server or other Coinswap networks. +> All apps are designed to run on **testnet4** for testing purposes. The DNS server that Maker connects to will also be on testnet4. While you can run these apps on other networks, there won't be any DNS available, so Maker won’t be able to connect to the DNS server or other Coinswap networks. To start `bitcoind`: @@ -101,7 +101,7 @@ coinswap 0.1.0 Developers at Citadel-Tech Coinswap Maker Server -The server requires a Bitcoin Core RPC connection running in Signet. It requires some starting balance (0.05 BTC Fidelity + Swap Liquidity). After the successful creation of a Fidelity Bond, the server will start listening for incoming swap requests and earn swap fees. +The server requires a Bitcoin Core RPC connection running in testnet4. It requires some starting balance (0.05 BTC Fidelity + Swap Liquidity). After the successful creation of a Fidelity Bond, the server will start listening for incoming swap requests and earn swap fees. The server is operated with the maker-cli app, for all basic wallet-related operations. @@ -191,7 +191,7 @@ This will launch `makerd` and connect it to the Bitcoin RPC core running on it's > **Note**: Currently The transaction fee for the fidelity bond is hardcoded at `1000 sats`. This approach of directly considering `fee` not `fee rate` will be improved in v0.1.1 milestones. -- Since the maker wallet is empty, we'll need to fund it with at least `0.00051000 BTC` to cover the fidelity amount and transaction fee. To fund the wallet, we can use a Signet faucet from [Signet Faucets](https://signetfaucet.com/). +- Since the maker wallet is empty, we'll need to fund it with at least `0.00051000 BTC` to cover the fidelity amount and transaction fee. To fund the wallet, we can use a testnet4 faucet from [testnet4 Faucets](https://mempool.space/testnet4/faucet). Let's just take `0.01 BTC`testcoins as extra amount will be used in doing wallet related operations in [maker-cli demo](./maker-cli.md) - The server will regularly sync the wallet every 10 seconds, increasing the interval in the pattern 10,20,30,40..., to detect any incoming funds. diff --git a/docs/app demos/taker.md b/docs/app demos/taker.md index 445295b4..3b86f3a2 100644 --- a/docs/app demos/taker.md +++ b/docs/app demos/taker.md @@ -13,10 +13,10 @@ The taker CLI is an application that allows you to perform coinswaps as a taker. ### Start Bitcoin Core (Pre-requisite) -`Taker` requires a **Bitcoin Core** RPC connection running on **Signet** for its operation. To get started, you need to start `bitcoind`: +`Taker` requires a **Bitcoin Core** RPC connection running on **testnet4** for its operation. To get started, you need to start `bitcoind`: > **Important:** -> All apps are designed to run on **Signet** for testing purposes. The DNS server that Taker connects to will also be on Signet. While you can run these apps on other networks, there won't be any DNS available, so Taker won’t be able to connect to the DNS server fir getting maker's offers and can't do coinswap with makers. +> All apps are designed to run on **testnet4** for testing purposes. The DNS server that Taker connects to will also be on testnet4. While you can run these apps on other networks, there won't be any DNS available, so Taker won’t be able to connect to the DNS server fir getting maker's offers and can't do coinswap with makers. To start `bitcoind`: @@ -87,7 +87,7 @@ $ taker -r 127.0.0.1:38332 -a user:pass get-new-address bcrt1qyywgd4we5y7u05lnrgs8runc3j7sspwqhekrdd ``` -Now we can use a Signet faucet to send some coins to this address. You can find a Signet faucet [here](https://signetfaucet.com/). +Now we can use a testnet4 faucet to send some coins to this address. You can find a testnet4 faucet [here](https://mempool.space/testnet4/faucet). Once you have some coins in your wallet, you can check your balance by running the following command: From 64ed9f464803788535f451da46239af164202610 Mon Sep 17 00:00:00 2001 From: KnowWhoami Date: Wed, 8 Jan 2025 22:28:16 +0530 Subject: [PATCH 4/4] update links --- docs/app demos/maker-cli.md | 2 +- src/bin/makerd.rs | 2 +- src/bin/taker.rs | 4 ++-- src/taker/mod.rs | 2 +- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/app demos/maker-cli.md b/docs/app demos/maker-cli.md index 03167b0e..9f095ce7 100644 --- a/docs/app demos/maker-cli.md +++ b/docs/app demos/maker-cli.md @@ -356,7 +356,7 @@ $ ./maker-cli get-new-address ### Spending `10,000 sats` from the Maker's Wallet: Next, let's send `10,000 sats` from the maker's wallet to an external address. -#### **Step 1**: Derive an External Address Using `bitcoin-cli`'s `deriveaddresses` Command +#### **Step 1**: Derive an External Address Using `bitcoin-cli`'s `getnewaddress` Command ```bash $ bitcoin-cli getnewaddress diff --git a/src/bin/makerd.rs b/src/bin/makerd.rs index 621d7142..cde49886 100644 --- a/src/bin/makerd.rs +++ b/src/bin/makerd.rs @@ -9,7 +9,7 @@ use std::{path::PathBuf, sync::Arc}; /// Coinswap Maker Server /// /// The server requires a Bitcoin Core RPC connection running in Testnet4. It requires some starting balance, around 50,000 sats for Fidelity + Swap Liquidity (suggested 50,000 sats). -/// So topup with at least 0.001 BTC to start all the node processses. Suggested faucet: https://mempool.space/testnet4 +/// So topup with at least 0.001 BTC to start all the node processses. Suggested faucet: https://mempool.space/testnet4/faucet /// /// All server process will start after the fidelity bond transaction confirms. This may take some time. Approx: 10 mins. /// Once the bond confirms, the server starts listening for incoming swap requests. As it performs swaps for clients, it keeps earning fees. diff --git a/src/bin/taker.rs b/src/bin/taker.rs index f46f094e..b1b26e29 100644 --- a/src/bin/taker.rs +++ b/src/bin/taker.rs @@ -13,9 +13,9 @@ use std::{path::PathBuf, str::FromStr}; /// /// The app works as regular Bitcoin wallet with added capability to perform coinswaps. The app /// requires a running Bitcoin Core node with RPC access. It currently only runs on Testnet4. -/// Suggested faucet for getting Testnet4 coins: https://mempool.space/testnet4 +/// Suggested faucet for getting Testnet4 coins: https://mempool.space/testnet4/faucet /// -/// For more detailed usage information, please refer: https://github.com/citadel-tech/coinswap/blob/master/docs/app%20demos/taker-tutorial.md +/// For more detailed usage information, please refer: https://github.com/citadel-tech/coinswap/blob/master/docs/app%20demos/taker.md /// /// This is early beta, and there are known and unknown bugs. Please report issues at: https://github.com/citadel-tech/coinswap/issues #[derive(Parser, Debug)] diff --git a/src/taker/mod.rs b/src/taker/mod.rs index c4d4a110..7466ef84 100644 --- a/src/taker/mod.rs +++ b/src/taker/mod.rs @@ -2,7 +2,7 @@ //! //! This also contains the entire swap workflow as major decision makings are involved for the Taker. Makers are //! simple request-response servers. The Taker handles all the necessary communications between one or many makers to route the swap across various makers. Description of -//! protocol workflow is described in the [protocol between takers and makers](https://github.com/citadel-tech/coinswap/blob/master/docs/dev-book.md) +//! protocol workflow is described in the [protocol between takers and makers](https://github.com/citadel-tech/Coinswap-Protocol-Specification/blob/main/v1/3_protocol-flow.md) pub mod api; mod config;