aljaz/clArk
1
0
Fork 0
mirror of https://github.com/aljazceru/clArk.git synced 2025-12-17 05:04:21 +01:00
Code Issues Packages Projects Releases Wiki Activity

Debugging and README Update (#5)

Browse Source
This commit is contained in:
42Pupusas
2024-06-10 05:43:14 -06:00
committed by GitHub
parent 03bebe62ec
commit 92cb3b15bb
3 changed files with 69 additions and 35 deletions
Download Patch File Download Diff File Expand all files Collapse all files

74
README.md
View File

@@ -14,53 +14,87 @@ a library that contains all the primitives used for these implementations.
You can play around with the tools as follows:
First you have to setup a regtest bitcoind node, there is a script provided for
First you have to setup a `regtest bitcoind` node, there is a script provided for
that. If you want to run your own node, keep in mind that for now, we need it
to have the txindex enabled.
to have the txindex and server options enabled.
```
$ ./run_bitcoind.sh
```
Edit the `bitcoin.conf` file in `test/bitcoindatadir` directory created by the script to include your RPC Auth credentials:
```
rpcauth=<userpw>
```
The field `<userpw>` comes in the format: `<USERNAME>:<SALT>$<HASH>`.
RPC clients connect using `rpcuser=<USERNAME>` and `rpcpassword=<PASSWORD>` arguments.
You can generate this value at [here](https://jlopp.github.io/bitcoin-core-rpc-auth-generator/).
This option can be specified multiple times.
Run the script again, then take note of these lines when starting your node:
```
Binding RPC on address <DOMAIN> port <PORT>
Using random cookie authentication.
Generated RPC authentication cookie <BITCOIND COOKIE>
```
Your `<BITCOIND>` URL will be `<DOMAIN>:<PORT>` and your `<BITCOIND COOKIE>` will be the location where the cookie file was generated.
You can interact with the node using `bitcoin-cli` as follows:
```
$ bitcoin-cli -regtest -rpcuser=user -rpcpassword=pass getnetworkinfo
$ bitcoin-cli -regtest -rpcuser=<USERNAME> -rpcpassword=<PASSWORD> getnetworkinfo
```
Then, you can run an arkd server:
You can create an `arkd` server by running the following command:
```
$ cargo run --bin arkd
$ cargo run --bin arkd create --datadir test/arkd --bitcoind-url <BITCOIND> --bitcoind-cookie <BITCOIND COOKIE>
```
This will start the server and it will work immediatelly. The configuration
currently is hard-coded in the `arkd/src/main.rs` file, and can only be changed
there. For arkd to work properly, you should fund it with some liquidity, this
This will create a new `arkd` server in the `test/` directory. You also can change the parameters as needed using the configuration file that gets created at `test/config.json`.
You can then start the server with:
```
$ cargo run --bin arkd start --datadir test/arkd
```
For `arkd` to work properly, you should fund it with some liquidity, this
can be done by sending some money to the address that is printed out when arkd
is started. You can send money there as follows:
```
$ bitcoin-cli -regtest -rpcuser=user -rpcpassword=pass generatetoaddress 1 <asp-addr>
$ bitcoin-cli -regtest -rpcuser=<USERNAME> -rpcpassword=<PASSWORD> generatetoaddress 1 <asp-addr>
# Then give it 100 confirmations because it's a coinbase output.
$ bitcoin-cli -regtest -rpcuser=user -rpcpassword=pass generatetoaddress 100 mtDDKi5mDjZqGzmbnfUnVQ8ZhCPMPVsApj
$ bitcoin-cli -regtest -rpcuser=<USERNAME> -rpcpassword=<PASSWORD> generatetoaddress 100 mtDDKi5mDjZqGzmbnfUnVQ8ZhCPMPVsApj
```
Next, you can start some clients. To create a client, use the following command:
```
$ cargo run --bin noah -- --datadir ./test/noah1 create
$ cargo run --bin noah -- --datadir ./test/noah2 create
$ cargo run --bin noah -- --datadir ./test/noah1 create --regtest --asp http://<ARKD-URL> --bitcoind <BITCOIND> --bitcoind-cookie <BITCOIND COOKIE>
$ cargo run --bin noah -- --datadir ./test/noah2 create ... same as above
```
These will create individual wallets and print an on-chain address you can use
to **fund them the same way as you did for the ASP above**. Note that clients
can receive off-chain Ark transactions without having any on-chain balance, but
a little bit of on-chain money is needed to perform unilateral exits.
to **fund them the same way as you did for the ASP above**.
To use the onchain wallets, there are a few commands available:
Note that clients can receive off-chain Ark transactions without having any on-chain balance,
but a little bit of on-chain money is needed to perform unilateral exits.
To use the on-chain wallets, there are a few commands available:
```
# First lets fund one wallet
$ NOAH1_ADDR=$(cargo run --bin noah -- --datadir ./test/noah2 get-address)
$ bitcoin-cli -regtest -rpcuser=<USERNAME> -rpcpassword=<PASSWORD> generatetoaddress 1 $NOAH1_ADDR
# Again give it 100 confirmations because it's a coinbase output.
$ bitcoin-cli -regtest -rpcuser=<USERNAME> -rpcpassword=<PASSWORD> generatetoaddress 100 mtDDKi5mDjZqGzmbnfUnVQ8ZhCPMPVsApj
# Then send some money to the other wallet
$ NOAH2_ADDR=$(cargo run --bin noah -- --datadir ./test/noah2 get-address)
$ cargo run --bin noah -- --datadir ./test/noah1 send-onchain $NOAH2_ADDR "0.1 btc"
$ cargo run --bin noah -- --datadir ./test/noah2 balance
@@ -78,23 +112,23 @@ Remember that all txs will just be in the mempool if you don't generate blocks
once a while...
```
$ bitcoin-cli -regtest -rpcuser=user -rpcpassword=pass generatetoaddress 1 mtDDKi5mDjZqGzmbnfUnVQ8ZhCPMPVsApj
$ bitcoin-cli -regtest -rpcuser=user -rpcpassword=pass generatetoaddress 10 mtDDKi5mDjZqGzmbnfUnVQ8ZhCPMPVsApj
```
Then, let's send some money off-chain to a third wallet:
```
$ cargo run --bin noah -- --datadir ./test/noah3 create
$ cargo run --bin noah -- --datadir ./test/noah3 create ... with same flags as before
$ cargo run --bin noah -- --datadir ./test/noah3 balance
# Should be empty..
$ NOAH3_PK=$(cargo run --bin noah -- --datadir ./test/noah3 get-vtxo-pubkey)
# For now every client has just a single pubkey.
$ echo "${NOAH3_PK}"
$ cargo run --bin noah -- --datadir ./test/noah1 send ${NOAH3_PK} "0.1 btc"
$ cargo run --bin noah -- --datadir ./test/noah1 send-round ${NOAH3_PK} "0.1 btc"
$ cargo run --bin noah -- --datadir ./test/noah3 balance
```
You will notice that there is a slight delay when sending, this is because the
client needs to wait for the start of the next round and currently no
out-of-round payments are supported. The round interval can be changed in the
arkd configuration.
`arkd` configuration.

10
noah/src/database.rs
View File

@@ -49,11 +49,8 @@ impl Db {
pub fn store_vtxo(&self, vtxo: &Vtxo) -> anyhow::Result<()> {
let vtxo_tree = self.db.open_tree(VTXO_TREE)?;
let expiry_tree = self.db.open_tree(VTXO_EXPIRY_TREE)?;
(vtxo_tree, expiry_tree).transaction(|(vtxo_tree, expiry_tree)| {
vtxo_tree.insert(vtxo.id(), vtxo.encode())?;
BucketTree::new(expiry_tree)
.insert(vtxo.spec().expiry_height.to_le_bytes(), &vtxo.id())?;
})?;
BucketTree::new(expiry_tree).insert(vtxo.spec().expiry_height.to_le_bytes(), &vtxo.id())?;
Ok(())
}
@@ -93,16 +90,13 @@ impl Db {
pub fn remove_vtxo(&self, id: VtxoId) -> anyhow::Result<Option<Vtxo>> {
let vtxo_tree = self.db.open_tree(VTXO_TREE)?;
let expiry_tree = self.db.open_tree(VTXO_EXPIRY_TREE)?;
Ok((vtxo_tree, expiry_tree).transaction(|(vtxo_tree, expiry_tree)| {
if let Some(v) = vtxo_tree.remove(&id)? {
let ret = Vtxo::decode(&v).expect("corrupt db: invalid vtxo");
BucketTree::new(expiry_tree)
.remove(ret.spec().expiry_height.to_le_bytes(), &id)?;
BucketTree::new(expiry_tree).remove(ret.spec().expiry_height.to_le_bytes(), &id)?;
Ok(Some(ret))
} else {
Ok(None)
}
})?)
}
/// This overrides the existing list of exit claim inputs with the new list.

6
run_bitcoind.sh
View File

@@ -3,5 +3,11 @@
datadir=./test/bitcoindatadir
mkdir -p ${datadir}
conf_file=${datadir}/bitcoin.conf
# Check if bitcoin.conf exists, if not, create it
if [ ! -f "$conf_file" ]; then
touch "$conf_file"
fi
bitcoind -regtest -datadir=${datadir} -server -txindex