d80dba048c2a020e6b0ce191d1470bdb0a82c148 doc: document the release process in a new document (Antoine Poinsot)
187857f106d639246f70278d4a55422f89014fd1 README: add a link to our Discord (Antoine Poinsot)
Pull request description:
This document a bunch of stuff i've been doing for every release in the past years. I've detailed it in a number of steps for clarity.
Fixes https://github.com/wizardsardine/liana/issues/803.
ACKs for top commit:
edouardparis:
ACK d80dba048c2a020e6b0ce191d1470bdb0a82c148
Tree-SHA512: c9f166c1ecfc595fcc3cd34d8603f6f2a67747625847e745fde5846dc5e687f04ac2e57886949f3f620ff1a55c40dc398cabc3013f058ddf70e00c73f3ec5922
We are being pulled over in two different directions when it comes to
our reproducible builds. On the one hand we need to target reasonably
old glibc versions in order to be compatible with older systems. On the
other hand the immaturity of the Rust ecosystem makes us require
bleeding edge versions of the compiler. With Guix to get the newer
versions of the compiler we need to also bump the glibc version.
This was not a sustainable situation. I was planning for a long time to
cleanup our reproducible builds. To create a proper Guix package for
both the daemon and the GUI using the build system they provide. I had
envisioned this way i could rewrite the inputs of the Guix package to
use an older glibc, while being able to bump the Guix time-machine. It
would even have allowed us to perform Windows builds inside Guix! And
who knows i could even have attempted to perform Apple ones too.
Unfortunately it turned out to be more complicated than that. I couldn't
manage to get my package to compile using an older glibc. Some details
about some of my failed attempts can be found there:
https://lists.gnu.org/archive/html/help-guix/2024-04/msg00056.html.
Instead of wasting more time on this, backport the newer Rust
declarations from up-to-date Guix to Guix-of-our-time-machine.
13398982534d56a5723dfa86723c5917483c8653 commands: include missing amount in response (jp1ac4)
Pull request description:
This PR follows a discussion around https://github.com/wizardsardine/liana/pull/873#issuecomment-1886715468.
The GUI uses the `InsufficientFunds` error to get the missing amount when the user is creating a new spend, but it is not straightforward to extract this information in a general way from the RPC error (see https://github.com/wizardsardine/liana/issues/822#issuecomment-1836482355) and instead the spend module's `create_spend` is currently used (see https://github.com/wizardsardine/liana/pull/863).
With this PR, the missing amount will be included in the `createspend` response rather than as an error.
These changes are based on suggestions from @darosior and @edouardparis.
In a follow-up PR, the GUI should revert to using the `createspend` command to calculate the amount left to select.
ACKs for top commit:
darosior:
re-ACK 1339898
Tree-SHA512: bf702d6b355339e96e719c1d95824e7941ac4fbaece4ec4cccd00b56ea4683ce7fb0cefc43faa5731b57e7935ef99da3a2c73b84aaeb9fa5f67703c799be2196
The GUI uses the InsufficientFunds error to get the missing
amount when the user is creating a new spend.
It is not straightforward to extract this information in a
general way from the RPC error. Instead, this missing amount
will be included in the command response.
These changes are based on suggestions from darosior
and edouardparis.
We leverage the change logic for this. By making it possible to set the
change address to an external address, one can send all the value from
the inputs to this address.
When creating a new spend, if coin outpoints are not provided,
then coins will be selected automatically.
This automatic selection is such that the transaction fee is
minimized, taking into account the cost of creating any
change output now and the cost of spending it in the future.
If change is added, it must reduce the transaction waste and
be above the dust threshold. This same policy is applied also
in the case of manual coin selection, replacing the previous
logic for determining the change amount. This ensures that
creating a spend with auto-selection and another with manual
selection using the same auto-selected coins will give the
same change amount.
2660b77487d63218019413a4ca33b3a9629fbfc8 implement listadresses (pythcoiner)
Pull request description:
address #681
todo:
- [x] implement tests
- [x] update docs
edit: i'm really new to rust, don't hesitate to kick my ass when i write stupid code
ACKs for top commit:
darosior:
ACK 2660b77487d63218019413a4ca33b3a9629fbfc8 -- my requests are addressed in followup #808.
Tree-SHA512: a5fdfb4516dc0379bfec1be535e752795dec75d28cbc5b9fa4fe9898fa00b1cfaa9cee3b95f4dfd68365f4585426e1b4457a8366cc4f783600704994f879526f
This reverts commit 71056982636b408485ab24dab6628a555a6e7924, reversing
changes made to 03c37bd378f4f6bf11d90b224ed1db74b3596eaf.
This reverts PR #722. It turns out the Ledger Bitcoin app needs the
BIP32 derivation for all the keys in the Script, not only for the
spending path used. Therefore always create PSBT with all the BIP32
derivations. We'll add a way to prune them for talking to the Bitbox in
a future commit.
7f3b0b021858cfb2fe914f3ba6b30a39e3ae05ff qa: test a PSBT has only the BIP32 derivations for a single spending path (Antoine Poinsot)
b71bd693d6ea4c1c3567194fc82be43fb70c05bb qa: don't use a static dummy origin for descriptor xpubs (Antoine Poinsot)
a81d39c81a89cdf5e70b9888cbeb3abaf290a365 commands: do not include BIP32 derivations for other spending paths (Antoine Poinsot)
Pull request description:
ACKs for top commit:
edouardparis:
ACK 7f3b0b021858cfb2fe914f3ba6b30a39e3ae05ff
Tree-SHA512: f0e132edf8d653c5575f843b1e85d995f155a2435a6e6257564dc945562df70ec2049c29d77f7580858d9e4a58290b0798f298f77c18255415c4cf26ccc07f33
When creating a PSBT, only include the BIP32 derivations in each input
for the spending path this PSBT was created for.
This is to workaround Bitbox only providing a single signature per
input. Most likely other signing devices will have this behaviour too in
the future. See
https://github.com/wizardsardine/liana/pull/706#issuecomment-1744705808.
