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.
Martin Habovštiak Kixunil
This is a proposal to develop a changelog generator tool more suitable for user-facing changelogs and based on experiences of existing projects. The rationale is provided to explain why this is better then existing alternatives. The foundational axioms are:
- Git history is not suitable as changelog because some commits are not important.
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!
Two basic things you should know before you start:
I have reviewed the Taproot PR and decided to write some notes. This is a combination of notes that may be useful for other (less experienced) reviewers to understand the code and possibly helpful for a bit wider technical audience to understand how Taproot works in better details. It's definitely not intended for general public.
| -----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. |
| xprop -spy -root -notype _NET_ACTIVE_WINDOW | sed -ue 's/^.*# //' -e 's/,.*$//' | while read id; do focused_vm="`xprop -notype -id $id _QUBES_VMNAME 2>/dev/null | cut -d '"' -f 2`"; test "$focused_vm" = "_QUBES_VMNAME: not found." && focused_vm=dom0; test -n "$focused_vm" && echo "`date +%s` $focused_vm"; done |
If you're reading this, it may mean you think my project is dead/unmaintained. Please read this before you dismiss it.
The short version is: please make sure to ask about a change you'd like before proceeding. It's likely I will reply an cooperate. A lack of updates often means that the code does what's intended.
So you see that there are no commits to my project for some time and maybe think it's not maintained. It's not that easy. Particularly in case of Rust crates. The primary reason for my project lacking changes is that I don't need the changes
This document proposes a novel way to improve coordination of users who wish to activate a new soft fork in Bitcoin. The main idea is to use smart contracts to incentivize users to actually enforce the soft fork with lower risk of support being too low. At the same time the contract is in effect only if significant part of economy agrees to it. The contract also signals the intent to miners and other users in a way that would be otherwise expensive for sybil attackers. This proposal also suggests an interesting way to pay developers for the development of the soft fork code.