Page MenuHomePhabricator

[ecash-agora] Add ALP support to `AgoraPartial.script`
ClosedPublic

Authored by tobias_ruck on Sep 12 2024, 22:40.

Details

Reviewers
bytesofman
Group Reviewers
Restricted Project
Commits
rABCaa2cdee2cf55: [ecash-agora] Add ALP support to `AgoraPartial.script`
Summary

Currently, AgoraPartial only supports SLP, with this diff it also supports ALP.

SLP and ALP have the same Agora Script except for the sub-script that builds the OP_RETURN output, as well as the last few ops.

ALP doesn't use the scriptSig to signal AGR0, instead it uses the OP_RETURN via eMPP. This increases tx size a bit, but simplifies usage significantly, as e.g. no ad setup tx is necessary anymore, and offers can be created directly in a single tx.

Depends on D16745.

Test Plan

npm test

Diff Detail

Repository
rABC Bitcoin ABC
Branch
ecash-agora-partial-script-alp
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 30273
Build 60073: Build Diffecash-agora-tests · ecash-agora-integration-tests
Build 60072: arc lint + arc unit

Event Timeline

modules/ecash-agora/src/partial.ts
947

probably best to move this to the SLP diff

A lot of complexity here. I'm not sure it's possible to really get what is going on without creating and taking offers. However, also important to limit the scope of the diff where its practical. So here, the tests confirm expected txs are made (tho the txs themselves are not really human-readable...at least not by this reviewer).

modules/ecash-agora/src/partial.script.alp.test.ts
120 ↗(On Diff #49658)

what's the difference between agoraPartial.scriptLen (212) and the bytecount of the hex code below (mb I made a mistake but I get 340 bytes)?

122 ↗(On Diff #49658)

is there any other way to confirm that this long hex string is .... "good" ?

modules/ecash-agora/src/partial.script.alp.test.ts
120 ↗(On Diff #49658)

The difference is that scriptLen excludes everything after the OP_CODESEPARATOR (which literally cuts out from the Script):

All of the signature checking words will only match signatures to the data after the most recently-executed OP_CODESEPARATOR.

It was thought this opcode is useless (and BTCers still believe it is, which is why they removed this behavior in Taproot), but here we can use it to cut out all the consts etc., to save the difference in bytes from the transaction.

That's why you see this difference—212 is the length of the Script to be found in the sighash preimage, whereas 340 is what will be in the redeemScript in the scriptSig...

122 ↗(On Diff #49658)

If you wanna go extra fancy you can put it into the decodescript RPC and match them up one-to-one with the script() function generating it (or just to ensure it even decodes).

But tbh I think it's fine reviewing the follow-up diffs where they're used in bitcoind, after all, if it quacks like a valid Script, it's probably a valid script.

This revision is now accepted and ready to land.Sep 18 2024, 21:29