Skip to content

Instantly share code, notes, and snippets.

@chris-belcher

chris-belcher/work-diary

Last active Oct 19, 2020
Embed
What would you like to do?
Chris Belcher work diary
I keep a diary of all the work I do on bitcoin privacy.
It may also be interesting to my collaborators and donors, and anyone who wants to follow
how my projects are going (these days I'm almost exclusively working on developing
CoinSwap, see https://gist.github.com/chris-belcher/9144bd57a91c194e332fb5ca371d0964).
(Note: I use the datetime format YYYY-MM-DD)
= week-2020-10-12 =
continuing to write the networking and protocol code
fighting with rust's borrow checker a little bit, i slightly rewrote parts of
the earlier wallet code in order to remove some lifetime compile errors
in order to continue writing the networking code, i now need to write code which generates and
checks the on-chain transactions, so that the maker and taker can sign and verify when they
receive network messages
having trouble with the rust-bitcoin dependencies
theres errors that appear when both rust-wallet and rust-bitcoin are included as dependencies
posted an issue here, maybe ill get some help https://github.com/rust-bitcoin/rust-wallet/issues/25
i think right now the most productive way forward is to temporarily remove rust-wallet from my codebase
its only used for mnemonic seed phrases, that can be replaced by having the user store a xprv key
this project will be testnet and regtest only for quite a long time, so theres plenty of time to
figure out the problem or wait for rust-wallet to update, and then put back seed phrases
until then theres plenty of work to be done in coding up the coinswap protocol, and that doesnt
need seed phrases
actually a possibly better solution, the dependency trouble comes when mixing types across
the two crates, i could just not do that
for example when having a ExtendedPubKey from rust-wallet, convert it to string then convert
that to an ExtendedPubKey from rust-bitcoin
theres a problem with the Bitcoin::Network enum but perhaps theres a workaround
figured out later that its pretty easy to workaround
managed to do the above, so all the types from rust-wallet are completely seperate from rust-bitcoin
appeared on a bitcoin magazine streamed conversation https://twitter.com/BitcoinMagazine/status/1316800930638032896
working on creating and signing a transaction, which i previously wouldve used rust-wallet for
but now will figure it out just with rust-bitcoin
having some trouble with it, managed to successfully sign exactly the same transaction with rust-wallet
so now im just carefully printing going through the tx byte-by-byte figuring out why the other code fails
tried to use a debugger to step into the library and figure how whats different, but couldnt get it to work
= week-2020-10-5 =
created the boilerplate code for maker and taker networking with tokio
am able to add new network messages now fairly easily
the code requests and serves up coinswap offers
because it uses async with tokio then the server is automatically able to handle multiple clients
using serde enum representations for the messages: https://serde.rs/enum-representations.html
this really helps because we can use the compiler for extra type checking and readability
= week-2020-9-28 =
spent most of the time recovering from my operation, but still did some work when i was able to
finished first draft of fixes to protocol design
published to mailing list
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-October/018221.html
its very useful to carefully think about all the protocol steps like this, because
then edge-cases and attacks can be more easily found
now coding the networking code for the final coinswap app
= week-2020-9-21 =
helped someone who messaged me twitter debug their electrum personal server installation
wrote a full design for a two-party coinswap which contains all those fixes, most notably collateral payments
going to the hospital for an operation, so most likely wont work for the rest of the week
= week-2020-9-14 =
still coding what will eventually be the internal wallet
ran into this issue https://github.com/rust-bitcoin/rust-bitcoincore-rpc/issues/136
thankfully @shesek also wrote a workaround
sadly this workaround wasnt sufficent, used a quick hack for now which ill fix later
using importmulti with bitcoincore_rpc seems to be a bit fiddly
got it to work
now have code which imports addresses and sync's a wallet, and supports seed phrase backups
now ill write a second version of the protocol design which fixes the issues found in review
of the first one
= week-2020-9-7 =
finished coding wallet generation and recovery, now coding wallet sync
had medical issues and hospital visits this week so did a bit less work
= week-2020-8-31 =
possibly made another breakthrough with fixing the vulnerability found by
ZmnSCPxj, about riskless theft attempts, it involve having the outgoing side
(e.g. alice in a simple alice-bob coinswap) be required to include her own
single-sig input to a contract transaction, then the riskless theft attempt
can be made to have an explicit cost
i'm calling it "collateral payments"
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018151.html
read https://doc.rust-lang.org/cargo/index.html
made a start on coding the actual coinswap application (finally)
started coding the part which generates and recovers a new single-sig wallet
= week 2020-8-24 =
made a short script which does the EC key tweaking from my detailed protocol design email
so that peers can agree on public keys with one fewer round trip
read this blog for a while to learn rust more
https://fasterthanli.me/articles/working-with-strings-in-rust
https://fasterthanli.me/articles/declarative-memory-management
https://fasterthanli.me/articles/a-half-hour-to-learn-rust
https://fasterthanli.me/articles/i-am-a-java-csharp-c-or-cplusplus-dev-time-to-do-some-rust
Antoine Riard found two attacks with my protocol design
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-August/018135.html
- after the preimage reveal the previous hop can still broadcast a high-fee
contract tx to burn the next hop's funds
the high-fee contract tx must exist and be known to both sides in order to
make sure the contract tx gets confirmed even if mempools are congested
this can perhaps be solved using anchor outputs instead of RBF, as is already
designed for lightning
- a malicious taker can use CPFP to pin a low-fee contract tx to stop it being
RBF-bumped, and while its stuck get the other contract tx confirmed to take
its money. Once that money is taken the malicious taker can allow the first
contract tx to be confirmed and take it's money too.
this seems like it can also be solved by using just a single contract tx and
using CPFP to fee-bump instead of RBF
possibly made a breakthrough with fixing these vulnerabilities
im considering having the two peers (alice and bob, say) know slightly different
versions of the contract transactions
= week 2020-8-17 =
still working on figuring out how to use rust-bitcoin to create and spend from 2of2 multisigs
stuck a bit, might have to go through the transaction byte-by-byte
managed to get spending from a 2of2 multisig to work
now figuring out how to create and spend-from a htlc contract with rust-bitcoin
spending from with both routes (by waiting for a timeout, or by providing a hash value)
reading in detail bip112 and bip68
ZmnSCPxj replied to my mailing list email with a possible concerning problem (riskless theft
attempts) that i need to obsess over for a while. this ultimately happens because the timelock
and hashlock contract is known to both sides together
successfully made a short script which creates and spends from a htlc contract with rust-bitcoin
it is able to spend both by providing the hash preimage and by waiting for the timeout
= week 2020-8-10 =
fixed up "protocol-design-final" and sent to the mailing list
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-August/018080.html
spoke on this podcast
https://twitter.com/blockdigest/status/1293275473938710535
reading code and figuring out exactly how to create and spend from a 2of2 multisig address using rust-bitcoin
= week 2020-8-3 =
continuing to work on the detailed design of the protocol
came up with an attack on my earlier design which included miner fees
where a malicious taker Alice could cause maker Bob to waste all his money on miner fees
and wrote down a defence against this attack
see the note (4/8/2020) in file "routed-coinswap-with-miner-fees"
started a document called "user warnings" to jot down things which will need to be in the user manual
e.g. you have a risk that your coins will be locked up for a little bit (same as in lightning channel unilateral close)
finished the document "multi-tx-routed-coinswap-with-branching" which has the detailed protocol design
that was a great exercise and i found a couple of edge cases
now ill work on the final protocol design which includes every feature, and then publish that for review
finished first draft of document "protocol-design-final", so now need to read it closely again and
eventually send it to the dev mailing list for review
= week 2020-7-27 =
posted my review in the taproot PR in secp256k1
https://github.com/bitcoin-core/secp256k1/pull/558
still have medical problems meaning i cant work as much
working on protocol design for how takers and makers communicate, and what transactions they broadcast when
handling miner fees seems to be an issue, i must come up with a good way to handle it
designed a whole protocol for routed coinswaps which entirely handle miner fees
written in the file "routed-coinswap-with-miner-fees"
while designing this i came across a possible problem i hadnt forseen
i call it the "who goes first in routed coinswaps" problem
after a lot of thinking and writing, i came up with a solution to it which should work
the solution is based on using retaliation to make it not possible to DOS for free
= week 2020-7-20 =
used rust-bitcoin and rust-wallet to sign a transaction
worked much less this week due to medical issues
reviewing code from libsecp256k1
<gmaxwell> https://github.com/bitcoin-core/secp256k1/pull/558 This is the libsecp256k1 PR for BIP340, it's
the majority of the lines of code of the taproot change. It could really use more reviewers, and was recently
squashed after lots of revisions from review.
edit: 2020/9/11 merged finally! https://twitter.com/pwuille/status/1304504395384512512
= week 2020-7-13 =
reading
https://rust-lang.github.io/async-book
read the book
its still unfinished, lots of TODOs
ill play with the http server example in the book, and maybe learn more from there
studying the bwt project which uses async via tokio and async-std
tokio and async_std are both used in http.rs only
the tokio pages are useful
intend to play with this example https://tokio.rs/docs/getting-started/echo/
created small tokio demo scripts, such as:
heartbeat - prints a message at reguler intervals
two heartbeats - prints two different messages at two different regular intervals
multi heartbeats - prints N different messages are N different intervals, for arbitrary number N
decided not to figure out how to make multi_heartbeat because ill never use something like that
it requires figuring out how to make the join! macro work for a list of futures
later i found out you can do that with futures::future::join_all
created a heartbeat server - which accepts tcp connections and at regular intervals sends a message down all the client sockets
read a bit of bwt to see how it uses async, with tokio and async_std
reading the code of https://github.com/stevenroose/hal/
which steven roose linked to me in an email exchange
skimmed that code, i think i understand it at a high level
managed to use the RPC library to obtain the best block hash from bitcoind
one snag was that i accidently used the wrong username and password, and
the error message was not descriptive enough
i decided to open an issue about it https://github.com/rust-bitcoin/rust-bitcoincore-rpc/issues/117
= week 2020-7-6 =
continuing work on rust http server
learning about tests, seperate modules, using cargo to run tests
file and path handling in rust
slowly improving the server
coded a function which generates a MIME type for the http reply
implemented http keep-alive instead of closing the connection after each request
have the server creates an index page if a directory is GET requested, that page lists all the files within it
used the external crate chronos to order to format the Date Modified as a string nicely
then will move onto implementing an async version of the server
start with having two applications in the project, the second one for async
= week 2020-6-29 =
finished the rust irc bot
it features:
* connects to a network and irc channel
* keeps track of nicks in the channel along with their op powers (including voice and half-op)
* keeps track of updates to above by watching for MODE messages
* if a nick addresses the bot by name it will reply "hello", if the nick has ops it replies "hello sire"
* allows op'd users to use the command !raw which sends a raw message to the server, which can be
used for sending QUIT and testing how the bot handles the server closing the connection
* implements heartbeat by using socket timeouts, which could be used for pinging the server to keep the connection alive
i learned lots about rust; such as borrowing, lifetimes, collections, tcp sockets, string parsing
skim read some other irc bots in rust
* https://github.com/treeman/rustbot
* https://github.com/aatxe/irc
this appears to be _the_ irc lib for rust, and it also uses asyncio which i want to learn too
read the chapter on cargo in the rust book, i skipped it last time
read the code of bwt again, i think i got more from it on this second reading
starting to code a http server
aiming to write test-driven code as i go
use the automated code formatting
aiming to first have a single-thread single-socket model, then move to asyncio
actually not asyncio, maybe do it with multiple threads and then asyncio, the async rust book is unfinished
seperate files and modules, one mod controlling the protocol parsing, so later it can be dropped into the async version
two binary files, one for single-client other for async, might work
= week 2020-6-22 =
still writing an irc bot in rust, learning a lot about string manipulation, and with rust's borrowing feature
answered some issues on the EPS github
reviewed the release notes of the next joinmarket version
still writing the irc, more things about ownership
every time i run into an issue i search the web to read more details
the &str type has functions called `to_string()` but `as_bytes()`
turns out `as_` implies conversion, `to_` implies allocation, and this is a common pattern in rust libs
still coding rust, learned a couple of things about ownership and lifetimes
fixed joinmarket issue #610 and tested waxwing's PR #611 finding a bug
= week 2020-6-15 =
still reading the rust book
finished the rust book except the cargo chapter
coded a rust script to generate a heatmap of the sin function
also calculated the value of pi using a monte carlo simulation
started writing a script to generate "worlds" of particles for the software KDE-step
ill generate a galaxy, then two galaxies colliding
this is useful to practice using iterators and structs in rust
started studying bwt, now seems like a good time to read other people's code
finished the skim reading
started writing an irc bot in rust
= week 2020-6-8 =
got a grant from the Human Rights Foundation
gave interview with Alyssa Hertig who will write an article about CoinSwap on coindesk
gave interview with Aaron van Wirdum journalist
continued reading the rust book
discussed coinswap and payjoin on the bitcoin dev mailing list
and taint analysis
reviewed the python-bitcointx pull request on joinmarket
https://github.com/JoinMarket-Org/joinmarket-clientserver/pull/536
set up a date for a podcast recording on the whatbitcoindid podcast
= week 2020-6-1 =
still learning rust
did the exercises in the rust book about collections (calculating averages)
merged the fidelity bond wallets PR
discussed on the bitcoin dev mailing list
went on the Tales From The Crypt podcast
https://anchor.fm/tales-from-the-crypt/episodes/170-Chris-Belcher-ef8blj
released electrum personal server 0.2.1
= week 2020-5 25=
published coinswap design document to the mailing list, and github gist
started working on `announce-fidelity-bonds` branch which edits the joinmarket makers and takers to create and parse fidelity bonds announcements
it assumes the fidelity bond wallet branch is merged, which iv been waiting to get tested/reviewed enough to merge
started learning rust, working through the rust book
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.