A Nostr client built to create Bitcoin Collaborative transactions, known as Coinjoins. Based on the Joinmarket model where there is a maker and a taker. A maker is always online available to take part in the transaction, and a taker who chooses when and what size of transaction to create.
To incentivize running a maker the taker pays a small fee to the maker for their service. The Maker also has the benefit of gaining privacy from each transaction they participate in so they can choose to set a fee of zero to be more likely to be selected by the taker in a transaction.
I'm currently in the process of changing from using bitcoincore-rpc to BDK, so there is quite a bit of dead or half finished code around, that I'm going to leave until I finish getting BDK to work. Using the bitcoincore-rpc a complete transaction can occur, however it does not actually verify the transaction is correct (ie you don't spend to much on maker fees, the maker gets back what they put in). Since im planning to use BDK for this I'm not going to fix it and just bypass it as a proof of concept.
This is Alpha level software with many things that need to be changed, added, improved and tested, please do not use on mainnet.
An Overview of the order flow.
cargo r -- --rpc-url "<url of bitcoin core RPC API>" --wallet <name of wallet> run-maker
cargo r -- --rpc-url "<url of bitcoin core RPC API>" --wallet <name of wallet> send-transaction --send-amount <Send amount> --number-of-makers <number of makers>
- Mining fee estimation doesn't work
- Does not check for dust
- No coin control to prevent mixing change and CJ
- Maker does not verify that CJ outputs are sent to correct send vs change address
- Update nostr_rust version
Nostr_rust greater then 14 uses a newer version of secp256k1 that causes compatibility issues with version used in rust_bitcoin, should be fixed in next release of rust_bitcoin.
- Events should be verified
- Cleanup, add tests, and COMMENTS
- Move as much code as possible to common not behind features
- BDK has rpc capabilities might be better to use that
- Use Replaceable events for offers
- Delete events when cj completed
- Use ephemeral events for messages (debuging them is a pain so there disabled for now)
- Delete maker offer
- Maker should republish offer after completed Coinjoins
- New key with proof of work?
- Maker republish offer if taker doesn't not respond
- Taker griefing #1
- Taker generates and sends Podle commitment
- Maker validates poodle commitment
- Maker stores lists of used commits and checks it was not used before (this is what makes it useful)
- Should these be gossiped?
- Podle with BDK
- Use nip-40 expiring events for offers
- Fidelity Bond (it'll be a bit)
- Add print outs
- Add Docs
- Electrum, rpc options
- Create CJ satisfaction weight of maker utxos
- Verify transaction
- Maker
- Get what is spent plus maker fee
- Send amount is between min and max
- All are inputs are same address type
- Taker
- All are inputs are same address type (done when creating CJ)
- maker fee is not more then config max
- mining fee is not more then config max
- Maker
Working but should fix
- I'm inconstant about where i loop to send messages, some send message fn accept a vec of the peers and send the messages. some only accept on pub key and loop is in main. Think all should accept vec
My fork of rust-bitcoin-rpc is required as a few functions are not merged upstream. I do intend to clean this up and create a PR to merge upstream as I would rather not depend on forks
Bitcoin core is requited, v23 and v22 have been tested. Other versions may work but have not been tested.
I can be contacted for comments or questions on nostr at _@thesimplekid.com (npub1qjgcmlpkeyl8mdkvp4s0xls4ytcux6my606tgfx9xttut907h0zs76lgjw) or via email tsk@thesimplekid.com.
Code is under the BSD 3-Clause License (LICENSE or https://opensource.org/licenses/BSD-3-Clause)