Bitcoin Developer Grant
Gleb Naumenko has been working on Bitcoin Core technologies since 2017. His primary focus is security, privacy and scalability of the peer-to-peer layer. He is also interested in the Lightning Network and other protocols on top of Bitcoin.
Gleb usually makes his contributions via:
- Direct changes and code review for Bitcoin Core and rust-lightning,
- Broader Bitcoin-related protocol research (usually via modelling and simulations),
- Collaborations with researchers from academic institutions, and
- Talks for the Bitcoin community as well as broader academic communities.
Gleb is most known for Erlay, the bandwidth-efficient transaction relay protocol, which allows to significantly reduce the requirements to run a full node, and enable the security increase “for free”.
He also made a number of other improvements to the Bitcoin Core peer-to-peer protocols, mainly focused on making the network more robust to attacks and spying. Lately, his attention was partially focused on the protocols on top of Bitcoin. In June 2020 Gleb published a paper which explored time-dilation attacks on the Lightning network.
In future he is planning to keep working on the security and privacy of the core software, protocol analysis, advancing Bitcoin research and bringing attention to the open problems we have.
Gleb has been awarded a Bitcoin developer grant by HDR Global Trading Limited and it is based on the open source template grant contract.
Reports by Gleb Naumenko:
In this article, we attempt to design smart contracts encouraging miners to withhold a certain transaction, to better understand how practical such smart contracts are. Better understanding these contracts is relevant in the broad Bitcoin context, and for better understanding the security of time-sensitive Bitcoin protocols. We start from trivial mempool spamming (not a smart contract), and go up to covenant-enabled multi-stage reward transactions.
In February 2022, Gleb Naumenko (Bitmex grant recipient) and Antoine Riard posted a CoinPool whitepaper. The earlier version of the project received less technical coverage in Bitcoin Magazine. This post attempts to build up some intuition on the CoinPool proposal by answering questions based on the feedback. It is aimed at slightly-technical readers (those, who know what a payment channel is), who lack time or expertise to read a full paper. We hope that this article spawns more feedback from the readers, which can be sent as a response to the mailing list post or to Gleb directly via firstname.lastname@example.org.
In this piece, BitMEX grantee Gleb Naumenko talks through approaches to mitigate channel jamming on the lightning network. Channel jamming is when a malicious entity blocks up liquidity in the lightning network, by making a payment to themselves, via third party channels and then never revealing the secret, such that the payment never completes. Gleb discusses the potential solutions to this problem, both short-term fixes and long-term protocol changes. He concludes by explaining that there is no simple all encompassing solution and that some of the effective mitigation systems may be complicated to implement. Therefore, the path forwards may require substantial extra research and discussion.
In this post, 100x Group grantee Gleb Naumenko and Antoine Riardwe explore a different approach to channel jamming mitigation. They are suggesting using UTXO ownership proofs (a.k.a. Stake Certificates) to solve the channel jamming problem. Previously, these proofs were only used in the Lightning Network at channel announcement time to prevent malicious actors from announcing channels they don’t control. One can think of it as a “fidelity bond” (as a scarce resource) as a requirement for sending HTLCs. They start the piece by overviewing issues with other solutions, and then present a naive, privacy-broken Stake Certificates. Then they examine designing a privacy-preserving version At the end, they talk about non-trivial design decisions and open questions.
In this article Gleb writes about how Bitcoin Core connects to other nodes on the network. He first provides some background about the latest default connection policy in Bitcoin Core 0.20.0, before explaining why there may be weaknesses in the current system which could make it easier for malicious actors to initiate an eclipse attack. Gleb goes on to talk about a potential more robust experimental peer selection methodology called “asmap”. Gleb then provides instructions for testing this new feature. Testing would help in ensuring the best security practices become more accessible.