- Introduction
- Before SOB and Proposal Submission
- About the Project
- First Meeting with Mentor
- Technical Knowledge and Improvements
- Future Work
- Account of Work
I am thrilled to provide an enthusiastic update on my progress during my Summer of Bitcoin Internship. [Upto Mid-Term Evalutiaon] The journey so far has been filled with exciting learning opportunities, challenging tasks, and valuable experiences. I am grateful for the chance to be part of such an innovative and dynamic program. Here's a detailed account of my achievements and growth during this period.
I was trying at summer of bitcoin last year (2022) but could not get through the screening round. Since then, I was aware about this opportunity and was determined. After getting some personal time from my part time Software developement internship, I have decided to contribute to some of the bitcoin projects.
Luckily, I was a fan of RustLang and so I have started exploring rust based bitcoin projects. I have come across few but most attractive project was rust-bitcoin. I have started fixing some TODOs and open issues. It was around January the program was again announce and I was slowly getting glimses of what the goal of rust-bitcoin is.
Long story short, I have send some begginner PRs and then also helped in setting up an mdBook for the project. When the regsitrations opened, I have applied and was expected to complete the coursework. I completed and it was the best part before the program started. I got to learn so many different concepts and philosophies from it.
During the proposal submission, I was deeply focussed on two projects. Key based signing on rust-miniscript and Performance Benchmarkings on VLS. I was the first person to solve the challenge in VLS reported into their matrix room. But down the line, I haven't got much acquinted with the lightnening security and its philosophy. So, I was not sure if I understand certain parts in codebase or the project descriptions.
Thus, I have decided to send only one proposal to rust-miniscript and I was selected :)
Each bitcoin transaction is verified by a network of nodes and it requires a transaction fee to process the transaction on blockchain.
The project aims to improve the transaction fee estimation which is currently implemented as worst-case analysis in rust-miniscript which results in overpayment for unused spend paths.
In case of multi-party transactions, it is important to agree on a transaction fee rate to prevent DOS attacks. To address this problem, rust-miniscript has implemented the absolute worst-case analysis for the satisfaction of weights and employs it to calculate the fees. But, This has issues related to overpayment for spend paths that are not well executed which increases the transaction cost.
One way to approach this would be to check for Key availability and Preimage availability . By knowing about these parameters, we can adjust the transaction fees to be less since we now already know that the key won’t be executed in a spend path. This would help in making better economic decisions regarding fee rate.
A huge shoutout to my mentor, Who is well supportive and made the journey more valuable by providing feedbacks, explaining bitcoin concepts, and helping to organize the project task in a way that we always add up value to people working with us. In the very first meeting, He explained the logistics of the program and what I should care more about and what less.
In my project, There was already some pre-work done in a direction. But, We wanted it to be sorted as per the requirement of the crate. And thus, We came to conclusion that we will not entirely open a new PR and do what we require but instead we will help the developers from BDK who initially worked on the PR and raise follow up PRs wherever required in order to make a more collaborative work environment. My very first task was to review the pre-work done and come up with my comments on the tasks and what improvements I can think of or what seems to be missing.
The pull request was a huge change and it took about a week to review their work. I initially had some conceptual doubts and was not willing to disturn the streamline conversation by asking some basic questions so I have replicated the pull request on my fork and asked all conceptual doubts in further meetings and async sometimes in order to get things done.
Pull Request by BDK Developers : rust-bitcoin/rust-miniscript#481
Pull Request on my fork for discussion : Harshil-Jani/rust-miniscript#1
Over a period of time, with multiple review iterations and understanding about things and their uses, I have deepend my knowledge on various important concepts such as descriptors, spend policies,Schnorr and ECDSA Signatures,Segwit 0,Taproot descriptors,PSBT and most importantly the steps involved in
- Creating
- Satisfying
- Signing
- Finalizing
- Broadcasting a PSBT.
I have learned about how the satifaction works in worst case and how it will be working in the greedy algorithm which we are designing. This was better understood to me after I have written an example which will allow people coming from other projects and using rust-miniscript as library to understand the steps involved in using our new algorithm.
It is a top level overview of my work. Deep down, I have to learn good amount of stuff like how does the descriptors and wrappers works inside of miniscript and how a policy gets satisfied. I have even played with timelocks based test cases and tried multiple variations on it. Learned deeply about thresh policy and with all these, I have manually learnt to calculate the satisfation weight. This got me exposed with a fact that Schnorr signatures are maximum of 64 bytes and ECDSA sigs are 72 bytes.
While learning all of it, I got sense of work about how tests works in a bitcoin and rust ecosystem and also understood about the importance of the example/ directory for any proejct. This would allow people from different projects come and learn how to use a certain feature without knowing in depth implementation.
I was constantly reading about miniscript on the https://bitcoin.sipa.be/miniscript/ official site and improving my understanding about them.
To stick with my project, I was asked to checkout of the Pull Request raised by BDK developers and write a new example where I need to plan entire PSBT finalizing procedure and consider all edge cases. I have worked on writing an example and got it successfully working. But there was already a known problem for Pkh. I and my mentor degubbed for this and found that when we are trying to satisfy the PSBT Transaction, We are changing the Miniscript descriptors pkh to expr_raw_pkh and thus we lost access the pkh when we try to finalize. The solution to this was that from the PSBT we can create a Map of all the keys in pkh and their hash160. And once we satisfy the miniscript descriptor then we can simply substitute pkh back in place of expr_raw_pkh. So, We worked on a logic to get it done and here is the PR.
rust-bitcoin/rust-miniscript#557
Once we were unblocked on that front I was expected to learn in depth about the Taproot Descriptor by reading BIP0386 and once I have developed concrete understanding about taproot descriptor, I have worked on extending my work for writing an example with the taproot based descriptor as well. Along the way I have had an problem and found a bug where the public key was expected and we ended up with XOnly key and I have pointed this in the original PR review and then implemented it in my example PR. I have had a cleanup of code on the tutorials and raised a PR with taproot and wsh both descriptor examples explained. rust-bitcoin/rust-miniscript#559
We have reached the mid evalutions. For the next half of the program we are trying to write a piece of algorithm so that we can protect the transaction process from a DOS Attack. To do this, We will get all the possible plans from a given descriptor and check total number of plans. If it exceeds a certain threshold, we will simply reject the descriptor. This is important because in case if the algorithm tries to plan the satisfaction for all possibilities it would end up increasing the congestion over the network and we just don't want this to happen. We will get count of all possible plans and if it exceeds a threshold We may not allow the transaction to occur. Also, Currently we just have unit tests and we are looking forward to write integration tests once the PR gets into the codebase. Another thing on our TODO list is about working on BIP 326 which is about improving the privacy and fungibility of wallets.
includes only PRs raised during internship period and not the ones before