My PhD research is mainly on the Balance Discovery Attack (BDA). The BDA was introduced (in academia) by Herrera-Joancomartí et al.. In their paper they used the term balance discovery attack and balance disclosure attack interchangeably. Nowadays the term probing or probing attack is more commonly used, but I prefer BDA, so I'll keep using that while shouting at the clouds.

The BDA is an attack on privacy. It can be used to discover balances of payment channels, but when used over a longer period of time it can also be used to detect actual payments. These are things we want to keep private, so it is interesting to look at ways of preventing this data from being leaked. Multi-part payments, and more specifically Payments Split & Switch (PSS) has some surprising effects that can prevent data from being leaked in ways that I will try to explain in this post.

Lightning Network uses source-based routing. What that means is that the sender is responsible for finding a route to the payee. But because the sender doesn't know the balances of all channels along a possible route, the proposed route can fail for lack of liquidity. So the sender is forced to try routes until it stumbles upon one that has enough liquidity to relay the payment; it's a process of trial and error. To increase the likelihood of success the idea of splitting up a payments into smaller parts was floated early on in the development of Lightning Network. The idea was that multiple smaller payments were more likely to succeed than one big payment. But you still want all separate parts of such a payment to act as one single atomic payment, that either succeeds completely or doesn't succeed at all.

There is this cool trick you can do with Schnorr signatures. It is called Adaptor Signature (AS). An adaptor signature is an extra signature that, combined with the original signature, allow for revealing a value that was previously hidden. You can use this trick to solve trust problems as they appear in atomic swaps, coin swaps and Discreet Log Contracts (DLCs).

Signature Aggregation (SA) is a way to aggregate multiple signatures into a single signature. The single aggregate signature is smaller (in bytes) than the original signatures combined. It reduces transaction weight, meaning we can have more transactions per block, which is always a good thing. It's like 7zip for transactions. Signature Half Aggregation is a variant of SA that only aggregates half of each signature. It offers less compression, but it has the benefit of not requiring any interaction with the signers, whereas full aggregation does require cooperation of all the signers.

So two cool tricks, but the latter breaks the former when it is used for blockwide signature aggregation. This article explains the math behind it and why SA breaks AS

Lightning Network is a peer-to-peer payment network that runs on top of the Bitcoin Blockchain. Because it runs on top of the Blockchain it is called a layer-two solution, which groups it together with other solutions that have this property of being built on top of a Blockchain. Layer One is the base layer, where the Blockchain lives. Because of the inherent properties of Layer One, it is impossible to process large amounts of transactions in that layer. The Bitcoin Blockchain can famously process a mere seven transactions per second on average. This constraint was the main impetus for the creation of Layer Two solutions. Lightning Network, being a Layer Two solution, allows for near instant transactions, that can easily scale to millions of transactions per second.

Image conversion and resizing for the web can be quite fiddly. Take responsive websites for instance. You want to show a smaller version of your image on smaller devices: You don't need to download a 1080px wide image to show on a 360px wide device, especially since that device is likely constrained in the amount of bandwidth it has. Then again when your website is shown on an ultra HD screen with 3840x2160 resolution 1080 is maybe even too small.

Apart from multiple sizes, you also want to offer multiple formats. Modern browsers support new(er) image formats like webp and avif offer better compression for comparable image quality. Using these formats you can decrease the total download size of your page, while improving the overall experience for the user. But you just can't assume (yet) that all browsers support those newer formats, so you have to provide older formats as a fallback option. All in all the amount of different files you have to offer for just a single image on a web page starts to become quite large and the whole thing becomes, like I said, fiddly.

Writing a scientific paper is hard. Doing your PhD is hard. Writing your thesis is hard. And to make me feel even more miserable I decided to measure my progress by counting the net change in words I achieve throughout each day. I am by no means a productivity guru and I don't know whether word count is a useful indicator for measuring the progress of a paper. That being said, it is a reality check to see how fast my work is progressing. So without further ado here's the Powershell command that outputs the wordcount for the last 25 days based on git commits. (For the bash command, see the bottom of this post)

for($i = 0; $i -lt 25; $i++){$j = $i + 1; Write-Host (get-date (get-date).addDays(-$i) -UFormat "%Y%m%d") ((git diff --word-diff=porcelain "@{$j days ago}" "@{$i days ago}"   -- "***.md"| Select-String -Pattern "^\+.*" | Measure-Object -word | select -ExpandProperty Words) - (git diff --word-diff=porcelain "@{$j days ago}" "@{$i days ago}"  -- "***.md"| Select-String -Pattern "^-.*" | Measure-Object -word | select -ExpandProperty Words)) }