search

LayerTwo-Labs / cusf_sidechain_proto

gRPC protocol definitions for a CUSF BIP300/BIP301 sidechain.
1 stars 2 forks source link

Consider removing fields from `CreateNewAddressRequest` #6

Closed torkelrogstad closed 1 week ago

torkelrogstad commented 1 week ago
  1. Label: would require us to keep a mapping of addresses to labels. No real in point in that, IMO.
  2. Address type: Would require us to manage different descriptors, effectively having to keep a set of different wallets. This also strikes me as not necessary.

https://github.com/LayerTwo-Labs/cusf_sidechain_proto/blob/b32acc20e8ee1649f35ced15325b1b9f18423b5a/proto/cusf/mainchain/v1/wallet.proto#L60-L63

nchashch commented 1 week ago

So we will decide which type of address the wallet will issue and then hard code it, and we won't use labels.

For the sidechain that makes sense, because the only time the sidechain would need to call CreateNewAddress is when creating withdrawal requests. And for withdrawal requests it should be fine to have all of them withdraw to a P2PKH addresses.

Because after the withdrawal is complete, you can always spend the output you got on the mainchain and lock the funds with the kind of script you want.

So the cost of hard coding the address type is that people who would want to change the address type of their withdrawal payout outputs will have to make an extra transaction. I think that would be a small minority and making an extra transaction is a small cost.

Then the benefit would be the reduced complexity of the sidechain <-> mainchain wallet protocol. Also we won't have to implement the GUI for managing descriptors/different address types in Thunder -- the GUI would also be simpler for the end user.

So I think it is worth it, we should remove the fields, at least for now.

In the future if we need the descriptor functionality we can always put the fields back in or add another RPC.