theseus/bundled-addons/aegis/lib/dgb/core/hd.js

22 lines
871 B
JavaScript
Raw Normal View History

fix(aegis): DigiByte import failed on every OTA install Reported as "the Aegis DigiByte import error". The vendored @dgb-wallet/core modules under lib/dgb/ imported "bitcoinjs-lib", "bip32", "ecpair", "bip39" and "@bitcoinerlab/secp256k1" as bare specifiers. Node's ESM resolver walks up from the importing file, so that resolves in a dev checkout — where Theseus's node_modules sits above the add-on — and resolves nowhere once Aegis is running from <userData>/extensions/aegis/, which is every OTA install. The import threw, index.js caught it and set dgbCore = null, and any DigiByte import then died in digibyteNetwork() with "DGB adapter not available". So DigiByte worked on a fresh install and disappeared after the first update. Confirmed on this machine: the only node_modules reachable from the installed extension carries bip39 and none of the other four. lib/dgb/deps.js now holds the dependencies, injected by index.js from api.require (which resolves against the app tree) before anything under lib/dgb/ is imported — the same pattern every other lib/*.js in Aegis already uses, and the reason that pattern exists. Consumers read them through accessors rather than capturing them at module scope, so import order is no longer load-bearing: hd.js builds its bip32 on first use and the two initEccLib callers go through a once-only ensureEcc(). Using a DGB module without injection now throws a named error instead of a resolver failure swallowed into a null. Verified by loading the modules from a directory with no reachable node_modules and deriving real addresses: BIP44 D…, BIP49 S… with its legacy 3… pair, BIP84 dgb1q…, BIP86 dgb1p… taproot, plus a WIF round-trip and the non-DGB WIF rejection.
2026-10-03 13:59:01 +02:00
import { bip32 } from '../deps.js';
feat(theseus/aegis): DGB adapter on @dgb-wallet/{core,psbt} vendored packages Aegis now shares its DGB code with the standalone DigiByte web-wallet at D:\Dev\SilentCode\Digibyte. Address derivation and PSBT construction come from that project's @dgb-wallet/core and @dgb-wallet/psbt packages instead of Aegis-local reimplementations. Any bugfix upstream flows in via a re-vendor of dist/*. - lib/dgb/{core,psbt}/ — vendored dist/ output of the two packages plus a tiny package.json shim marking them as ESM. @dgb-wallet/core's own import specifier "@dgb-wallet/core" inside psbt/*.js is rewritten to "../core/index.js" so the sibling module resolves without a workspace. - New Theseus deps: bitcoinjs-lib, bip32, bip39, @bitcoinerlab/secp256k1, ecpair — the peer deps the vendored packages need. Loaded via api.require in index.js's loadDeps(). - chain-dgb.js is a thin adapter now: BIP32 tree via bip32 + DGB Network object, addresses via core.p2wpkhAddress, tx via psbt.buildPsbt + PSBT.signInput (per-input, since each UTXO's key differs) + psbt.finalizeAndExtract. Runtime backend stays the same — Theseus's lib/electrum.js against the DGB ElectrumX pool. - Verified end-to-end in scratchpad: abandon×11 mnemonic derives dgb1q9gmf0pv8jdymcly6lz6fl7lf6mhslsd72e2jq8 (matches iancoleman.io/bip39 and the previous inline implementation, so no on-chain address change for anyone who was already using Aegis's DGB slot). PSBT build+sign+ finalize on a mock UTXO produces a valid 223-byte witness tx. BIP44 (D…) and BIP49 (S…) address families are implemented in the vendored core but not yet exposed in Aegis's picker — the panel needs an "address family" selector inside the DGB settings block first. Left for a follow-up; today's DGB pick uses BIP84 native SegWit only.
2026-09-07 02:19:44 +02:00
import { digibyte, DGB_COIN_TYPE } from './network.js';
export const PURPOSE_LABEL = {
44: 'BIP44 legacy P2PKH',
49: 'BIP49 P2SH-wrapped SegWit',
84: 'BIP84 native SegWit v0',
86: 'BIP86 Taproot (SegWit v1)',
};
export function rootFromSeed(seed, network = digibyte) {
fix(aegis): DigiByte import failed on every OTA install Reported as "the Aegis DigiByte import error". The vendored @dgb-wallet/core modules under lib/dgb/ imported "bitcoinjs-lib", "bip32", "ecpair", "bip39" and "@bitcoinerlab/secp256k1" as bare specifiers. Node's ESM resolver walks up from the importing file, so that resolves in a dev checkout — where Theseus's node_modules sits above the add-on — and resolves nowhere once Aegis is running from <userData>/extensions/aegis/, which is every OTA install. The import threw, index.js caught it and set dgbCore = null, and any DigiByte import then died in digibyteNetwork() with "DGB adapter not available". So DigiByte worked on a fresh install and disappeared after the first update. Confirmed on this machine: the only node_modules reachable from the installed extension carries bip39 and none of the other four. lib/dgb/deps.js now holds the dependencies, injected by index.js from api.require (which resolves against the app tree) before anything under lib/dgb/ is imported — the same pattern every other lib/*.js in Aegis already uses, and the reason that pattern exists. Consumers read them through accessors rather than capturing them at module scope, so import order is no longer load-bearing: hd.js builds its bip32 on first use and the two initEccLib callers go through a once-only ensureEcc(). Using a DGB module without injection now throws a named error instead of a resolver failure swallowed into a null. Verified by loading the modules from a directory with no reachable node_modules and deriving real addresses: BIP44 D…, BIP49 S… with its legacy 3… pair, BIP84 dgb1q…, BIP86 dgb1p… taproot, plus a WIF round-trip and the non-DGB WIF rejection.
2026-10-03 13:59:01 +02:00
return bip32().fromSeed(seed, network);
feat(theseus/aegis): DGB adapter on @dgb-wallet/{core,psbt} vendored packages Aegis now shares its DGB code with the standalone DigiByte web-wallet at D:\Dev\SilentCode\Digibyte. Address derivation and PSBT construction come from that project's @dgb-wallet/core and @dgb-wallet/psbt packages instead of Aegis-local reimplementations. Any bugfix upstream flows in via a re-vendor of dist/*. - lib/dgb/{core,psbt}/ — vendored dist/ output of the two packages plus a tiny package.json shim marking them as ESM. @dgb-wallet/core's own import specifier "@dgb-wallet/core" inside psbt/*.js is rewritten to "../core/index.js" so the sibling module resolves without a workspace. - New Theseus deps: bitcoinjs-lib, bip32, bip39, @bitcoinerlab/secp256k1, ecpair — the peer deps the vendored packages need. Loaded via api.require in index.js's loadDeps(). - chain-dgb.js is a thin adapter now: BIP32 tree via bip32 + DGB Network object, addresses via core.p2wpkhAddress, tx via psbt.buildPsbt + PSBT.signInput (per-input, since each UTXO's key differs) + psbt.finalizeAndExtract. Runtime backend stays the same — Theseus's lib/electrum.js against the DGB ElectrumX pool. - Verified end-to-end in scratchpad: abandon×11 mnemonic derives dgb1q9gmf0pv8jdymcly6lz6fl7lf6mhslsd72e2jq8 (matches iancoleman.io/bip39 and the previous inline implementation, so no on-chain address change for anyone who was already using Aegis's DGB slot). PSBT build+sign+ finalize on a mock UTXO produces a valid 223-byte witness tx. BIP44 (D…) and BIP49 (S…) address families are implemented in the vendored core but not yet exposed in Aegis's picker — the panel needs an "address family" selector inside the DGB settings block first. Left for a follow-up; today's DGB pick uses BIP84 native SegWit only.
2026-09-07 02:19:44 +02:00
}
// Standard account-level derivation: m/purpose'/coin'/account'.
// account defaults to 0 (the first account).
export function accountNode(root, purpose, account = 0) {
return root.derivePath(`m/${purpose}'/${DGB_COIN_TYPE}'/${account}'`);
}
// Address-level derivation from an account node.
// change = 0 for external (receive) addresses, 1 for internal (change).
export function addressNode(account, change, index) {
return account.derive(change).derive(index);
}
//# sourceMappingURL=hd.js.map