-
Notifications
You must be signed in to change notification settings - Fork 132
[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
base: main
Are you sure you want to change the base?
Changes from 1 commit
62de43e
28b00f9
77b6a4a
69846c4
d550e87
2b81b77
c1357ed
33352ba
640d57f
7b03e20
332c817
aa0e923
c2b9ffc
8101fa1
601bb7e
ad9dd7f
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -201,6 +201,13 @@ type SendManifest struct { | |
// to the auth mailbox server. | ||
TxProof TxProof | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Looks like we're duplicating the block header + height here across There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The envelope itself isn't encoded, only the |
||
|
||
// ExpiryBlockDelta is a user-defined expiry block height delta for the | ||
// message. Once the outpoint claimed by the proof provided by this | ||
// message has been spent, then after this number of blocks after the | ||
// spending transaction height the message can be considered expired and | ||
// may be deleted. | ||
ExpiryBlockDelta uint32 | ||
|
||
// Receiver is the receiver's public key of the asset outputs, used | ||
// to decrypt the send fragment. This is the internal key of the address | ||
// that was used to send the assets. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps we should create a distinct interface? The addr fragments are proofs, but it may be the case that the same
Courier
that can handle proofs, can't also handle the new addr fragments.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I think I initially misunderstood your comment here #1587 (comment) and interpreted it as also using the same method. But can take things apart again, no problem.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, actually, this would make things a bit more complicated to implement. With the send fragment being delivered in the same method as the actual proof, we can re-use the same backoff and re-try logic for the fragment as we do for the proof itself. This also makes it sort of an atomic operation for the caller, so they know whether the status for an output can be completed.