CoinPayments Integration

hanh · June 16, 2021, 2:21pm

Not that I can see. Monero has a similar feature, they call it “subaddress” Subaddress - Monero Documentation and they recommend to always use them.

Here’s a link to the relevant discussion in zcash github

github.com/zcash/zcash

[Sapling] diversified addresses

opened 04:39PM - 01 Jan 16 UTC

closed 10:35AM - 19 Mar 18 UTC

daira

I-SECURITY A-crypto I-performance I-privacy use case A-circuit not in 1.0 special to Daira F-selective-disclosure M-requires-zip NU1-sapling elliptic curves

It is an advantage of Zerocash that even when a payee uses a single address publ…ic key, some level of payer anonymity is retained. However the payers can compare the public keys they were given and determine that they are paying the same entity. It would be nice if there were a way to diversify public addresses so that they cannot be linked, but retain a single private key for ease and efficiency of address management. In particular, the key-private decryption key would be the same for a given set of diversified addresses, so that it would be possible to scan the blockchain for buckets encrypted to any of the addresses in that set, simultaneously. One way of doing that is: Let Sid be a diversifier, which must be long enough that it is unlikely to collide between two diversified addresses _in the same set_ when chosen randomly. Let GH ("group hash") be a hash function that takes a diversifier into a random element in an elliptic curve group (with unknown exponent). Let CRH be a collision-resistant hash. Let a private key be (ask, skenc) generated as in the current Zerocash protocol. Let a public address be (Sid, apk,id, pkenc,id) where pkenc,id = skenc . GH(Sid) and apk,id = CRH(Sid, ask). Other changes are obvious: we use GH(Sid) in place of the base point of the curve, and we include Sid in a note plaintext so that we can check the corresponding apk,id when given ask. Assume that GH is an ideal "random" hash into the group; then, the security is dependent on being unable to find skenc even when given multiple pairs (G, skenc . G) for random group elements G. This is a nonstandard assumption, but may be reasonable and is certainly not obviously bad. [Edit: it actually depends on not being able to link such pairs, which is a stronger assumption than being unable to find skenc, and at least as strong as DDH.]

hanh · August 10, 2021, 5:44am

Coin Payment C# Library

The Coin Payments C# Library is completed with unit and integration tests. There are two client connector classes.

BlockExplorer. It queries the ZAMS (Zcash account management system) and gets information about user balance, incoming funds and initiates payments.
Signer. The Signer is an offline service (i.e. Cold Wallet) that CP manages and secures independently.

We have provided both implementations as work in progress on the server side.

The Coin Payment C# Library is the client side.

ml_sudo · August 11, 2021, 5:50am

@aserrano could you please update the community on Coinpayment’s sudden and unexpected change in direction?

vamsi · August 11, 2021, 6:14am

can you please share the repo link ?

aserrano · August 11, 2021, 1:26pm

Sure. Hi everyone, CoinPayments has informed us that they are scrapping their plans for the new platform which was the driver behind this grant to add shielded support. They are going to continue to support Zcash payments on the platform, but this means the work @hanh has done toward the integration will not be implemented.

Hanh suggested that he would be able to repurpose some of this work toward a BTCPay integration instead. I’m supportive of this given the circumstances with the platform and hope ZOMG will consider extending funding for this work.

ml_sudo · August 11, 2021, 1:54pm

Thanks @aserrano.

I think a lesson we’ve learned here is that we will need to see direct commitment and involvement from all parties in the future (applicant and platform). It appears that they lobbied for this to happen while they’ve now just walked away, without any downside and without providing any color on how they intend to help us achieve our goal of continuing Zcash support going forward as their platform evolves.

@ZcashGrants

(correction: earlier I said that we lobbied for this. Apparently the CP reached out to us in the first place. Makes it look even worse I suppose.)

decentralistdan · August 13, 2021, 7:49pm

I am in favor of transitioning the focus to BTCpayserver, I mentioned a BTCpayserver “Fork” in my MGRC post but now understand that it is actually just an integration that needs to be completed & maintained.

https://docs.btcpayserver.org/Altcoins/

hanh · August 13, 2021, 10:36pm

A fork would require maintenance as well.

security fixe
protocol updates

Moreover, I think that merchants and vendors will have concerns regarding installing a fork.

Ps: a fork is easier to do. I would be able to add and change anything at will. Instead, I will need to create services and follow their API.