hardfork(v4): Spam deterrence

.cargo/config.toml

@@ -10,6 +10,9 @@ linker = "arm-linux-gnueabihf-gcc"
 [target.'cfg(all(windows, target_env = "msvc"))']
 rustflags = ["-C", "link-arg=/STACK:8388608"]
 
+[target.'cfg(macos)']
+rustflags = ["-C", "link-arg=-Wl,stack_size,41943040"]
+
 # For the GNU/MinGW tool-chain
 [target.'cfg(all(windows, target_env = "gnu"))']
 linker = "x86_64-w64-mingw32-g++" # Use g++ driver so -lstdc++ gets pulled in automatically

.github/workflows/ci.yml

@@ -87,14 +87,14 @@ jobs:
           - target: x86_64-pc-windows-gnu
             os: ubuntu-22.04
 
-    runs-on: ${{ matrix.host }}
+    runs-on: ${{ matrix.os }}
     if: github.event_name == 'push' || !github.event.pull_request.draft
     steps:
       - uses: actions/checkout@v4
       - name: Setup build environment (cli tools, dependencies)
         uses: ./.github/actions/setup-build-environment
         with:
-          host: ${{ matrix.host }}
+          host: ${{ matrix.os }}
           target: ${{ matrix.target }}
 
       - name: Build binary
@@ -117,21 +117,21 @@ jobs:
       fail-fast: false
       matrix:
         os: [ubuntu-22.04, macos-15]
-    runs-on: ${{ matrix.host }}
+    runs-on: ${{ matrix.os }}
     if: github.event_name == 'push' || !github.event.pull_request.draft
     steps:
       - uses: actions/checkout@v4
       - name: Setup build environment (cli tools, dependencies)
         uses: ./.github/actions/setup-build-environment
         with:
-          host: ${{ matrix.host }}
+          host: ${{ matrix.os }}
 
       - name: Run monero-harness tests
-        if: matrix.host == 'ubuntu-22.04'
+        if: matrix.os == 'ubuntu-22.04'
         run: cargo test --package monero-harness --all-features
 
-      - name: Run library tests for swap
-        run: cargo test --package swap --lib
+      - name: Run library tests
+        run: cargo test  --lib
 
   docker_tests:
     strategy:
@@ -182,6 +182,12 @@ jobs:
             test_name: alice_broken_wallet_rpc_after_started_btc_early_refund
           - package: swap
             test_name: happy_path_alice_does_not_send_transfer_proof
+          - package: swap
+            test_name: partial_refund_bob_claims_amnesty
+          - package: swap
+            test_name: partial_refund_alice_burns
+          - package: swap
+            test_name: partial_refund_alice_grants_final_amnesty
           - package: monero-tests
             test_name: reserve_proof
           - package: monero-tests

.helix/ignore

@@ -1,2 +1,4 @@
 src-tauri/gen/
+monero-sys/monero/
+monero-sys/monero-depends/
 

AGENT.md

@@ -0,0 +1 @@
+AGENTS.md

AGENTS.md

@@ -0,0 +1,50 @@
+ - Read CONTRIBUTING.md and the code style guidelines!
+ - When asked about libp2p, check if a rust-libp2p folder exists which contains the cloned rust libp2p codebase. Read through to figure out what the best response it. If its a question about best practice when implementing protocols read @rust-libp2p/protocols/ specificially.
+ - Never do `cargo clean`. Building `monero-sys` takes ages, and cleaning the build cache will cause a full rebuilt (horrible).
+   `cargo clean` has never fixed a build problem.
+ - Before suggesting a change, always give at least a short (1 sentence) summary of which function you are editing and why.
+ - When being asked to add something, check whether there is a similar thing already implemented, the architecture of which you can follow.
+   For example, when asked to add a new Tauri command, check out how other tauri commands are implemented and what conventions they follow.
+ - 
+
+ - Think about seperation of concerns. This has many facets. But the most ofen there are questions like:
+   "Which part of the code should decide how to handle this situation". In the context of an error, the solution is:
+   - Never use fallback values. They lead to
+     - swallowed errors
+     - breaking invariances
+     - breaking other implicit assumptions
+     - destroy any meaning the value might have had.
+     Instead, if an error/invlaid state is encountered, the error should be propagated.
+     This is most often correctly done by using anyhow's "Context" and the question mark operator`.context("Failed to <foo>")?`.
+   - Keep error handling simple: it is basically never wrong to just propagate the error using `?` and maybe add some basic context.
+
+  Other facetts of seperation of concern include:
+   - should this function need to have access to this <implementation detail>?
+   - should this function decide a parameter itself or just take an argument?
+
+  We follow the principle of LEAST SURPRISE. Take a step back, and come back with a fresh view. Then ask yourself: "would I expect this function to do <X>?".
+  If not, then don't do it. 
+
+- coding style tips:
+  - keep the code succint. Prefer `if let` and `let ... else` to `match` whenever possible.
+  - avoid nesting if possible.
+  - prefer early returns to nesting.
+
+- Docker tests: We have an extended test suite that simulates a whole blockchain environment for the purpose of testing swaps end to end.
+  The docker tests are located in `swap/tests` and can be executed using `just docker_test <name>`. Get a list of all docker tests by `just list-docker-tests`.
+- If you changed something could possibly affect the success of a swap, make sure to run the integration tests that could possibly be affected.
+  Be very liberal with assuming what might be affected.
+- If not explicitly instructed yet, ask the user whether you should add {unit, integration} tests if you just added / changed some behaviour/code
+- The docker tests are long (multiple minutes) and produce tens of thousands of log messages.
+  Don't try to read all of that output, it will fill you context up before finishing
+  the initialization.
+  Instead, spawn them as a background-task (each as it's own).
+  Then you can simply check in on the current status by checking it's output every minute or so.
+  If you are claude, use claude codes native background task system and read from the `/tmp/claude/tasks/foo/output.tmp` pipe file, or whatever the path is.
+  If you are not claude, then do the thing that best accomplishises this.
+
+- Before claiming you finished, make sure everything compiles (`cargo c --all-features`).
+  Also all tests (`cargo c --tests`) and all targets (`cargo c --all-targets`) must compile.
+
+
+

CLAUDE.md

@@ -0,0 +1 @@
+AGENTS.md

CONTRIBUTING.md

@@ -6,21 +6,38 @@ Thank you for wanting to contribute to this project!
 
 There are a couple of things we are going to look out for in PRs and knowing them upfront is going to reduce the number of times we will be going back and forth, making things more efficient.
 
+0. **Read and comply with our [AI Policy](AI_POLICY.md)**
 1. We have CI checks in place that validate formatting and code style.
-   Make sure `dprint check` and `cargo clippy` both finish without any warnings or errors.
-   If you don't already have it installed, you can obtain in [various ways](https://dprint.dev/install/).
-2. Run the test suite with [cargo-nextest](https://nexte.st/docs/running/).
-   Install it using `cargo install cargo-nextest` and execute `cargo nextest run`.
-3. All text document (`CHANGELOG.md`, `README.md`, etc) should follow the [semantic linebreaks](https://sembr.org/) specification.
-4. We strive for atomic commits with good commit messages.
+   Make sure the branch is building with `--all-features` and `--all-targets` without errors
+   and all tests are passed.
+2. All text document (`CHANGELOG.md`, `README.md`, etc) should follow the [semantic linebreaks](https://sembr.org/) specification.
+3. We strive for atomic commits with good commit messages.
    As an inspiration, read [this](https://chris.beams.io/posts/git-commit/) blogpost.
    An atomic commit is a cohesive diff with formatting checks, linter and build passing.
    Ideally, all tests are passing as well but we acknowledge that this is not always possible depending on the change you are making.
-5. If you are making any user visible changes, include a changelog entry.
+4. If you are making any user visible changes, include a changelog entry.
 
 ## Contributing issues
 
 When contributing a feature request, please focus on your _problem_ as much as possible.
 It is okay to include ideas on how the feature should be implemented but they should be 2nd nature of your request.
 
-For more loosely-defined problems and ideas, consider starting a [discussion](https://github.com/comit-network/xmr-btc-swap/discussions/new) instead of opening an issue.
+## Code style
+
+### General
+
+ - File structure
+   - The content of each file should be ordered in terms of importance / level of abstraction
+   - Public `struct`s, `enum`s and important constants should be at the top
+   - `impl` blocks should be below the type declarations
+   - Both the type declaration part and the implementation part of the file should be internally ordered by level of abstraction/ importance
+   - For example, `fn main` should always be at least at the top of the implementation 
+ - Prefer early returns over nested `if`/`match` statements
+ - Don't use fallback values or silent failures
+
+### Rust
+
+ - Use `cargo fmt` for formatting
+ - Make use of the powerful `if let` and `let ... else` pattern to enable early returns
+ - Make use of anyhows `.context` method and the `?` operator for concise error reporting
+