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)
It’s been one year since I stopped working on my Bitcoin projects. Many people donated money to me. They deserve to know what’s going on. I have severe long Covid. It has utterly destroyed my life. Made me completely disabled in body and mind. And I need help.
I got Covid on March 2022. By May 2022 I could see that I hadn’t really recovered fully. I’d get weird symptoms when I did any kind of exercise. In July 2022, disaster struck as my condition worsened dramatically and I found myself unable to work. I also couldn’t read books, watch TV, scroll my phone, drive or anything that required concentration.
I spent the next few months mostly outside lying down looking at the clouds, trying not to concentrate on anything. I tried many different experimental treatments but nothing worked that well. Resting a lot, in body and mind, helped me most. Giving my body the rest it needed to heal itself. By October 2022, I had improved a bit, I could read my phone for a few minutes and watch short YouTube videos, with breaks.
But in November, things took a turn for the worse. I lost goals/gains? I had made and steadily went downhill. In February 2023 I got so bad that I became sensitive to light. I had to rest in a completely dark room. If a bit of sunlight poked through the curtains, it would set off bodily pains, intense headache and nausea. I had to blindfold myself to go to the bathroom, feeling my way around like a blind man. Since then I’ve been in this dark room, lying in bed, doing absolutely nothing. I haven’t written a single line of code in a year. My doctor says that it is about blood. That covid damages the blood vessels and they no longer deliver nutrients properly to the muscles and brain. I've actually seen this with my own eyes, once when having my blood taken the nurse noticed it was very thick and sticky. She put a few drops into a tissue to show me, and the blood didn't flow like normal but jiggled like uncooked egg. Blood thinners are one of the things that helped a bit though not enough.
I’ve got important work to do. I shouldn’t be in this dark room for another day, let alone for the next several years or decades which is how long this disease lasts.
Near the start of Covid, when patients were filling up hospitals there was a series of rapid trials and in only a few weeks they found widely available medications that turned out to work well for acute covid. The same kind of thing should happen now for long covid.
A lot could be achieved just by speeding up the bureaucracy. For example, it often takes 8 months for a scientific paper to get past peer reviewing lists because the reviewer was reading it for 8 months but because that’s how long it took them to get round to it. I’ve got a background in science so I know how this works. It’s OK for an experiment on subatomic larticles, not when so many people are disabled and unwell. Right now there’s a trial for paxlovid, which will take two years (!) very curious given patients take it just got two weeks. I am seeing one of the rare specialists in post viral illnesses who now runs a long covid clinic. They havent been able to help me much since theres not enough science yet. It’s likely I’d be near the front of the queue when a medication that works is found.
We need these rapid trials. I need those trials, quickly.
The long covid space has plenty of ideas for stuff to try (for example this long covid researcher, this patient advocate). So if anyone reading this has any kind of influence influence then I urgently need your help.
Here is a photo of me in my dark room. I’m here over 23 hours per day.
took part in a Bitcoin Developers twitch livestream taking viewers through Teleport: https://twitter.com/ConorOkus/status/1540024421812826113
pushed this commit which adds one new method of creating funding transactions in case the first method fails https://github.com/bitcoin-teleport/teleport-transactions/commit/761e3a9bb86dd1380b01a1e2ffdf8c97d43dd2b9
carefully analyzing all the debug information i got from the crash bug from last week
found another thing i need to print out in the debug log, trying again to reproduce the crash
while that happens i made a new release of electrum personal server: https://github.com/chris-belcher/electrum-personal-server/releases/tag/eps-v0.2.4
the dogfooding from earlier gives me the impression that the create_spending_tx() function will sometimes fail, ultimately because its method of creating transactions doesn't always work, so i need to create another way that can be used if this first way fails
pushed this commit which i think fixes the earlier issue of maker's swapcoins not appearing in the wallet
did another coinswap on signet to confirm this, and it does work
noticed another bug where the taker code wont import the addresses and transactions of a coinswap you just did
fixed that here: https://github.com/bitcoin-teleport/teleport-transactions/commit/6176d12cc616779f56028b07ed024bf1fc0ee3d7
added a check when starting the maker, which i suspect trips up a lot of people when they try to run a maker with this early stage code: https://github.com/bitcoin-teleport/teleport-transactions/commit/dced1f998e264a4706f76991783f6cf6e8a51d78
found a crash bug while dogfooding doing coinswaps on signet, i was able to reproduce it too with a backtrace so im hopeful i can fix it easily
hopefully fixed another crash bug but the not one i was looking for https://github.com/bitcoin-teleport/teleport-transactions/commit/ced801cc62e4e1257e81e8ad7978caacbcc0dede
i managed to reproduce the crash bug from earlier with a backtrace and with debug symbols enabled, hopefully that will allow me to find the cause of it, it might take a while
continued to dogfood doing coinswaps on signet over tor
found other weird issues, including an alarming issue where coins will just disappear from the wallet, so im investigating that
created a new main subroutine "display-wallet-addresses" which ill need for debugging this coins disappearing issue: https://github.com/bitcoin-teleport/teleport-transactions/commit/9b9f6b83029e9143dc1ed7e2e5ea2bac78405348
and a bugfix https://github.com/bitcoin-teleport/teleport-transactions/commit/66b2f63886aac2b0bf3c04abd65c10b3b5356a1a
found the cause of the disappearing coins, it was because i was using two versions of the wallet file and i happened to look at the old version
found another issue while dogfooding, which is that the maker cant seem to spend coins in timelock contracts
after investigation looks like the walletcreatefundedpsbt RPC call doesnt want to select the timelocked coins, i dont think its worth fixing this since eventually we'll be using scriptless-scripts instead, its best to just spend the coins back to our wallet when their timelock matures, thats what the watchtower does automatically anyway
did another coinswap with myself on signet, noticed some other coins disappeared! now ill track down this bug
after searching a bit, seems like what i did was use the same wallet file for one of the makers and the taker, thats pretty undefined behaviour so
doing another coinswap with myself on signet, now with the correct wallet files haha still found some problems, again missing coins, will investigate
looks like the maker code doesnt correctly import addresses, and i never noticed when trying it on regtest because all the coinswap apps were connected to the same regtest instance
pushed commit which implements code that has makers advertising fidelity bonds https://github.com/bitcoin-teleport/teleport-transactions/commit/da30210ebda960686ababfc76c026fabee605da6
this commit doesnt contain an update to the tests, so they fail now, will fix
small edit pushed: https://github.com/bitcoin-teleport/teleport-transactions/commit/389944454b12d6778ff4aa815de4a69dfafb4985
fixed tests: https://github.com/bitcoin-teleport/teleport-transactions/commit/1665c9a55f6523c3c7acd5ef0a44e0cdbcf9cb5b
im examining the logs of the two signet makers iv been running, i got the idea to reduce spam and add more detail to the logs: https://github.com/bitcoin-teleport/teleport-transactions/commit/73c4f983f638677e945dec8cadcf29d7e69343fa there have been three coinswap attempts but all ended up going to the contract transaction stage, that's pretty weird, ill try doing a coinswap with them, i tried to do a coinswap and it looks like one of the makers kept refusing incoming connections for some reason, very weird
i can see why people maybe gave up halfway through, because waiting for signet blocks is pretty boring, coinjoin has much more instant gratification compared to coinswap
ill try again with just one hop instead of two, so its less likely to fail.. with one hop the maker that previously refused connections is now accepting connections, weird maybe the yield-generator's connection to the bitcoin node is intermittent and that causes the maker to think it cant reach the bitcoin node, making it shut down... also the connection between maker and watchtower failed too for some reason, which made the whole coinswap fail... very weird
wrote a suggestion on the minimint project after watching their talk on the open source stage of the miami bitcoin conference: fedimint/fedimint#96
finished implementing the generating of fidelity bond proofs, the signatures which are used to convince other entities that your fidelity bond is real and owned by you, also finished the verify function which checks the proof is valid
implemented an extra column in the "download-offers" subroutine which displays maker's fidelity bond values, will now test a little bit
it seems to work on signet too, both when querying a single maker and when querying all makers
finished implementing the ability to spend from timelocked fidelity bond addresses in teleport https://github.com/bitcoin-teleport/teleport-transactions/commit/46e29e5e880e3a3ecf4e65f7e1ef02d54bc4b4da
wrote a reply to some messages on the mailing list about my fidelity bonds BIP https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020479.html
wrote another reply https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020486.html
currently working on implementing fidelity bond proofs and the function which calculates the value of a fidelity bond
started to implement fidelity bonds into teleport
implemented the generating of the timelocked addresses, and sync'ing them
currently working on having fidelity bond coins be printed out in the "wallet-balance" main method
realized that this code is pretty urgent so wrote it and created a PR JoinMarket-Org/joinmarket-clientserver#1256
continuing to work on creating a bip for fidelity bond wallets, currently working on the details of the certificate signature to make sure that its compatible with signmessage/verifymessage that other wallets already implement
uploaded the code which produces test vectors for the fidelity bonds bip: https://github.com/chris-belcher/timelocked-addresses-fidelity-bond-bip-testvectors
sent the bip proposal to the mailing list: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020389.html
trying to ease myself back into doing work
continued to write the draft for the new BIP document about fidelity bond wallets, which is already implemented in joinmarket and will be an important part of teleport / coinswap
managed to write these comments on the joinmarket github about fidelity bonds: JoinMarket-Org/joinmarket-clientserver#1247 (comment)
this week i only worked about an hour a day :( this sucks. can't wait until tuesday for when i have my meeting with the physiotherapist, hopefully he can help
wasnt able to do any work all week due to the previously-written about covid wrist and hand pain issue
did some napkin math regarding my newfound inspiration for private methods of lightweight wallet sync, but unfortunately it didnt work, you can get good privacy but it uses far too much bandwidth
back to trying to figure out the standard for fidelity bonds signatures
later, i managed to figure everything out about fidelity bond signatures, i have rust code which generates them and signs certificates, now ill write a bip document about them
i noticed that the pull request on bitcoin core which implements my BIP-326 got one tACK. So I reviewed the pull request myself as well, to hopefully get the PR merged. bitcoin/bitcoin#24128 (comment)
looks like covid made my wrist/hand injury RSI from a few months ago flare-up again :( i got a lot of pain in the same places in the wrists and hands when i type on a keyboard or use the mouse. I emailed my doctor who said yes its fairly common, he says that in most cases it lasts 1-2 months but may be shorter.
had covid, didnt work all week
got some inspiration for private methods of lightweight wallet sync while in self-isolation
continued to work on implementing a part of joinmarket's fidelity bond protocol in rust, so that it can later be used in teleport and so that the same fidelity bond can be used in both teleport and joinmarket, and also so that the protocol is standardized so that other wallets can support timelocked addresses too
the PR i reviewed was merged into bitcoin core: bitcoin/bitcoin#24225 it is a step towards adding an implementation of my bip326 into core
played with descriptor wallets in core a little bit, intending to make teleport use them, as they are clearly the future. however it looks like rust-bitcoin doesnt support the importdescriptors RPC yet: rust-bitcoin/rust-bitcoincore-rpc#199 so ill postpone moving to them
im giving up the brainstorming into private methods of lightweight wallet sync for now, C-PIR seems too costly for the server and prefix filtering of addresses doesnt provide any privacy for reasonable bandwidth usages. it's not even worth writing up anywhere
now working on adding fidelity bonds to teleport
i thought of another thing to try for brainstorming private methods of lightweight wallet sync, involving downloading false positives and using the properties of the binomial coefficent, ill investigate it after i finish some of this timelocked address and fidelity bonds code
working on reproducing the exact same fidelity bond signing stuff as in joinmarket, but in rust, to be used in teleport
fixed a thing on electrum personal server, which was quick and easy, but Bitcoin Core is deprecating an RPC call that EPS uses, so that had to be tweaked
my anti-fee-sniping and extra privacy BIP was merged(!): bitcoin/bips#1269 (comment)
reviewed a PR for bitcoin core which could ultimately lead to an implementation of bip326 being added: bitcoin/bitcoin#24225
did a bit of reading papers about cryptography to see if some idea would work, i think it will not. the idea is from this thread: https://bitcointalk.org/index.php?topic=5365132.20
made some necessary bug fixes and then made a release of electrum personal server: https://github.com/chris-belcher/electrum-personal-server/releases/tag/eps-v0.2.3
thinking about and working on another idea related to the above cryptography, you could summarize the aims of the idea as "an electrum server that cant spy on you"
created an alpha release and posted it on all the places https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/020026.html
spent time answering questions from various people
working on doing some calculations for fidelity bonds, it is research ill need before adding fidelity bonds to teleport
tried to write and make a short video presentation about the upcoming alpha release, but got stuck with writer's block and decided it wasnt worth spending 2 weeks doing it
did some test coinswaps on signet and found some other things that could really trip people up when testing, so decided to fix them: https://github.com/bitcoin-teleport/teleport-transactions/commit/390341b056ed91d4cbcf24c1b992b7f1693508c4 https://github.com/bitcoin-teleport/teleport-transactions/commit/4b8581e7f8801b9847edfdb8438db6c926ba5435
other small edits: https://github.com/bitcoin-teleport/teleport-transactions/commit/43f035527c93619f51afefd0b8c3d266e8c580e9 https://github.com/bitcoin-teleport/teleport-transactions/commit/f9bff3f7007fd4326680baaf0628bdeb842bf74f
decided to do the release on monday when more people are on the internet
until then, working on some analysis of joinmarket's fidelity bond ecosystem, that understanding will be needed because teleport also requires fidelity bonds
created a main subroutine "download-offers" which displays all the offers of all the makers out there https://github.com/bitcoin-teleport/teleport-transactions/commit/4b1c89e3954c37cfc08a96410735a93076e6f0f8
other small edits, which add small things or rename things: https://github.com/bitcoin-teleport/teleport-transactions/commit/d83dcc8db6d960c2af0281ff255b27a0235799bc https://github.com/bitcoin-teleport/teleport-transactions/commit/876e986c943812729ebc4d438d9eafef88e39a4f https://github.com/bitcoin-teleport/teleport-transactions/commit/c34f75c98cd8da7a3b0e9935a038ac3bd3068771
now working on updating the rust-bitcoin dependency to the latest version
added a fee rate parameter that the user can configure https://github.com/bitcoin-teleport/teleport-transactions/commit/85610a0cbe5de706877cfeed930c50facee3aed7
these are all the features i want in the first alpha release, now ill write some more docs if needed, and then write an email to the mailing list about this release and post it all around like on reddit/twitter/mastodon
i pretended i was new to the project and set up a maker from scratch on sig, i found a bug which i need to work through.
i think i found the cause of the bug, which was caused by upgrading to bitcoincore-rpc version 0.14, posted an issue to the github rust-bitcoin/rust-bitcoincore-rpc#211 playing around with it also helped me find a workaround which i think ill use until it gets fixed upstream
coded one or two small fixes, also edited and expanded the README in preparation for the upcoming alpha release
wrote the email which will announce the alpha release, not sent yet. I'm thinking of creating a video presentation which might be a bit more accessible, I've seen other announcement posts which have an accompanying video and it seemed like a good idea.
separated out a big chunk of code in taker_protocol.rs into its own function
pushed this commit https://github.com/bitcoin-teleport/teleport-transactions/commit/b430eb25b982e9246dfed0e65582104511f9151d with it now all the taker connections are attempts repeatedly before giving up.
This robustness is important for decentralization, without it only makers on very stable servers and connections which never go down would earn the max profit. We want makers to be runnable on raspberry pis in people's bedrooms, that would be out without more robustness and re-trying the connections.
a few other small commits which involve renaming things mostly: https://github.com/bitcoin-teleport/teleport-transactions/commit/3a590944cbc8a153bbce8003b22ad1e2b4dc5b3e https://github.com/bitcoin-teleport/teleport-transactions/commit/731d73871834a7bfcaf76a62a4646e04eeeb8b8f
currently working on adding socks5 proxy support, which is needed to use tor. because of that i notice the version of tokio im using is many many versions out of date and i need to update, or else this tokio-socks package i found wont work
done, that was easier than i thought https://github.com/bitcoin-teleport/teleport-transactions/commit/73145d8475766a7b9db6b869773d934442e65447
added ability for taker to connect to .onion makers https://github.com/bitcoin-teleport/teleport-transactions/commit/0f75c1dc12addf5057b204178f5c248a18b9dc7a
add timeouts to the taker message sending routines https://github.com/bitcoin-teleport/teleport-transactions/commit/af3e8a39a7ba0dcf92b8b62c18ec12875c7fb01a
implemented retrying and timeouts to the offerbook synchronization code https://github.com/bitcoin-teleport/teleport-transactions/commit/4405ed37e5a4f32e3c372a13593f73ce29fe3de9
now working on creating directory servers
created a simple directory server with the python http.server module, also created code to have teleport takers sync from those directory servers. pushed the code: https://github.com/bitcoin-teleport/teleport-transactions/commit/173a1c05ed7dbbaaeba8f61a5353f44056169e8b
did small code edits: https://github.com/bitcoin-teleport/teleport-transactions/commit/5ac963b0d091df2c021bcf5b7b28d8e878f0314d https://github.com/bitcoin-teleport/teleport-transactions/commit/a5ec8dedd8f7a75d4db581bd612682470c372e8d https://github.com/bitcoin-teleport/teleport-transactions/commit/55dac4a50bc48ca773e1d0feaa0265155a86c7ba
now adding support for coinswap fees from taker to maker, and parameters like minimum confirmations and minimum locktime
also reading old mailing list emails to help figure out exactly how to implement coinswap fees
implementing all the fees and doing the accounting, for makers now i am able to print out a "potentially earned" log message
done, pushed the commit https://github.com/bitcoin-teleport/teleport-transactions/commit/b6a5b225195a3a3ef3da67f1f3a349a76823fbdc
the next big task will be adding support for connecting to makers at any address not just localhost, and also connecting over tor
did some small code edit tasks: https://github.com/bitcoin-teleport/teleport-transactions/commit/af1af0efb16872e01d8cc63f31d1386c27cbc847 https://github.com/bitcoin-teleport/teleport-transactions/commit/8a0886797a4a426adcc4c135090dafcbb42c3b4b https://github.com/bitcoin-teleport/teleport-transactions/commit/e36e1a38c36adf18d15d15a360874d6af8f1a798 https://github.com/bitcoin-teleport/teleport-transactions/commit/e1e896e62be8ea52517163f2c9bf86e84b2295cc https://github.com/bitcoin-teleport/teleport-transactions/commit/87f6e3faeeca423b9aa98c0f761247748a459406 https://github.com/bitcoin-teleport/teleport-transactions/commit/1c6542121a45bc58704092f7f8b0a1046515ca51 https://github.com/bitcoin-teleport/teleport-transactions/commit/956eb81d93c5aa87bf3a9bae1e1c12751ffe0aae https://github.com/bitcoin-teleport/teleport-transactions/commit/e033828f422401f16b6eeb951b9bd3b7773bd308 https://github.com/bitcoin-teleport/teleport-transactions/commit/0f7a7c4e57195fd4f9982ea55dd100f210de0f12
spent some time making example scripts and asking for advice on the ##rust irc channel, figuring out how exactly ill code this next thing where taker attempts to connect many times before giving up
partily finished coding the feature for repeatedly attempting to connect to makers, not giving up after the first failure but trying again, though not in every single place in the code yet
pushed the code i have so far https://github.com/bitcoin-teleport/teleport-transactions/commit/3bcc827f72f38ccba596a2e902bff28662feaa99 still not done yet is the connection which sends the ProofOfFunding message, that part is more complicated and ill do it in another commit
after a fair bit of testing and playing around, i got the watchtower code to work i believe
however i realize for security its necessary for the watchtower to broadcast a spend of the contract which uses the timelock branch as soon as that timeout matures, so im coding that up now
coded that up and testing it also testing in the special case where the contract transactions are all confirmed in different blocks
found a bug that means i have to slightly recode a significant part of the watchtower code. the bug happens when theres are multiple timelocked transactions watched by the watchtower, and they mature at different times. done that now, it was fiddly but im finished at least for this bug
that marks the end of my work on watchtower for now, pushed all the code https://github.com/bitcoin-teleport/teleport-transactions/commit/ba2731a76d81583a78ffe6b2487c6a8756edb055
now moving ahead to the next task before the first release. reorganized my notes slightly to make a brief plan for the next task
made a few small edits here: https://github.com/bitcoin-teleport/teleport-transactions/commit/4275ca3ba1f47f63a8b8289d1a39b3f0be45c749 https://github.com/bitcoin-teleport/teleport-transactions/commit/42d977ed40211a19b8f11fc1778db4226cbdd189 https://github.com/bitcoin-teleport/teleport-transactions/commit/281eb2e4f8c02095c78481402b9a3c4605f0e73b
continuing to work on implementing the feature in watchtower where it watches for a hash preimage being used to spend a certain coin, and then using the knowledge of that hash preimage to spend its own coins
for that i need to create a way to spend a coin using a hash preimage, so that i can test the watchtower
pushed this commit which adds the displaying of hashlocked contract coins https://github.com/bitcoin-teleport/teleport-transactions/commit/d15536b49d71ce327b3ce3efd3763b2d234eb568
pushed this commit which implements spending of hashlocked contract coins https://github.com/bitcoin-teleport/teleport-transactions/commit/6475b24c87fa4f459a1a72a8f3d4fae173a01944
now working on adding to watchtower features for detecting when a contract UTXO is spent via the hashlock branch
ive written code which reads the hash preimage from a transaction
finished writing more-or-less all code for watchtower that will be needed, testing it now by doing hashlock spends on regtest
working on creating more integration tests, specifically one for the wallet display and another which does a full coinswap but which fails due to a maker misbehaving, the test will check that the taker correctly responds
added two small edits while reading the code figuring out whats the best to do https://github.com/bitcoin-teleport/teleport-transactions/commit/5ab083703ef6831410c3ffdc778913c0cac30b63 https://github.com/bitcoin-teleport/teleport-transactions/commit/70e3d1101a89f011025af2b449227993e08d408f
actually on second thoughts i can create tests like these later, right now its more important to go ahead with new features eventually getting to an alpha release
working on a new main subroutine called direct-send which just sends a normal transaction out
from the wallet, i described it previously here: bitcoin-teleport/teleport-transactions#42 it is needed right now because it can be used to test a thief attempt where one party spends
a contract transaction output using a hashvalue, we have to test that the watchtower correctly reads out
that hashvalue and uses it to spend its own contract transaction outputs
to do that you need to be able to choose to spend certain coins, hence making this new subroutine
did that in these commits https://github.com/bitcoin-teleport/teleport-transactions/commit/9b256b1d6ca9dac3af3fb68b73c56cd2b2d79f92 https://github.com/bitcoin-teleport/teleport-transactions/commit/50560943f23374ef173a5d1f9927a08f8df81e96
spent a day or two coding some analysis scripts for the fidelity bonds on joinmarket i've been trying to calculate the probability of each maker actually being chosen to create a coinjoin with its an interesting problem and very relevant to coinswap because the project will use fidelity bonds too however the code i wrote runs in O(N!) time and so very quickly becomes impractical to run in any reasonable time, so ill have to think about ways to get that time down
giving up for now, and going back to coding on teleport/coinswap
i moved most things in main.rs to lib.rs, as this is the standard way of structuring a project and is required for writing more integration tests
opened a pull request in the BIP repository to add my BIP standard for using nsequence numbers for anti-fee-sniping to eventually improve the privacy of coinswap, lightning network, DLCs and other off-chain protocols: bitcoin/bips#1269
modified the standard coinswap integration test to work with the move to lib.rs, this will allow later adding of more integration tests which test various kinds of errors https://github.com/bitcoin-teleport/teleport-transactions/commit/f48a2f487bfb5bfd4bc0fd24fae2f8bc1bec0887
finished and tested the code for having the taker try again with another maker if it fails to obtain the required signatures
created a new mode for makers where they will abort the connection if the taker asks for senders contract transaction signatures this new mode is used for testing the above new feature
merged the git branch i was working on these past few days and pushed it to github
there are other commits in that branch but these two are probably the most important https://github.com/bitcoin-teleport/teleport-transactions/commit/1f63310eb84b36148b0aae11489d681e9bab19a5 https://github.com/bitcoin-teleport/teleport-transactions/commit/d5e38f3b4be4c34af0c7d0b4c3c61a0dae74a556
noticed some odd log::info! messages that could be improved in maker, did that https://github.com/bitcoin-teleport/teleport-transactions/commit/dfcdfc901dc3aa0ee24dbd678c4cd0aa1b053aeb now when running maker the info messages will be interesting and readable
made slight edits to the wallet-balance output https://github.com/bitcoin-teleport/teleport-transactions/commit/a6300300829ccd1afce9d6c85b23e0e9f58ef032
fixed a problem where a socket to the maker would remain open and idle for potentially days https://github.com/bitcoin-teleport/teleport-transactions/commit/8d93f7ff4d2332acd51bd4819185db36fd3e69fb
removed some unecessary code i noticed here https://github.com/bitcoin-teleport/teleport-transactions/commit/c938596bfa9151631a83452fda4e359909aeb780
reading and studying how tests work, as i intend to write some more tests, i didnt write the tests we have now so i need to understand them in a lot of detail first
worked on connecting up the watchtower code with the maker code to have the maker register its coins with watchtowers during a coinswap the security of coinswap depends on this
pushed a commit: https://github.com/bitcoin-teleport/teleport-transactions/commit/8c5a4be497e603152f45037e6f42b5fb476a25e7
now working on adding code to the taker which watches the network like a watchtower but in the same application, allowing the taker to know if one of the makers has deviated from the protocol by broadcasting one or more contract transactions done, pushed commit https://github.com/bitcoin-teleport/teleport-transactions/commit/7c3fc03f8d53826d9964d339480e105f7f790c24
wrote an issue delegating a feature we need bitcoin-teleport/teleport-transactions#42
finally finished the first version of the watchtower code which i pushed here https://github.com/bitcoin-teleport/teleport-transactions/commit/2c22fb9d43c2348f715e99e258c18509b53e57ce
next step is to connect it up to the maker code, and to create tests which run the whole taker-maker-watchtower flow
still working a little bit less intensely due to overuse injury/RSI
continued to work on the watchtower code made the part which extracts TXIDs from blocks and compares to the txids the watchtower has to look for
my hand doctor advised me to work 1.5-2hr per day for the next week, which will slowly increase
finished writing the first simple version of watchtower, which is meant to have the feature that if one contract transaction is broadcasted then all the other contracts of that coinswap will also get broadcasted this is a necessary part of coinswap's security
now working on code for a watchtower client, which makers will use to tell watchtowers about their coinswaps, and also the code ill use to test the watchtower
The large gap in my updating of this work diary is because my RSI injury got worse and I stopped working.
Over the last few weeks I found myself more and more avoiding using my right hand because of the pain in the fingers. I went to visit a specialist doctor, he did an ultrasound on my hands and did a physical examination. He sent me to do a electromyography (EMG) test to check for carpel tunnel syndrome, the test came back negative so I most likely dont have that syndrome. The doctor said he thinks I have an overuse injury, also the term RSI doesnt mean anything, it is not a medical term. I have an appointment for a hand physical therapist next week.
I've been resting my hand, not using the computer at all, for about 2 weeks. I slowly got back into working after resting. I've been doing little bits of working/typing for an hour at a time, and then rest. I'll be aware of any pain or sensation in the fingers and stop using the computer immediately if I feel anything.
I was able to carry on developing the watchtower code a little. pushed this commit: https://github.com/bitcoin-teleport/teleport-transactions/commit/cc401f0b9dab3e1eb3f95740ee505bdd2a34d6b3
reviewed quickly an urgent bugfix for joinmarket
released here https://github.com/JoinMarket-Org/joinmarket-clientserver/releases/tag/v0.9.3
more discussion here bitcoin-teleport/teleport-transactions#37 (comment)
iv had pretty bad RSI so ive been typing with one hand lately, ive ordered a better keyboard which is on the way
pushed two commits to github: https://github.com/bitcoin-teleport/teleport-transactions/commit/e07b9ce906d1073f18bb0ec460bd79035039b543 https://github.com/bitcoin-teleport/teleport-transactions/commit/b25f5d332106531cddd349d5c3b57c7b6f332480
merged this PR bitcoin-teleport/teleport-transactions#38
currently working on reviewing PR 32 which is needed to fix how logging works finished testing it, it seems great so i merged it bitcoin-teleport/teleport-transactions#32
continued coding where i left off committed code which broadcasts contract transactions now working on code to display live contract transactions to the user
a sparrow wallet developer implemented my BIP about using relative locktimes for taproot spends sparrowwallet/sparrow#161 (comment)
they also suggested an edit to the spec, which i merged
on vacation
on vacation
its one month since fidelity bonds in joinmarket was released made a quick summary and explaination on the social medias
https://x0f.org/@belcher/106850991287519185 https://twitter.com/chris_belcher_/status/1432696845017436166 https://www.reddit.com/r/Bitcoin/comments/pf6kb2/developments_in_joinmarket_and_privacy_one_month/
reviewed and merged bitcoin-teleport/teleport-transactions#29
some small cleanup changes and bugfixes https://github.com/bitcoin-teleport/teleport-transactions/commit/570fd8aeacc0cd0ab49af335150297ab612c45ab https://github.com/bitcoin-teleport/teleport-transactions/commit/fded48e9b58f8957d7c0a1f23344656498d72c97 https://github.com/bitcoin-teleport/teleport-transactions/commit/5ac0008b8c9847fa073177a87f6e1096260f8cea
added short doc https://github.com/bitcoin-teleport/teleport-transactions/commit/b29882b64331c194e9bff097a332a643191cbe52
working on a feature allowing users to recover from incomplete coinswaps it would broadcast the contract transactions and have the teleport wallet handle them (for example, by displaying them separately depending on whether the timeout has passed)
still observing how the joinmarket fidelity bond ecosystem develops
continued to review some PRs on the teleport github bitcoin-teleport/teleport-transactions#29
merged bitcoin-teleport/teleport-transactions#33
more talking to people about joinmarket fidelity bonds
updated docs JoinMarket-Org/joinmarket-clientserver#982
joinmarket with fidelity bonds is released https://github.com/JoinMarket-Org/joinmarket-clientserver/releases/tag/v0.9.0
already within 2 days we have "9 fidelity bonds found with 32.47176562 BTC total locked up" and someone locked up 12.61058953 BTC until 2024-08-01 pretty facinating to see
a bunch of bugs have been found in joinmarket 0.9.0, im helping fix and test
some stuff i fixed: JoinMarket-Org/joinmarket-clientserver#961 JoinMarket-Org/joinmarket-clientserver#964 JoinMarket-Org/joinmarket-clientserver#966
answered more questions about fidelity bonds in joinmarket many people had questions now that it is released
working teleport/coinswap
tried to figure out the best way to import contract_redeemscript addresses into core's wallet i cant find a way for the redeemscript to appear in the output of listunspent
worked on adding wallet routines which allow users to broadcast their contract transactions and wait for the timeout to get their bitcoins back, to be used for example by the taker if a maker ends up stalling
tested and merged this pr bitcoin-teleport/teleport-transactions#23
merged the announce-fidelity-bonds branch into joinmarket(!)
wrote pseudocode for the bip proposal for nsequence value setting https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019275.html
asked sparrow wallet to consider adding it sparrowwallet/sparrow#161 because i saw on twitter that they've already implement taproot on-chain wallets
checked and merged two PRs on the teleport github bitcoin-teleport/teleport-transactions#25 bitcoin-teleport/teleport-transactions#22
wrote a big comment along with pseoducode bitcoin-teleport/teleport-transactions#23 (comment)
pushed three commits to teleport https://github.com/bitcoin-teleport/teleport-transactions/commit/ef4565c436f497fa65111a532bc3260a27e0e1b6 https://github.com/bitcoin-teleport/teleport-transactions/commit/5741b6d2baa51b0d24e71f1361b53bd3c9f9b6de https://github.com/bitcoin-teleport/teleport-transactions/commit/aa6093e14b7359460b0ef90a47b3c7ec9d1a0d18 getting ready to add security, i.e. if the other side of a coinswap does something bad (e.g. broadcasts a contract transaction) then we are able to respond to it (by, for example, claiming the money with a hash preimage)
also this: https://github.com/bitcoin-teleport/teleport-transactions/commit/179038763b1d6a66cb9d39e0a623624e7ac22e1a which speeds up the integration tests
coded an edit to fidelity bond wallets in joinmarket that we decided was needed https://github.com/JoinMarket-Org/joinmarket-clientserver/commit/5178d0548182f2d8ef575edd532ae5650140d126
finishing squish the commits to the joinmarket fidelity bonds PR this is the home stretch now now just doing some quick tests manually
in an IRC discussion between myself and undeath we came up with a thing thats really worth doing before merging the PR which is to change slightly how generating timelocked addresses works see JoinMarket-Org/joinmarket-clientserver#872 (comment)
working on teleport transactions (coinswap) for a bit continuing to write code so that the wallet tool outputs coinswaps-in-progress which will be necessary for adding watchtowers and reacting to stalls and misbehaviour from the other side
discussion about my proposed bip https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019147.html
two commits https://github.com/bitcoin-teleport/teleport-transactions/commit/2e78e153c45d25240b1ca5dd2ad58ae34689a9d1 https://github.com/bitcoin-teleport/teleport-transactions/commit/9ddd6db88d890146d301385dd4cb9be10ea510ef in preparation for adding the ability to use the contract transactions which is needed to actually enforce the security of coinswap, you need the backout transactions
the "announce fidelity bonds" PR in joinmarket had some activity again, making the requested changes and then squishing all the commits ready for the final review
squishing all the commits and made sure the tests all pass, it took ages
finished adding error handling to maker_protocol.rs https://github.com/bitcoin-teleport/teleport-transactions/commit/c0e374f81f0d432f6acecf0e5e1733d4ada6f7ae
suggested three issues to mojo, he was asking for ideas of how to help bitcoin-teleport/teleport-transactions#19 bitcoin-teleport/teleport-transactions#20 bitcoin-teleport/teleport-transactions#21
read the code, thought a lot, and wrote notes about using the contract txes which can be used to recover money after a locktime or with a hash preimage
working on adding proper error handling to teleport right now unwrap() is used everywhere, so if anything unexpected at all happens the app just crashes
have added error handling to all of wallet_sync.rs added error handling to contract.rs
uploaded work so far to github https://github.com/bitcoin-teleport/teleport-transactions/commit/17eba9bcbb0b7a6b462a57c8389d91141537f061
figuring out how to pass errors around the maker code so if an error arrives from the taker-handling routines in the maker which requires the whole maker to shut down, how to send this shutdown message to the server socket loop requires me to read a bit more about tokio
figured it out with a bit of help from the #rust channel on libera
used that to slightly change the server loop and integration test to use select! https://github.com/bitcoin-teleport/teleport-transactions/commit/3eb9ae95b2df5e68a974b19d8cf5b938a64c6c88
currently trying to add error handling to maker_protocol.rs but some issues around the tokio concurrency compile errors are causing headaches again created a cut-down version of my code to be able to show people in #rust who helped me figure it out
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 spesmilo/electrum#7330 (comment) in either case, its a success from my point of view
created this PR on the electrum github to improve privacy in a very specific situation: spesmilo/electrum#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 JoinMarket-Org/joinmarket-clientserver#895
fixed some of waxwing's review comments some edits of the docs, and one crash bug in wallet-tool's showutxos method
fixed all the other review comments and uploaded the commits JoinMarket-Org/joinmarket-clientserver#872 (comment)
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
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)
discussed with waxwing and undeath about the fidelity bonds code, they had many questions
wrote docs on the fidelity bond proof protocol JoinMarket-Org/JoinMarket-Docs#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
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 JoinMarket-Org/joinmarket-clientserver#872
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
coded the fix to the year 2038 problem with fidelity bonds and merged it JoinMarket-Org/joinmarket-clientserver#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 bitcoin-teleport/teleport-transactions#14 bitcoin-teleport/teleport-transactions#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
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 JoinMarket-Org/joinmarket-clientserver#798 i figured out a solution
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
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 spesmilo/electrum#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
reviewed this PR JoinMarket-Org/joinmarket-clientserver#837 opened this one JoinMarket-Org/joinmarket-clientserver#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
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
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
while talking to an EPS user in the wild i came up with another possible solution to rescanning while in pruned mode: chris-belcher/electrum-personal-server#85 (comment) 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
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 chris-belcher/electrum-personal-server#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: chris-belcher/electrum-personal-server#96 (comment)
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/
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
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
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
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
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 bitcoin-teleport/teleport-transactions#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
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 bitcoin-teleport/teleport-transactions#8 bitcoin-teleport/teleport-transactions#9
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
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
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:
- makers in coinswap routes dont talk directly to each other
- payments in routed coinswap cant be cancelled without the detection (the taker will be see the mined contract transactions)
- the taker releases the hash preimage to every maker directly and simultaneously
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
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
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 rust-lang/rust#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
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
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
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
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
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
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 rust-bitcoin/rust-bitcoincore-rpc#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
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
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 rust-bitcoin/rust-wallet#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
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
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
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
still coding what will eventually be the internal wallet ran into this issue rust-bitcoin/rust-bitcoincore-rpc#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
finished coding wallet generation and recovery, now coding wallet sync
had medical issues and hospital visits this week so did a bit less work
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
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
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
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
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
posted my review in the taproot PR in secp256k1 bitcoin-core/secp256k1#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
used rust-bitcoin and rust-wallet to sign a transaction
worked much less this week due to medical issues
reviewing code from libsecp256k1 bitcoin-core/secp256k1#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
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 rust-bitcoin/rust-bitcoincore-rpc#117
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
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
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
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
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 JoinMarket-Org/joinmarket-clientserver#536
set up a date for a podcast recording on the whatbitcoindid podcast
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
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
Nice work, Chris, thanks for keeping this. It is inspiring to read.