Digital Signatures History 1976: Whitfield Diffie and Martin Hellman first described the idea of a digital signature scheme, but they only theorized that such schemes existed. 1977: Ronald Rivest, Adi Shamir, and Len Adleman invented the RSA algorithm, which could be used to produce a kind of primitive digital signature. 1988: Lotus Notes 1.0, which used the RSA algorithm, became the first widely marketed software package to offer digital signatures. 1999: The ability to embed digital signatures into documents is added to the PDF format. 2000: The ESIGN Act makes digital signatures legally binding. Until today: Some institutions and websites have emerged to legalize digital signatures and verify identity. Digital signatures have evolved over time, becoming an integral part of secure communication and document integrity.

Collaborators: Kasra Khoshjoo, Reza Pishkoo This repository contains summaries and presentations of the project "Profit Maximization on Lightning Network", in which we investigate strategies for maximizing revenue from transaction fees. Introduction In the Lightning Network, transactions pass through channels to avoid the difficulties of making transactions in the Bitcoin Blockchain. Each owner of payment channels sets a fee rate on transactions passing through. The question is, who should connect with, and how much capacity should be allocated to each channel to become a transaction hub and maximize the profit of receiving fees? We investigate this problem from the perspective of bandit problems and available theoretical tools in the literature[^fn1]. (slides of a presentation summarizing our progress until Nov 2023 are available here) Summary of our findings (non-chronological order)

In this note, we define and explain HTLC. After that, introduce atomic swap by using HTlC, and take a look at an example of atomic swap between chana A and chain B. Note: In all examples, Alice is the seller and Bob is the buyer. Hashed Timelock Contract (HTLC) is a framework used for payment transfers via platforms like the Lightning Network, allowing receivers to confirm the receipt of funds before time-out. The primary goal of HTLCs is to provide an extra level of security while transferring funds through a decentralized system. Hash time lock contracts can help to eliminate the need for third parties in contracts between two parties. Third parties that are often involved in contracts are lawyers, banks, etc. Lawyers are often required to draw up contracts, and banks are often required to help store money and then transfer it to the receiving party in the contract. With hash time lock contracts, two parties could hypothetically set up contracts and transfer money without the need for third parties. This is because the sending party could create the conditional payment, and then the receiving party could agree to it, receive it, and help validate the transaction in the process.

Suppose Alice has some Bitcoin and Bob has some other coin(e.g., Litecoin). Alice wants to trade her bitcoins for Bobs litecoin. However, they both want to preserve their privacy, so an outside adversary or even an observer (e.g., Eve) could not distinguish Alice and Bobs transactions from ordinary bitcoin transactions like a simple transaction between Alice and Carol in which Alice sends some bitcoin to Carol. Note that having such a feature on bitcoin's blockchain not only improves bitcoin's fungibility but improves all network participants privacy due to the fact that anybody analyzing the blockchain must now deal with the possibility that Carol's transaction was actually a simple payment or an atomic swap or a smart contract(script) etc. To understand how the aforesaid swap can be done some prior knowledge is needed:

alidarvishi14@gmail.com with help from https://github.com/barnabemonnot/abm1559 Introduction EIP 1559 is an upgrade to the economic model of Ethereum gas fee. Proposed by Vitalik Buterin in his Blockchain Resource Pricing paper, this mechanism is going to replace the first-price auction model governing the current fee market for transaction inclusion. The basefee and EIP-1559 As discussed in EIP-1559, users have to pay a basefee that will be burned for each transaction. Basefee is updated with a multiplicative rule derived from the size of the last block. If the last block size is more than the target size, basefee will increase, and if the last block is not full enough, basefee will decrease.