Skip to content

Instantly share code, notes, and snippets.

View Kixunil's full-sized avatar

Martin Habovštiak Kixunil

View GitHub Profile
@Kixunil
Kixunil / quick_dive_rust_code.md
Last active February 4, 2023 19:00
WIP quick dive into a source code written in Rust

Quick dive into a source code written in Rust

Are you a Rust newbie who found some code written in Rust and wants to dive right into the code? You're at the right place! This quick guide is supposed to help you in exactly this situation. It's not meant to be a full Rust tutorial - there are beter sources of those!

Quick intro

Two basic things you should know before you start:

@Kixunil
Kixunil / efficient_reusable_taproot_addresses.md
Last active April 14, 2023 22:07
Efficient reusable Taproot addresses

Reusable taproot addresses

Abstract

This document proposes a new scheme to avoid address reuse while retaining some of the convenience of address reuse, keeping recoverability purely from Bitcoin time chain and avoiding visible fingerprint. The scheme has negligible average overhead.

Motivation

@Kixunil
Kixunil / beta-gpg-key.asc
Created August 11, 2020 17:05
Declaration of ownership of GPG key
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I hereby declare that I'm the owner of GPG key with fingerprint
3D9E81D3CA76CDCBE768C4B4DC6B4F8E60B8CF4C
Which I use to sign beta-quality software.
This software should be mostly usable, but was not WIDELY tested.
It may contain bugs or even security vulnerabilities, as any other software.
@Kixunil
Kixunil / anyonecanboost.md
Last active March 27, 2024 16:32
Anyone can boost

Anyone can boost - a more efficient alternative to anchor outputs

Abstract

Bitcoin protocols using presigned transactions (e.g. Lightning Network, Firefish etc) face a problem with predicting fees of the presigned transactions. One possibility is to guess the future fee rate but that risks that the transaction will not be included in a block fast enough and it also risks wasting satoshis on fees. Another possibility is to use CPFP which may require adding more outputs - so called "anchor outputs". The drawbacks of anchor outputs are increased transaction size and potentially decreased privacy since the anchor outputs usually use "suspiciously low" amounts. Further, anchor outputs may pollute UTXO set if the presigned transaction confirms anyway (because it also had high enough fee) but the outputs are uneconomical to spend. This document proposes a new solution that could not only solve these issues but bring even more efficiency gains in the future.