Ark encoding

[altafan]

This fixes the existing method for secret/public key encoding and adds support for:

• encoding/decoding ark addresses
• encoding/decoding ark relays
• encoding/decoding ark url

This also fixes the name of the submodule, called now github.com/ark-network/ark/common.

This also adds a replacement in the main go.mod for the import of the submodule for future tasks.

Last but not least, this adds (few) tests for all the encoding methods.

Please @louisinger review.

[louisinger]

Wouldn't be better to include the Ark provider public key into Ark addresses ? most of the time, you don't want to receive VTXOs on every arks but only on a specific one

[bordalix]

Just my 2 sats:

1. Should we include a version prefix on addresses?
2. Why bech32 and not bech32m?

Bech32 has an unexpected sipa/bech32#51: whenever the final character is a 'p', inserting or deleting any number of 'q' characters immediately preceding it does not invalidate the checksum. This does not affect existing uses of witness version 0 BIP173 addresses due to their restriction to two specific lengths, but may affect future uses and/or other applications using the Bech32 encoding.

[tiero]

Why do we need to encode the relay on his own? Shouldn't just be part of the address?

[altafan]

Why do we need to encode the relay on his own? Shouldn't just be part of the address?

@tiero It's part of the ark url used to connect to an ASP, not the address you get from a receiver.

Since nostr has a dedicated prefix for relays, I thought it was worth keeping this distinction.

[altafan]

• Should we include a version prefix on addresses?

@bordalix for the PoC i would say no, but if you take a closer look at the fixtures, you can see the prefixes are actually asec1, apub1, ark1, arelay1. It seems the bech32 pkg already adds a version byte and I think it's enough for us now. In alpha, we will definitely add our own version byte.

• Why bech32 and not bech32m?

Nice catch, I moved to bech32m indeed. The btcutil's bech32 package already supports it.

[louisinger]

nit: what do u think of having a struct as return type instead of a tuple key, key, err ? Saying this because it's hard to discriminate user/asp key looking at the signature as it is

[altafan]

I'll add a name to the return values

[altafan]

done.

[bordalix]

No, the 1 in bc1 is the separator, not the version (bc1 = hrp + separator). The version comes after the separator, and bech32(0) = q and bech32m(1) = p

address = hrp + separator + bech32x(version + ripe160(sha256(pubkey))

That's why all segwit addresses (version 0) start with "bc1q" and all taproot addresses (version 1) start with "bc1p"

https://en.bitcoin.it/wiki/Bech32

[tiero]

I propose to keep relays outside of the Ark address, and only the two pubkeys. Fine to have apub and asec for now.

We can have it as part of a BIP21 address URI

ark1[...]?relays=[wss://my.domain.com/]  

together with other things BIP21 may specify

[altafan]

@tiero ATM the address encodes only user and asp pubkeys, while relays are encoded in the ark URL. This is an example of valid address.
The idea is that this URL is used only at client setup, to connect with an asp. This is an example of valid ark URL.

Clients can verify that the asp pubkey encoded in a receiving address matches the one they have in their ark URL.

Therefore, the pubkey of the asp is used as its identifier and shouldn't change.

Does this make sense to you?

[tiero]

Yes, not sure the ark:// has real utility compared to a simple BIP21 address.

The idea is that this URL is used only at client setup

Not sure this is something desirable for the ASP ie. having user to "connect" to them, rather than just listening on the common channel for payment requests.
But not holding this PR for this, we can always deprecate later.

[altafan]

Not sure this is something desirable for the ASP ie. having user to "connect" to them, rather than just listening on the common channel for payment requests.

In my mind it's not a "direct" connection.. rather, the ASP announces in the ark URL his identity, ie his public key, and the list of relays through which he communicates with the users. It feels overkilling to me carrying on this info in every receiving address generated by users (if that's what you mean when you speak about ark addresses).