added tweak calculation & incoming UTXO detection#21
Conversation
|
|
||
| // important, need the locking script from previous transaction, and we put it in place of unlocking | ||
| // script so the util that parses pubkeys can find the pubkey | ||
| tx.ins[0].script = txPrevout0.outs[0].script; |
There was a problem hiding this comment.
@junderw a lil guidance please? for this case to get pubkeys from inputs i have to assist it and provide locking script (input is p2tr). but for other testcases i can extract pubkeys from raw tx directly (inputs are p2wpkh). how can i tell by parsing txhex with bitcoinjs if i need to assist it and get prevout tx..?
There was a problem hiding this comment.
You can look at the witness and see if it matches a known P2TR pattern.
The only 3 types that have witness are P2WPKH, P2WSH, and P2TR.
ONLY P2TR will have pubkey info in the previous output's script... so you need to figure out if the witness is the witness of a P2WSH, a P2WPKH, or P2TR.
You could try using the payments API and running the input script and input witness through a P2WPKH payment then a P2WSH payment and if both fail assume it's P2TR and needs extra data.
|
|
||
| static sumPubKeys(pubkeys: Uint8Array[], compressed: boolean = true): Uint8Array | null { | ||
| if (pubkeys.length === 0) return null; | ||
| if (pubkeys.length === 1) return concatUint8Arrays([new Uint8Array([2]), pubkeys[0]]); // not sure about this `2` |
There was a problem hiding this comment.
@junderw i had to add leading 02 here, i guess it has smth to do with compressed pubkeys..? just want to make sure im not missing anything (my computations now match other implementation)
Overtorment
changed the title
|
Looks like you are on the right path to detecting UTXOs when provided with tweaks and able to derive a tweak from transaction inputs. I am not able to follow how tx prev outs script is being handled in the code base. I see a reference to setting it up in silent-payments.test but I think this will be the essence of one of the key challenges in receive wallet scanning.
|
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
|
|
||
| ret.push(u); | ||
| } | ||
| } |
There was a problem hiding this comment.
Bug: UTXO Detection and Key Generation Errors
In detectOurUtxos, the vout variable isn't incremented when iterating tx.outs, causing all detected UTXOs to incorrectly show vout: 0. Separately, the null check for the d variable (from ecc.privateAdd) is placed after d is already used to create an ECPair and WIF. This means if d is falsy, an error will occur before the check can catch it.
| if (result.length === 32) { | ||
| // its x-only...? | ||
| return concatUint8Arrays([new Uint8Array([2]), result]); // not sure about this `2` | ||
| } |
There was a problem hiding this comment.
Bug: Incorrect Public Key Conversion
The sumPubKeys method incorrectly assumes an even y-coordinate when converting 32-byte x-only public keys to compressed format, always prepending 0x02. The correct prefix (0x02 or 0x03) depends on the actual y-coordinate parity, which isn't determined. This can lead to invalid public keys, as the comment "not sure about this 2" suggests.
| // looking for smallest outpoint: | ||
| const outpoints: Array<Uint8Array> = []; | ||
| for (const inn of tx.ins) { | ||
| const txidBuffer = inn.hash;//.reverse(); |
There was a problem hiding this comment.
Bug: Byte Order Mismatch in Tweak Calculation
The computeTweakForTx method uses txids without reversing them, unlike _outpointsHash which explicitly reverses the txid buffer for outpoint hash calculation. This byte order inconsistency can lead to incorrect tweak computations and potential incompatibility with the BIP-352 specification.
3 participants
No description provided.