Skip to content

[group key addrs 7/7]: send and receive support for V2 addresses #1587

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 17 commits into from
Aug 6, 2025

Conversation

guggero
Copy link
Member

@guggero guggero commented Jun 6, 2025

This PR introduces a new V2 address that:

  • Allows grouped assets to be sent.
  • Allows the amount to be defined as zero by the recipient, allowing the sender to choose the amount.
  • Can be re-used indefinitely without any privacy downsides.
  • Use a new proof courier type to transfer an encrypted send fragment from the sender to the receiver using a mailbox system (but a more robust mailbox than the previous hashmailbox implementation).

This change is Reviewable

@guggero guggero force-pushed the group-key-addr-part-2 branch from a5c2fd0 to b482ea3 Compare June 19, 2025 11:48
@guggero guggero changed the title [group key addrs 3/?]: send and receive support for V2 addresses [group key addrs 4/4]: send and receive support for V2 addresses Jun 19, 2025
@guggero guggero changed the title [group key addrs 4/4]: send and receive support for V2 addresses [group key addrs 5/5]: send and receive support for V2 addresses Jun 23, 2025
@guggero guggero force-pushed the group-key-addr-part-2 branch from b482ea3 to 8f8e164 Compare June 23, 2025 14:55
@guggero guggero changed the base branch from group-key-addr to add-mailbox-server June 23, 2025 14:55
@guggero guggero force-pushed the add-mailbox-server branch from 094b31e to 3d1a126 Compare June 24, 2025 08:27
@guggero guggero force-pushed the group-key-addr-part-2 branch from 8f8e164 to 060159b Compare June 24, 2025 08:27
@guggero guggero force-pushed the add-mailbox-server branch 3 times, most recently from dc426c6 to 74953ff Compare June 25, 2025 08:49
@guggero guggero force-pushed the group-key-addr-part-2 branch 2 times, most recently from db7f36c to a3dbdd3 Compare June 26, 2025 09:14
@guggero guggero changed the title [group key addrs 5/5]: send and receive support for V2 addresses [group key addrs 6/6]: send and receive support for V2 addresses Jun 26, 2025
@guggero guggero changed the base branch from add-mailbox-server to pedersen-keys-refactor June 26, 2025 09:17
@guggero guggero force-pushed the pedersen-keys-refactor branch from 5687720 to 46d9159 Compare June 26, 2025 10:18
@guggero guggero force-pushed the group-key-addr-part-2 branch from a3dbdd3 to ad2c782 Compare June 26, 2025 10:19
@guggero guggero force-pushed the pedersen-keys-refactor branch 2 times, most recently from e5fdf7e to eea552e Compare June 27, 2025 10:56
@guggero guggero force-pushed the group-key-addr-part-2 branch 2 times, most recently from ae1aefb to cd9b477 Compare June 30, 2025 15:33
@guggero guggero force-pushed the pedersen-keys-refactor branch from eea552e to 555c711 Compare June 30, 2025 15:34
guggero added 7 commits August 5, 2025 19:58
As a preparation for creating events from wire transactions that aren't
notified by the lnd wallet (and therefore don't come through the
lndclient calls), we make the arguments to GetOrCreateEvents a bit more
explicit.
We refactor the proof handling to allow multiple outputs to be processed
and proofs for them to be fetched.
Simplifies the code a bit by using the Goroutine helper method.
@guggero guggero force-pushed the group-key-addr-part-2 branch from c691660 to 9b0821a Compare August 5, 2025 17:58
@guggero
Copy link
Member Author

guggero commented Aug 5, 2025

Okay, the itest failures are constant now, not flakes. Must be something I changed in the last push. Will address first thing tomorrow.

@guggero guggero force-pushed the group-key-addr-part-2 branch from 9b0821a to a45379a Compare August 5, 2025 19:25
@guggero
Copy link
Member Author

guggero commented Aug 5, 2025

Found the itest issue, should be good to merge now.

@Roasbeef Roasbeef requested a review from ffranr August 6, 2025 02:20
Copy link
Member

@Roasbeef Roasbeef left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 🦜

Reviewed 43 of 63 files at r10, 20 of 20 files at r11, all commit messages.
Reviewable status: all files reviewed, 60 unresolved discussions (waiting on @ffranr, @guggero, and @ZZiigguurraatt)


itest/addrs_v2_test.go line 50 at r11 (raw file):

		amountToRequest := uint64(0)
		amountToSend := a.Amount - 1
		if amountToSend == 0 {

What type of error would get user get if they attempted to send a value greater than 1 to a collectible address? I wonder if we should encode that extra bit into the addr type.

FWIW, calls to decode the address should fetch the genesis as needed allowing this full information to be displayed.


tapdb/sqlc/queries/authmailbox.sql line 52 at r6 (raw file):

    m.encrypted_payload,
    m.arrival_timestamp,
    m.expiry_block_height,

Ah so we're removing this everywhere after all in favor the the should-be-good-enough-for-everyone value? np, we can always re add it later in a migration if needed


rpcserver.go line 1689 at r11 (raw file):

	// If the user didn't specify a specific address version but is using
	// a group key, we default to version 2.

👍


proof/courier.go line 1878 at r11 (raw file):

		// RPC methods that we require.
		statusErr, ok := status.FromError(err)
		if ok && statusErr.Code() == codes.Unimplemented {

Nice, I assume this is for cases where a Universe server hasn't updated to the latest version?


cmd/commands/addrs.go line 122 at r11 (raw file):

		// at least a V2 address. So we can just use that if the user
		// specifies no explicit version.
		if len(groupKey) > 0 {

👍

Copy link
Member Author

@guggero guggero left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewable status: all files reviewed, 60 unresolved discussions (waiting on @ffranr, @Roasbeef, and @ZZiigguurraatt)


itest/addrs_v2_test.go line 50 at r11 (raw file):

Previously, Roasbeef (Olaoluwa Osuntokun) wrote…

What type of error would get user get if they attempted to send a value greater than 1 to a collectible address? I wonder if we should encode that extra bit into the addr type.

FWIW, calls to decode the address should fetch the genesis as needed allowing this full information to be displayed.

Good question!
So due to this:

case asset.Collectible:

We don't allow addresses for collectibles to have a zero (optional) amount in the first place. So the error would already be thrown at address creation time: unable to make new addr: unable to make new addr: address: collectible asset amount not one.

I've added an integration test case for this!


proof/courier.go line 1878 at r11 (raw file):

Previously, Roasbeef (Olaoluwa Osuntokun) wrote…

Nice, I assume this is for cases where a Universe server hasn't updated to the latest version?

Yes, correct.


tapdb/sqlc/queries/authmailbox.sql line 52 at r6 (raw file):

Previously, Roasbeef (Olaoluwa Osuntokun) wrote…

Ah so we're removing this everywhere after all in favor the the should-be-good-enough-for-everyone value? np, we can always re add it later in a migration if needed

Yes, exactly. We can always add something later once we know exactly how/when we can do a cleanup without affecting emergency recovery.

guggero added 4 commits August 6, 2025 10:45
Adds the new --addrs_with_amounts flag that allows to specify the amount
to send to an address that allows sending user-defined amounts (address
V2).
For v2 addresses we want the address to only show the group key if a
group key is used. The value of the asset ID becomes meaningless for an
address that supports group keys. Unfortunately we can't really _remove_
the value from the address (it's always encoded). But we can set it to
all zeroes so it's more apparent to the user that it's not used.
@guggero guggero force-pushed the group-key-addr-part-2 branch from a45379a to a7b40ad Compare August 6, 2025 08:45
The re-try mechanism introduced in a previous PR didn't work properly,
because the re-try only happens if the callback returns an error.
This fixes the behavior by returning a temporary error to trigger the
re-try.
@ffranr ffranr added this pull request to the merge queue Aug 6, 2025
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Aug 6, 2025
@guggero guggero added this pull request to the merge queue Aug 6, 2025
Merged via the queue into main with commit d6a1cb7 Aug 6, 2025
19 checks passed
@github-project-automation github-project-automation bot moved this from 👀 In review to ✅ Done in Taproot-Assets Project Board Aug 6, 2025
@guggero guggero deleted the group-key-addr-part-2 branch August 6, 2025 15:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: ✅ Done
Development

Successfully merging this pull request may close these issues.

[feature]: add support for re-useable group key based addresses [feature]: support of passing arbitary amount to a taproot address
6 participants