Skip to content

Instantly share code, notes, and snippets.

@chris-belcher

chris-belcher/work-diary

Last active Jun 16, 2021
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).
Support this work with a donation: https://bitcoinprivacy.me/coinswap-donations
(Note: I use the datetime format YYYY-MM-DD)
= week-2021-6-7 =
a few more fixes to the announce fidelity bonds PR on joinmarket
wrote a BIP proposal which will slightly improve privacy for off-chain protocols like coinswap and lightning
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019048.html
fixed all the crashes and tests in the announce fidelity bond PR in joinmarket, now just waiting for others
to review and then hopefully its nearly done
my PR to electrum wasnt merged, instead SomberNight wrote code that did the same thing but in his way
https://github.com/spesmilo/electrum/pull/7330#issuecomment-859758732
in either case, its a success from my point of view
= week-2021-5-31 =
created this PR on the electrum github to improve privacy in a very
specific situation: https://github.com/spesmilo/electrum/pull/7330
reviewed and tried out mojo's PR for teleport adding an integration test
more reviewing
waxwing is reviewing my fidelity bonds PR for joinmarket
noticed an easy privacy win here
https://github.com/JoinMarket-Org/joinmarket-clientserver/pull/895
fixed some of waxwing's review comments
some edits of the docs, and one crash bug in wallet-tool's showutxos method
= week-2021-5-24 =
fixed all the other review comments and uploaded the commits
https://github.com/JoinMarket-Org/joinmarket-clientserver/pull/872#issuecomment-849199986
will now do a release of electrum personal server so that the small new features like
nonblocking mempool sync can be used by users
for that i need to update/install virtualbox properly so i can build the exe on
windows, currently stuck on that
done
new release of electrum personal server: https://github.com/chris-belcher/electrum-personal-server/releases/tag/eps-v0.2.2
reading the code of teleport again to try to figure out the best way to improve error handling
this will be needed also to implement the security part of coinswap, for example broadcasting the contract
transactions and being ready to react if another party broadcasts them
= week-2021-5-17 =
made all the edits to fidelity-bonds.md that the reviewers asked for
reading the code to figure out how to fulfil waxwing's review comments
about not having the jmbitcoin package be included in jmdaemon
wrote a part of a solution which involves adding new commands to the
client-daemon protocol used in joinmarket
(just to clear up possible misunderstanding, the client-daemon protocol
is different from the taker-maker protocol also used in joinmarket)
= week-2021-5-10 =
discussed with waxwing and undeath about the fidelity bonds code, they had many questions
wrote docs on the fidelity bond proof protocol https://github.com/JoinMarket-Org/JoinMarket-Docs/pull/4
reviewed and merged two of mojo's PRs on teleport
some more back and forth on the announce fidelity bonds PR and docs PR
merged the docs PR
= week-2021-5-3 =
finished one test which tests the de/serialization of the fidelity bond message
sent from maker to taker
added test which checks for duplicates
reviewed again two PRs
used the c++ code from earlier to calculate another value for the success probability
for a sybil attack, it took 57 hours to run
added appendix 1 to the financial mathematics of fidelity bonds document
https://gist.github.com/chris-belcher/87ebbcbb639686057a389acb9ab3e25b#appendix-1---fit-to-unit-honest-weight-sybil-attack
updated the old fidelity bond wallet code
it broke a bunch of tests which seem like they might take a while to fix
as of now managed to fix all the errors in the tests except for the one about watch-only fidelity bond wallets
fixed now
wrote all the commit messages to be useful for later, until now they were just placeholders
opened the fidelity bonds PR, finally
https://github.com/JoinMarket-Org/joinmarket-clientserver/pull/872
= week-2021-4-27 =
coded up a c++ version of the python script which calculates how much
a sybil attacker would have to spend to attack a joinmarket which has
fidelity bonds
one calculation reduced from 14 hours with python to 1 minute 3 seconds with c++
unfortunately the calculation runtime goes as O(N!) so it may only get
about 2-3 more N values calculated
created a new page for orderbook watcher which displays calculations for how
much it could cost to sybil attack the current offerbook
essentially the calculations here
https://gist.github.com/chris-belcher/87ebbcbb639686057a389acb9ab3e25b#cost-of-sybil-attacks
but on the observed actual offerbook
and its coming together nicely
i think all the code i wanted for using fidelity bonds is now done
i just need to come up with some tests and write those, then ill open a PR
= week-2021-4-19 =
coded the fix to the year 2038 problem with fidelity bonds and merged it
https://github.com/JoinMarket-Org/joinmarket-clientserver/pull/857
finished more or less, code for taker which does the choosing of makers based
on fidelity bonds
now working on little fixes that i didnt do during the main thrust of coding
e.g. making sure two makers can use exactly the same UTXO for a fidelity bond
replaced magic numbers with constants
in the orderbook page on orderbook-watcher, i added code to display fidelity bond
values alongside the offer
reviewed pull requests on the teleport repository
https://github.com/bitcoin-teleport/teleport-transactions/pull/14
https://github.com/bitcoin-teleport/teleport-transactions/pull/15
was thinking about how to code a feature in orderbook watch showing how much a
sybil attack would cost, i had a big realization which will cut down the code
i need to write by a lot
the realization is that they can be cached
and only run once
looking over data now, some coinjoins have even 25 peers, so N=24 makers
so would be nice to calculate up to N=24 while right now i have only up to N=12
will need to quickly rewrite the sybil attack calculations code in c++ instead of python
= week-2021-4-12 =
adding parsing of fidelity bonds to taker and orderbook watch
stuck on some weird parts of the codebase
coding function to check if the fidelity bond UTXO really exists and is confirmed
created a new page for the orderbook watcher where it displays information about all fidelity bonds
including details like locktime, bond value, redeemscript
adding code which creates the feature where takers consider the fidelity bond values when choosing
which offers to use to create a coinjoin with
the fidelity bond wallet code suffered from the year 2038 problem on 32 bit systems
see https://github.com/JoinMarket-Org/joinmarket-clientserver/issues/798
i figured out a solution
= week-2021-4-5 =
currently coding the wallet to choose the most-valuable fidelity bond and announcing it
requires adding new RPC functions
appeared on matt odell's Citadel Dispatch podcast/show with waxwing talking about bitcoin privacy
https://podcasts.apple.com/us/podcast/tales-from-the-crypt-a-bitcoin-podcast/id1292381204?i=1000516047636
= week-2021-3-29 =
testing fidelity bond announcing on regtest on my own irc server running locally
there are weird wallet sync issues
steadily fixing the problems of my first draft
figuring out some ecdsa signature issues
done that
now figuring out how best to connect up the wallet to the fidelity bond announcing
read about Electrum's new version, noticed they save information in op_return
posted an issue on their github describing a better way
https://github.com/spesmilo/electrum/issues/7157
coding function and tests to calculate fidelity bond value given parameters like
the UTXO value, locktime, current time, etc
having problems with running pytest now that i updated ubuntu
fixed by uninstalling then reinstalling
found some subtle mistakes in my document about the maths of fidelity bonds
https://gist.github.com/chris-belcher/87ebbcbb639686057a389acb9ab3e25b
corrected them
= week-2021-3-22 =
reviewed this PR https://github.com/JoinMarket-Org/joinmarket-clientserver/pull/837
opened this one https://github.com/JoinMarket-Org/joinmarket-clientserver/pull/838
they are part of the process of finishing adding fidelity bonds to joinmarket
continued to read code, write notes about adding fidelity bonds and write code
simplified the design from may 2020
figured out parts of the message passing between maker and taker
figured out the signing and verifying parts mostly
= week-2021-3-15 =
figuring out how to do the rest of the adding fidelity bonds to joinmarket
i was working on this back in may 2020 and still have some code and
notes, reading that and rebasing the code onto the current joinmarket
rebase went fine
spent time upgrade my xubuntu as it was reaching the end of life
took a while but upgrade seemed to work fine
= week-2021-3-8 =
worked on the web api rescan feature for EPS
should be quick to code and useful to certain people
turns out it harder to code than i anticipated, because the order that
transactions are imported into Core matters
earlier transactions have to be imported before later ones, otherwise Core rejects them
also with more consideration i think creating such a method which destroys privacy
is on balance a bad thing, even with all the warnings i write in the UI
now working on fully implementing fidelity bonds into joinmarket
currently reading the code to figure out the best way to add them
still need to release a new version of electrum personal server to include
the bugfixes and mempool feature i made
= week-2021-3-1 =
while talking to an EPS user in the wild i came up with another possible solution to
rescanning while in pruned mode:
https://github.com/chris-belcher/electrum-personal-server/issues/85#issuecomment-788353541
might implement it
spent a lot of time on taproot activation, discussing it on IRC, reading and writing
mailing list emails
wrote this to try to bring consensus to the community about activation
Making the case for flag day activation of taproot
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018538.html
https://www.reddit.com/r/Bitcoin/comments/lwvg78/making_the_case_for_flag_day_activation_of_taproot/?
continued to take part in ##taproot-activation
looks like this "speedy trial" idea could be the thing that brings everyone together
= week-2021-2-22 =
merged a couple of open PRs for electrum personal server
edited the README to deal with an issue someone opened
some other fixes
worked on passing an error from tor broadcasting in electrum personal server back to
electrum (see issue https://github.com/chris-belcher/electrum-personal-server/issues/220)
worked on creating a way to obtain the mempool from Core while always keeping the server reponsible
especially useful these days with big mempools
implementing the solution here: https://github.com/chris-belcher/electrum-personal-server/issues/96#issuecomment-481662390
my earlier reddit thread was sticked so spent some time replying to people there
https://www.reddit.com/r/Bitcoin/comments/lm6nmk/another_coinswap_milestone_multihop_coinswaps/
= week-2021-2-15 =
participated in the taproot activation meeting on IRC
created a mailing list post and reddit thread showing the multi-hop coinswap on testnet and
announcing the github project
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018426.html
doing some work on electrum personal server, there have been many bug reports built up over the last
few months which would be nice to fix before going onto other stuff
= week-2021-2-8 =
wrote the text for the mailing list and reddit threads, had writers block for a long time
didnt do much else, felt a bit low energy
= week-2021-2-1 =
now that multihop coinswap is done, im working on refactoring the code to make it readable
because until now it was an unreadable mess
refactored the code which exchanges signatures and proofs between makers
done by splitting off chunks of code into other functions
now the main part of the code is much more readable hopefully, the main loop nearly
fits on one page and because of the function names which act as labels its hopefully
obvious what each if-statement does
did the same refactoring for the hash preimage handover and privkey handover code
used cargo clippy to improve the code a bit
squished and rebased all the git commits, and pushed to github
edited the README to have instructions on how to make a multi-hop coinswap
participated in the ##taproot-activation meeting and talked about it a lot in various
places (reddit, twitter, mastadon, IRC, etc)
did a 5-hop coinswap on testnet
on monday when the internet is more active i will write a mailing list email with the link
to the github and invite people to take a look at the code, the testnet coinswap will be
a nice concrete example of what the software can already do
added a lot of information for developers in the README, including a brief explanation of
how i look at coinswaps and how they work, the aim is to make it as easy as possible for
someone to understand the project
= week-2021-1-25 =
changed `N = 2` to `N = 1` in my code without changing anything else and did a single-hop coinswap
the coinswap seemed to work perfectly, i looked at the wallet-balance to make sure
now trying with N = 3, created a wallet for the third maker
found some weirdness with locktimes, fixed that
found a crash bug with private key handover
seems to be that the privkeys were sent the wrong way around
or not the wrong way round, some else weird is going on..
possibly whats happening is a bug where the taker chooses the wrong WatchOnlySwapCoin object
still working on the private key handover crash bug,
im still thoroughly confused by it
after adding lots more println!() statements, it seems whats happening is taker is receiving privkeys
and then sending those same privkeys back to the same maker
i think the problem is that the taker is sending the wrong multisig_redeemscripts, and so choosing the
wrong set of swapcoins (choosing the outgoing_swapcoins rather than the incoming_swapcoins)
after a few days still stuck on reading the outputs of all the println statements i added everywhere
with massive amounts of hex strings that i all need to keep in my head at once
found the problem:
the statement "if is_taker_next_peer" is false which results in the `outgoing_privkeys` variable being set
and right after that is the statement "if is_taker_previous_peer" which is also false which results in the
same `outgoing_privkeys` being read from
and the total effect is to send the same privkeys the taker just received right back to the maker that sent them
it only appears for multi-hop coinswaps with 3 makers or more, because then is_taker_next_peer and is_taker_previous_peer
can both be false at the same time
fixed by simply reversing the order of the two if-statements
created a multi-hop coinswap with 4 makers, it was done easily by changing a variable from 3 to 4
= week-2021-1-18 =
currently working on fixing a bug where the second maker complains that the
given contract scriptpubkey doesnt match the given contract transaction
after two days of wading through hex strings i finally found the cause of the above crash bug
the next crash bug is that the second maker supposedly returns an invalid signature to the
taker, must investigate
found it cause, the public keys in the 2of2 multisig were swapped around
merged this PR https://github.com/bitcoin-teleport/teleport-transactions/pull/10
got to another crash bug involving an indexing error when handing over hash preimages
fixed the indicies, now onto another error where the same maker is given the hash preimage twice
fixed that
now the two-hop coinswap completes successfully(!)
however now theres an odd error where the wallet-balance display doesn't show any swapcoins, but only
for the taker
restarted everything and the same thing is happening for the maker's wallets, also the only
coins showing up are the non-swapcoin ones
it seems to be that the UTXOs simply arent showing up in `listunspent`
i tried removing the bitcoin core wallet and recovering the teleport wallet
found one weirdness, which is that the result of the `listunspent` RPC call doesnt always have
the witness script
so the coins actually are there, but the code doesn't realize they are swapcoins
looks like it was my mistake, when doing initial sync of a wallet the code imports swapcoin addresses
by their scriptpubkey rather than their descriptor
created commit: c2ea860
still some weirdness where my file maker2.teleport appears to have no swapcoins at all, which isnt possible
theres definite weirdness that multiple .teleport files being imported into Core cause weirdness
as if teleport cant tell which coins really belong to it
rewrote the function, commit: a29b2ea
made a method in main.rs which dumps all the information in the .teleport file
to help with debugging
did another 2-hop coinswap and carefully checked with wallet-balance that the change in the wallet state is
as i expected
= week-2021-1-11 =
finished writing the code for arbitrary multi-hop coinswaps, now have to iron out all the bugs and crashes
trying to do a multi-hop coinswap on regtest, steadily working my way through crash after crash, bug after bug
merged PRs from @theStack
https://github.com/bitcoin-teleport/teleport-transactions/pull/8
https://github.com/bitcoin-teleport/teleport-transactions/pull/9
fixed bug
https://github.com/bitcoin-teleport/teleport-transactions/commit/119497573d30294acb21c2cb50c45404fd569386
this week all of tor's v3 onion addresses were unreachable
https://matt.traudt.xyz/posts/tracking-tors-network-wide-v3-onion-service-outages/
it was a reminder of tor's centralized nature
in my head i planned this project to run entirely over tor, but now i realize how important it is
to have alternatives to tor just in case
so i spent a bit of time thinking about that and writing some notes
created the payjoin adoption wiki page: https://en.bitcoin.it/wiki/PayJoin_adoption
to try to get payjoin adopted more
wrote a mailing list email to explain why its important:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-January/018356.html
= week-2021-1-4 =
still implementing multihop coinswaps with an arbitrary number of hops
using rust's trait feature which i havent used before, so having some trouble
figure it out, thanks again to ##rust on freenode
in multihop coinswaps i implemented the SendersAndReceiversContractSigs protocol message
which is one of the biggest parts because the taker has to obtain those signatures
from different places depending on whether the previous and/or next coinswap peers
are makers or the taker itself
implemented the final SignReceiversContractTx which was also very fiddly
i implemented the entire main for-loop which obtains and relays pubkeys, transactions and
signatures to all the makers
this is hopefully the hardest part over, now just to give the hash preimage to every maker
and relay their privkeys
came up with a slightly better sequence for sending the hash preimage message to makers
= week-2020-12-28 =
writing a bit of pseduocode to figure out the best way to recode multi-hop taker
couldnt figure it out, i will try modifying the taker protocol to do a routed coinswap with 3 makers
and hopefully from that ill figure how to code it for N makers
wrote down a diagram of multi-hop coinswap with 3 makers
had some inspiration about how to code a N-hop coinswap, trying to write some pseudocode in a text file now
wrote the pseudocode which i think should work, coding it in rust now
i realize it would be useful to first implement code on the maker side which allows the taker to disconnect
the tcp connection while waiting for transactions to confirm and then later reconnect
the maker cant handle this right now, and if i code the arbitrary-multi-hop taker this way then it would be
unnecessary technical debt
after reading the maker code carefully, it looks like it already supports tcp connection reconnecting
ill change the code a bit in taker to try it out
tried it out, it works perfectly
will upload this code to the master branch on github because its useful
https://github.com/bitcoin-teleport/teleport-transactions/commit/a4128c6eff34908233c87626e8b21acb1621e350
i came across this paper describing wormhole attacks against the lightning network
https://eprint.iacr.org/2018/472.pdf
reading it because its possible a similar attack will work against routed coinswap
read the relevant section and found that the wormhole attack cant be used, for at least two reasons:
1) makers in coinswap routes dont talk directly to each other
2) payments in routed coinswap cant be cancelled without the detection (the taker will be see the mined contract transactions)
3) the taker releases the hash preimage to every maker directly and simultaneously
= week-2020-12-21 =
writing the sending and receiving of steps C and D in the protocol, which is very fiddly
finished that, writing code to wait for maker2's funding transactions to be confirmed
finished all that code, and the hash_preimage message and the private key handover message
testing multi-hop coinswaps on regtest
run up against a block, for some reason my code thinks the second maker sent an invalid signature
the sender and receiver pubkeys are mixed up for some reason
next bug: when sending hash preimage the multisig redeemscript isnt found by the maker
the receivers_multisig_redeemscripts are not found anywhere else in any debug logs
search for the `senders_contract_tx_info.multisig_redeemscript` in the logs, i bet theres a problem parsing it
wasnt that
found the bug, i accidently used maker1's public keys instead of maker2's, works now
i just the first multi-hop coinswap on regtest(!)
Currently the code is not that great, there is a lot of repeated code as the taker explicitly sends and
receives each message. The multi-hop is fixed at two hops. So will now work on rewriting the code a bit
to remove the duplication and also allow an arbitrary number of hops.
There will essentially be a for-loop which does the multi-hopping.
one thing missing from my code is the taker handling a coinswap between three makers where the
taker's pubkeys are not involved at all, this only happens with a three-maker coinswap or above
= week-2020-12-14 =
finished writing a readme for this early stage of the project
currently using rustfmt on my code for the first time
i uploaded the code i have so far:
https://github.com/bitcoin-teleport/teleport-transactions
its at the pretty early stages, e.g. theres no configuration files you have to edit things in the source
but you can create your own coinswaps on regtest or testnet
along with the IRC channel ##coinswap on the freenode network
set up rustfmt to format my code
started using the izip!() macro to replace the repeated zip(), which improves readability especially
when rustfmt now formats my code the way it wants
starting to figure out how to add multi-hop coinswaps to the taker
in principle the maker's code doesnt need to be edited at all for this
merged a few PRs that people opened on the github
continued to write code for multi-hop coinswaps, got up to the part where the taker
broadcasts their own funding tx, then obtains signatures from maker2 to pass onto maker1
and then waits for confirmation of maker1's funding txes
wrote the sending of the ProofOfFunding message to maker2
= week-2020-12-7 =
the bug i stopped at last week was due to the wallet attempting to spend a coin on a 2of2 multisig
i hadnt implemented that yet, now is a good time so since theres many 2of2 multisig coins building
up in the regtest wallet
implemented spending from 2of2 multisig UTXOs which are completed coinswaps
made the first testnet multi-tx coinswap with random amounts(!)
posted about it on reddit, twitter and mastadon
https://www.reddit.com/r/Bitcoin/comments/k95iu4/the_first_coinswap_on_testnet_massive/
https://twitter.com/chris_belcher_/status/1336323479377911809
https://x0f.org/@belcher/105345215819636699
now working on implementing multi-hop coinswaps
for that the taker will need to connect to multiple makers at once, so i had to spend
a little bit of time figuring out how to use tokio async to do that
also spent time figuring out how to use tcp timeouts with tokio async
which will be required, for example if the taker connects to a maker they need a timeout to recover
from the case where the maker is just unresponsive
figured it out
found and reported a bug in the rust compiler
https://github.com/rust-lang/rust/issues/79913
coded function which connects to multiple makers at once and downloads their offers
quite a few people contacted me about working on coinswap so i think its time to release some code
even if its nowhere near finished
currently writing the README and setting up an IRC channel
= week-2020-11-30 =
continuing to code multi-tx coinswap
after a couple of days, the code for multi-tx is done, and it compiles
now to actually run it on regtest to iron out any bugs there
fixed a bug involving forgetting to unpack a vector of multisig public keys
spent a day or two on another bug which turned out to be nothing to do with my code i think
it was some weirdness where bitcoin core regtest had in its UTXO set that a certain coin had already been spent
but the wallet and `listunspent` still had the coin as unspent, so when it tried to spend it an error happened
pretty weird
i did `rescanblockchain` and it was all fixed
created the first ever multi-tx coinswap on regtest(!)
right now it uses fixed values of the individual coinswaps, ill make it use randomness as
a simple implementation and then do it on testnet
finished writing code which creates random bitcoin amounts to send in the funding transactions
although random, the amounts add up to the total amount that the user wanted to send
its a simple algorithm and theres a lot of scope for improving the building of the multiple
funding transactions, but now for its good
run into a bug, something in the wallet about obtaining UTXOs to spend
= week-2020-11-23 =
working on initial sync of core wallet including coinswap addresses, not just the xpubs
taking me longer than i thought, rust's borrow checker is slowing me down
figured out the borrow checker thing
finished the job of adding sync'ing of coinswap addresses
i wanted to create a coinswap on testnet, but i found a bug where an invalid signature is created, doh
annoyingly the bug doesnt seem to be there on regtest
tracked down the bug to a rounding error, the value 1.24997104 btc was converted to 124997103 satoshi
created the first coinswap on testnet by this project
these transactions dont look very special (which is the point) but they are coinswaps
taker pays 0.05 tbtc to the multisig address
https://blockstream.info/testnet/tx/c22909c3723c9754fa34f699b1658dc429dbd22a53634c9880bad4abd0f260a1
maker pays 0.0499 to another multisig
https://blockstream.info/testnet/tx/bec9bca4fd3d36c1cb5e4b870b82c5e37bf450d4f5a74586abca9b01efaf84d9
they follow the coinswap protocol, finally handing over the private keys to each other
even though these coins are unspent (for now), they have shifted possession, the taker really does own
the UTXO worth 0.499 tbtc, and the maker really does own the UTXO worth 0.5 tbtc
(the difference of 0.001 tbtc is the fee paid by the taker to the maker)
the two UTXOs are unconnected on the blockchain
this is not a big first, because waxwing's coinswap experiment from 2017 also created coinswaps on testnet
now to code multi-tx coinswaps
essentially involves replacing a lot of items with vectors of those items
= week-2020-11-16 =
now the basic coinswap code is written im actually trying it out on regtest to get it to actually produce coinswaps
fixed a couple of simple bugs as i go through the coinswap protocol
found a bug in the wallet sync code, have to figure out how to fix it
still trying to reproduce it in a seperate file
found the bug and a workaround
found another bug in my code where for some reason the verifying of a signature fails
found the cause of the above bug, the incoming and outgoing txes were swapped around for some reason
its not swapped around, something more complicated has gone wrong
it looks like the multisig redeemscripts are wrong
found the bug finally, the cause was accidently using the maker's own public key when it shouldve been the taker's
managed to run the code from start to end
i.e. created a coinswap on regtest(!)
edited wallet code to sync and display UTXOs which came from a coinswap for which we have both privkeys
= week-2020-11-9 =
working on handling the signatures which the maker receives from the taker
that requires moving around a bunch of code so that the signatures can be correctly stored in the wallet
fundamentally this is happening because the maker code needs to store information about
the funding tx, contract tx, redeemscripts, etc until the taker replies with a message containing the signatures
finished all the moving code around, and finished the part where maker applies received signatures and
broadcasts his funding tx
finished coding the receiver contract signature message, and all the required infrastructure cod around it
now all thats left is the handover of hash preimages and privkeys
finished handover over preimages and privkeys
now to actually try out all this, up til now ive only been checking it with the rust compiler
also need to add loads of println!() to track whats going on
= week-2020-11-2 =
added the `1 OP_CSV OP_DROP` condition to the contract script to avoid transaction pinning
finished the proof-of-funding message verification, now coding the messages where the maker
requests that his contract transaction is signed
i.e. the reply to the proof-of-funding message
realized that one round trip can be eliminated from the protocol, so i created the plan for that
it works because the original protocol has messages going from one maker to another, but in reality
the messages are all routed via the taker
realized about an attack against a maker im calling the multiple contract attack, which is:
the full description is in my notes, but it requires implementing a cache of (prevout, contract-scriptpubkey)
did that
finished coding the reply to the proof-of-funding message, which is called send-sender-and-receiver-contract-txes
= week-2020-10-26 =
modifying the contract redeemscript i was planning to use, to fix the oversized preimage attack
https://lists.linuxfoundation.org/pipermail/lightning-dev/2016-May/000529
and testing the solution a little bit
wrote code which sends a sender's contract to the other side, check it and sign it, and sends back the signature
while working on the code to allow sync'ing multiple wallets, i found
this bug in rust-bitcoin https://github.com/rust-bitcoin/rust-bitcoincore-rpc/issues/148
working on the proof-of-funding message, which is a message sent when a funding transaction has confirmed
and therefore proves to the other party that the whole exchange of messages isnt a DOS
= week-2020-10-19 =
added print statements to bitcoin core, and used them to confirm that the sighashes of
the two transactions (one which works, one which doesnt work) are the same
i fed the sighash printed by bitcoincore into my rust code, then the resulting signature
was correct. so that means the problem lies somewhere in the part which calculates a sighash from
the transaction
found the issue, turns out i passed the wrong script to the sighash function, i should have passed
script_code but instead passed hash(script_code) [also called script pub key]
finished the function which creates a funding transaction
including automatically obtaining the next change address
wrote code which creates sender contract transactions (e.g. Alice-Bob/Alice contract tx)
also creating coinswap addresses (2of2 multisig) using the EC tweak scheme, and saving
these to the wallet file
started modifying wallet code so that the same full node can handle multiple instances
for example multiple makers and one taker, which is needed for testing
= 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
@themighty1

This comment has been minimized.

Copy link

@themighty1 themighty1 commented Oct 28, 2020

Nice work, Chris, thanks for keeping this. It is inspiring to read.

@ta32

This comment has been minimized.

Copy link

@ta32 ta32 commented Dec 5, 2020

if you do some work on rust either learning or creating a prototype could you consider streaming it on twitch? Would be interesting to watch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment