Page MenuHomePhabricator

[Cashtab] [Chronik] [Tx Gen] Generate encoded OP_RETURN script
ClosedPublic

Authored by emack on Jun 14 2022, 12:08.

Details

Summary

As per T2503, this is part of a series of diffs to refactor the transaction generation process within useBCH.

This diff is a standalone utility function which generates an encoded OP_RETURN script to reflect the various OP_RETURN powered send XEC permutations involving messaging, encryption, eToken IDs and airdrops.

The existing OP_RETURN script generation logic in sendXec() has a bit of repetition based on the permutations, which this diff seeks to optimize by using a building block approach to the script array rather than rebuilding the entire script for each permutation.

This diff does not change any existing functionality within the codebase.

Test Plan

npm start
npm test
observe the successful execution of new useBCH.test.js unit tests

Diff Detail

Repository
rABC Bitcoin ABC
Branch
generateOpReturnScript
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 19414
Build 38561: Build Diffcashtab-tests
Build 38560: arc lint + arc unit

Event Timeline

emack requested review of this revision.Jun 14 2022, 12:08
bytesofman added inline comments.
web/cashtab/src/hooks/useBCH.js
1418 ↗(On Diff #34022)

While we are at this refactoring, let's completely pull out this buried API call. We shouldn't have any API calls inside a component function. Instead, we only make the API call if there is a flag -- and then we pass the output as a param into the function.

So, sendXEC would have this kind of call before this function is called -- which is okay since these are all lowest level calls.

If (encrypted) {

try {API call to get pub key, return pubKey as recipientPubKey}
catch (err) { throw err}

try {
            const pubKeyBuf = Buffer.from(recipientPubKey, 'hex');
            const bufferedFile = Buffer.from(optionalOpReturnMsg);
            const structuredEj = await ecies.encrypt(pubKeyBuf, bufferedFile);

            // Serialize the encrypted data object
            encryptedEj = Buffer.concat([
                structuredEj.epk,
                structuredEj.iv,
                structuredEj.ct,
                structuredEj.mac,
            ]);
        } catch (err) {
            console.log(`useBCH.handleEncryptedOpReturn() error: ` + err);
            throw err;
        }


generateOpReturnScript = (BCH, optionalOpReturnMsg, destinationAddress, airdropFlag, airdropTokenId, encryptionFlag, encryptedEj) {}
1471 ↗(On Diff #34022)

Match the approach used in D11617 so we can display error notifications of specific error msgs in the app

This revision now requires changes to proceed.Jun 16 2022, 23:29
emack marked 2 inline comments as done.
  • Removed the buried encryption API call for use in sendXec() prior to this function being called.aa
  • The removal of the encryption API call also meant this function no longer needs to be async - both the function and unit tests have been updated to reflect this.
  • Adjusted catch block to throw error for subsequent error notification use.
  • Added input param specific errors

Looks good but we need no husky changes

This revision now requires changes to proceed.Jun 17 2022, 17:18

Reverted husky change per feedback

bytesofman added inline comments.
web/cashtab/src/hooks/__tests__/useBCH.test.js
261

Hm maybe this is reflective of earlier implementation issue -- shouldn't the airdropTokenId be visible in this string? We don't need to further encode this.

https://reviews.bitcoinabc.org/rABCc069254a1268a846506e61ece05df90d7083f413

Let's sort this out before the sendXec refactor -- please open a new task to patch. TokenId should appear directly in the msg rather than hex encoded (which takes more space)

This revision now requires changes to proceed.Jun 20 2022, 18:04
emack marked an inline comment as done.

Rebased to D11644 and moved logic and unit tests into cashMethods.

bytesofman added inline comments.
web/cashtab/src/utils/__tests__/cashMethods.test.js
195 ↗(On Diff #34119)

Match the exact returned result of the function and not slice(0,12)

web/cashtab/src/utils/cashMethods.js
35 ↗(On Diff #34119)

Use currency.opReturn.opReturnPrefixHex

We will be refactoring / deprecating this BCH object

It is a nice idea to have all of these opcodes in a repo, i.e. the ultimate source of this at https://github.com/Bitcoin-com/bitcoincash-ops/blob/master/index.json

But I think not worth it to go through BCH to get to that directly. We'll eventually handle this differently.

This revision now requires changes to proceed.Jun 24 2022, 21:28
emack marked an inline comment as done.

Unit test for encrypted OP_RETURN script now validating the full result returned from function.
Updated OP_RETURN prefix constant to currency instance.

bytesofman added inline comments.
web/cashtab/src/utils/__tests__/cashMethods.test.js
176 ↗(On Diff #34140)

Remove the TODO comment

web/cashtab/src/utils/cashMethods.js
35 ↗(On Diff #34140)

Is this approach (versus the Buffer.from... approach used below in the script.push calls) necessary?

Using a set prefix from the currency settings object should be intuitive or there should at least be a standard approach that future developers can reference. We shouldn't have multiple patterns for this.

This revision now requires changes to proceed.Jun 27 2022, 20:07
emack marked 2 inline comments as done.

script.push(Buffer.from(currency.opReturn.opReturnPrefixHex, 'hex')); actually evaluates to '016a' instead of keeping the hex string intact. This behavour is specific to the initial script array element. To get around this, I've followed the bch-js approach of directly using the opReturn prefix in decimal form for the initial entry.

script.push(Buffer.from(currency.opReturn.opReturnPrefixHex, 'hex')); actually evaluates to '016a' instead of keeping the hex string intact. This behavour is specific to the initial script array element. To get around this, I've followed the bch-js approach of directly using the opReturn prefix in decimal form for the initial entry.

OK cool.

Could you add this info as a comment in the function?

My personal bias is to include any of these sorts of "huh ok" tidbits directly in the code, since they would be helpful to any new devs who might not have or seek out the phab history.

This revision now requires changes to proceed.Jun 28 2022, 16:31
This revision is now accepted and ready to land.Jun 29 2022, 04:23

Removed duplicate bchjs declarations