[group key addrs 6/6]: send and receive support for V2 addresses #1587
Conversation
proof/send.go
Outdated
| // ScriptKeyDerivationUniquePedersen means the script key is derived | ||
| // using the address's recipient ID key and a single leaf that contains | ||
| // an un-spendable Pedersen commitment key | ||
| // (OP_CHECKSIG <NUMS_key + asset_id * G>). This can be used to |
There was a problem hiding this comment.
Ah ok, so this is just to ensure unique script keys for each unique asset ID in a send fragment, but we still plan on inserting that new asset TLV containing the shared secret hash to make all asset commitments for a given addr unique?
There was a problem hiding this comment.
Correct. Will add the odd TLV value to make sure identical sends (e.g. same amounts and same asset IDs) will still produce a different on-chain output for better privacy.
| // TxProof is the proof of the transaction that contains the asset | ||
| // outputs that are being sent. This is used as proof-of work to show | ||
| // to the auth mailbox server. | ||
| TxProof TxProof |
There was a problem hiding this comment.
Looks like we're duplicating the block header + height here across TxProof and SendFragment. Or is the idea that the encoding is smart enough to only encode once and copy the fields over as needed?
There was a problem hiding this comment.
The envelope itself isn't encoded, only the SendFragment within. So the TxProof here is is what's required to send the fragment to the server.
Perhaps "envelope" isn't the best analogy here, as that's also sent along with a letter/message. Going to rename this to SendManifest instead, perhaps that makes more sense.
| Proof: &mboxrpc.SendMessageRequest_TxProof{ | ||
| TxProof: rpcProof, | ||
| }, | ||
| // TODO(guggero): what value? |
There was a problem hiding this comment.
Good question...I think will depend on what we end up using as the max block height/expiry value for the server.
| if err != nil { | ||
| return nil, fmt.Errorf("unable to decode "+ | ||
| "addr: %w", err) | ||
| } | ||
|
|
||
| // TODO(guggero): Need to add send fragment envelopes to |
There was a problem hiding this comment.
Can spin out into a sub-issue.
Do the vPSBTs actually need to be updated though? IIUC, we just need to specify the new proof courier semantics.
tapfreighter/chain_porter.go
Outdated
| "service handle: %w", err) | ||
| } | ||
|
|
||
| err = courier.DeliverFragment(ctx, envelope) |
There was a problem hiding this comment.
Any reason to not fold this into the loop below where we'll attempt to send out the proofs/fragments in parallel?
tapfreighter/parcel.go
Outdated
| @@ -483,6 +486,8 @@ type sendPackage struct { | |||
| // associated Taproot Asset commitment. | |||
| InputCommitments tappsbt.InputCommitments | |||
|
|
|||
| FragmentEnvelopes map[uint32]*proof.SendFragmentEnvelope | |||
| // required for V2 addresses that don't specify an amount (amount of zero). | ||
| // If an address does specify an amount, then it cannot be overridden in | ||
| // this map. | ||
| map<string, uint64> address_amounts = 5; |
There was a problem hiding this comment.
Hmm, for parsing, what if we allowed tap_addrs to be blank if this is specified, then we only read out address_amounts. This way a user doesn't need to specify an addr twice if it's a v2 addr.
Another alternative would be to upgrade tap_addrs to be a new message type, that can specify the addr, then also a custom amount.
Mainly thinking about how we can streamline the process of a new user potentially unknowingly using a re-useable addr.
guggero
force-pushed
the
group-key-addr-part-2
branch
from
a5c2fd0 to
b482ea3
Compare
guggero
changed the title
guggero
changed the title
guggero
force-pushed
the
group-key-addr-part-2
branch
from
b482ea3 to
8f8e164
Compare
guggero
force-pushed
the
add-mailbox-server
branch
from
094b31e to
3d1a126
Compare
guggero
force-pushed
the
group-key-addr-part-2
branch
from
8f8e164 to
060159b
Compare
guggero
force-pushed
the
add-mailbox-server
branch
3 times, most recently
from
dc426c6 to
74953ff
Compare
guggero
force-pushed
the
group-key-addr-part-2
branch
2 times, most recently
from
db7f36c to
a3dbdd3
Compare
guggero
changed the title
guggero
changed the base branch from
add-mailbox-server
to
pedersen-keys-refactor
This introduces a workaround that gets us WHERE xxx IN (...) queries working with a little trick. See the comment in scripts/gen_sqlc_docker.sh for more information on how this works and why the workaround is needed.
This MultiSubscription helper struct allows us to subscribe to receive messages for multiple keys held by a receiving wallet but all consolidated into a single message channel.
guggero
force-pushed
the
pedersen-keys-refactor
branch
from
5687720 to
46d9159
Compare
guggero
force-pushed
the
group-key-addr-part-2
branch
from
a3dbdd3 to
ad2c782
Compare
guggero
force-pushed
the
pedersen-keys-refactor
branch
2 times, most recently
from
e5fdf7e to
eea552e
Compare
Depends on #1621.
This is a very early prototype that barely works.
But it shows all the areas that need to be touched to support V2 addresses.
This will likely be split into two or three PRs, once fully finished and cleaned up.