Page MenuHomePhabricator

[ecash-herald] Implement ecash-script for OP_RETURN parsing
ClosedPublic

Authored by bytesofman on Jun 7 2023, 00:04.

Details

Summary

T2972

Simplify existing parseOpReturn function to use ecash-script library.

Test Plan

npm test

Diff Detail

Repository
rABC Bitcoin ABC
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

Fabien requested changes to this revision.Jun 7 2023, 14:23
Fabien added a subscriber: Fabien.
Fabien added inline comments.
apps/ecash-herald/constants/op_return.js
19 ↗(On Diff #40633)

?

apps/ecash-herald/src/parse.js
317 ↗(On Diff #40633)

nice

327 ↗(On Diff #40633)

According to the change above it should end with the memo.prefix ?

351 ↗(On Diff #40633)

Note that this will likely fail as the ascii values are in the range 0x00-0x7F and not 0x00-0xFF

This revision now requires changes to proceed.Jun 7 2023, 14:23
apps/ecash-herald/constants/op_return.js
19 ↗(On Diff #40633)

The old parser had to deal with pushdata. So, while it did "work," it was hardcoded to only parse memo txs that were pushed with '02'

memo is unique in that the prefix is '6d' (1-byte) , but it is always pushed with '02' because there are many different actions. e.g. 026d01 means this tx is a memo tx that is setting name, 026d02 means this tx is posting a memo, etc.

The parse memo function will need to be refactored to take advantage of the improvements available with consumeNextPush but for now I didn't touch it.

02 needs to be removed here because consumeNextPush does not return pushdata, just the push itself. Better since now we could parse memo txs with the prefix pushed differently, tho I haven't seen any of these.

apps/ecash-herald/src/parse.js
327 ↗(On Diff #40633)

Previously, we were getting prefixes by checking hardcoded initial characters. So, memo was differentiated as having a 2-byte prefix.

Now we just get the protocolIdentifier as the first element of stackArray.

For memo, the first push is always different depending on the action. So, it will be 2 bytes and start with 6d, e.g. 6d01, 6d02, etc -- it's not like other protocols where the first push is simply the 4-byte identifier and always the same.

351 ↗(On Diff #40633)

hm good point. Basically any attempt to just spit out an attempted parsing of an unknown OP_RETURN will likely have some weird characters, general failures. At the same time, this type of parsing is more human-readable than the hex.

Block explorers do it this way even though it might not look great. The failure mode is to just print some nonsense characters, it doesn't throw an error.

Fabien added inline comments.
apps/ecash-herald/src/parse.js
327 ↗(On Diff #40633)

Got it, the 02 was the push opcode not the memo action

351 ↗(On Diff #40633)

OK, the failure mode is sensible

This revision is now accepted and ready to land.Jun 7 2023, 18:13