liamzebedee/tbtc-testnet-starter

requestRedemption with P2PKH fails

Closed this issue · 4 comments

deposit.requestRedemption('SZt6evokJ6FSJMgx43L1uosoQpesh7DBjE') fails with "Tx spends the wrong UTXO". However, it works with a bech32-formatted address, eg. "sb1qr64l8xglvwnvfqgnjjqtdz3v4fw45cq5v7l7dz".

It appears that the uxtoOutpoint, which is a tuple of (txid,voutIndex) is different to the outpoint of the deposit's funding transaction UXTO.

For a RedemptionRequested event:

{
  utxoSize: BN {
    negative: 0,
    words: [ 100000, <1 empty item> ],
    length: 1,
    red: null
  },
  redeemerOutputScript: '0x1976a9148a1458638f3d03af755f3b06f83543e4053949cf88ac',
  requestedFee: BN {
    negative: 0,
    words: [ 150, <1 empty item> ],
    length: 1,
    red: null
  },
  outpoint: '0x20352c0035ebce1ec4b057ba028f2fa4fbc00ea3a851ebf9851637d4d226621100000000',
  digest: '0xb4bbedfe004f276b427da8b6a653c66ad302306f07f0595e90fcc1d8ba95f74a'
}

The outpoint (txid=20352c0035ebce1ec4b057ba028f2fa4fbc00ea3a851ebf9851637d4d2266211,vout=00000000), does not match
either of the funding txid's:

hash: '77ba6cecb01d8f58d0aeb8eeebae29cf9f7e96c59c8b50124850ac28e9e31458',
witnessHash: '77ba6cecb01d8f58d0aeb8eeebae29cf9f7e96c59c8b50124850ac28e9e31458',

funding tx

{
  hash: '77ba6cecb01d8f58d0aeb8eeebae29cf9f7e96c59c8b50124850ac28e9e31458',
  witnessHash: '77ba6cecb01d8f58d0aeb8eeebae29cf9f7e96c59c8b50124850ac28e9e31458',
  size: 220,
  virtualSize: 220,
  value: '49.99999779',
  fee: '0.0',
  rate: '0.0',
  minFee: '0.0000022',
  height: -1,
  block: null,
  time: 0,
  date: null,
  index: -1,
  version: 1,
  inputs: [
    {
      type: 'pubkeyhash',
      subtype: null,
      address: <Address: type=pubkeyhash version=-1 str=STSWSw6xqU4mQf8kFKsrnUBsBnB188Mzam>,
      script: <Script: 0x48 0x3045022100fcd56ef6b6b7e1747026d709219b82864422fe310f7862ffd9d588f40412e6c502207f1b293f45c7aa8bd63084dc898d16d70da6ddabb669a0bbdd2c4692d4cf150501 0x21 0x039f870f1c1d3e0aa95080be9be89e1b2da4770d18e5005c101f95bde297cbe87c>,
      witness: <Witness: >,
      redeem: null,
      sequence: 4294967295,
      prevout: <Outpoint: 7cb2926a93d30bb3a829ff3b0a1672fede6c426f923f3d02cebdcede8bc69406/0>,
      coin: null
    }
  ],
  outputs: [
    {
      type: 'witnesspubkeyhash',
      value: '0.001',
      script: <Script: OP_0 0x14 0x1eabf3991f63a6c481139480b68a2caa5d5a6014>,
      address: <Address: type=witness version=0 str=sb1qr64l8xglvwnvfqgnjjqtdz3v4fw45cq5v7l7dz>
    },
    {
      type: 'witnesspubkeyhash',
      value: '49.99899779',
      script: <Script: OP_0 0x14 0xefb51027b8f6286a4e47ac294220ba7dfbf307f7>,
      address: <Address: type=witness version=0 str=sb1qa763qfac7c5x5nj84s55yg960halxplhpc8lsz>
    }
  ],
  locktime: 0
}

Couple of notes here:

  • Tx spends the wrong UTXO should only happen during provideRedemptionProof, not during requestRedemption---something's fishy here. It's part of redemptionTransactionChecks which is only called in provideRedemptionProof.
  • The comparison outpoint is only set once, during provideBTCFundingProof. This makes me think the most likely issue you're seeing is that submitting redemption proof for one deposit to a different deposit that is also in AWAITING_WITHDRAWAL_PROOF. Another option is that the _txInputVector being submitted to provideRedemptionProof is incorrect for a different reason, client-side.

It could be an issue with redemption script handling, but that seems very unlikely to me because it doesn't look like the failed require touches the redemption script or anything that the redemption script could have had an impact on

Unable to repro this now, I think this was likely a client-side encoding issue. Made some changes to ElectrumHelpers in relation to this issue. 😬