Certain types of transactions seem vaporized

[staccDOTsol]

hi @t-nelson

Problem

Abt two months ago I went and tried to cash out on a vuln I had mistakenly introduced into Candy Machine a couple years ago. My withdraw_funds function had a lack of checks and balances, and one attack vector had included messing with the candy config's authority and fake valid auth using an ages-old solana bug with passing seed authority via known bumps in CPI, further reading: #21409

Anywho, I tried to get some cash desperate in homelessness, ended up doing it successfully on devnet and ended up with a number of successful tx, i.e.:

5GwvNXcCVoCkwFcYQtJNshjyqvHsiNCbFV3w9HAdGmc8KPZ1JZu4NruuJpyrp7aGTbz8naoGHra4Z3AiCZyyBde5

among many others

Later that night this same code was unsuccessful on main net, suspect metaplex patched this vector in a later main net push.

when I checked about two months these devnet tx didn't exist on solana explorer, solana cli, solscan or solana.fm. they did exist on helius xray, and then I made a little angry tweet - I woke up the next morning and it was missing from xray, too. Tweet since redacted.

Today I mucked around, if you check candy machine v1 on solscan for devnet you find nothing newer than 4 months ago
https://solscan.io/account/cndyAnrLdpjq1Ssp1z8xxDsB8dxe7u4HL5Nxi2K5WXZ?cluster=devnet
run this and you see block times as recent as Oct 11 2023, atow a week ago

curl "https://devnet.helius-rpc.com/?api-key=-f797-49e8-8152-6d2292c21241" -X POST -H "Content-Type: application/json" -d '
                                       {
                                         "jsonrpc": "2.0",
                                         "id": 1,
                                         "method": "getSignaturesForAddress",
                                         "params": [
                                           "cndyAnrLdpjq1Ssp1z8xxDsB8dxe7u4HL5Nxi2K5WXZ",
                                           {
                                             "limit": 1000
                                           }
                                         ]
                                       }
                                     ' | jq  --raw-output '.result[].signature'

Tun the following code

const url = "https://api-devnet.helius.xyz/v0/transactions/?api-key=-f797-49e8-8152-6d2292c21241";
const fetch = require("node-fetch");
const parseTransaction = async () => {
    // slice transactions into groups of 100
    for (let i = 0; i < transactions.length; i += 100) {
        const transactionSlice = transactions.slice(i, i + 100);
        

  const response = await fetch(url, {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      transactions: transactionSlice
    }),
  });

  const data = await response.json();
  console.log("parsed transaction: ", data.map((transaction) => transaction.nativeTransfers.length > 0?
  
  transaction.description == "" ? 
  console.log(transaction) : null 
  :null));
}
};

parseTransaction();

you get this wee lil guy:

{
  description: '',
  type: 'UNKNOWN',
  source: 'CANDY_MACHINE_V1',
  fee: 10000,
  feePayer: '7M1RM6MXU7ezJw5yvG64VCXTZHT5MPPdPUuoiCmTVf6o',
  signature: '4sB56gPoffP13UNk3EZqFLpScTtjcDft1S35kFErxWviD4roNLHUWHfQJJieubBGKqxYifGLNdaKwDVKo6erdbF3',
  slot: 211795270,
  timestamp: 1692197791,
  tokenTransfers: [],
  nativeTransfers: [
    {
      fromUserAccount: '7M1RM6MXU7ezJw5yvG64VCXTZHT5MPPdPUuoiCmTVf6o',
      toUserAccount: 'EF95BXRqSgdkrRxpF79UaPrjuNdZoksHuz9tTnf653CP',
      amount: 2282880
    }
  ],
  accountData: [
    {
      account: '7M1RM6MXU7ezJw5yvG64VCXTZHT5MPPdPUuoiCmTVf6o',
      nativeBalanceChange: -10000,
      tokenBalanceChanges: []
    },
    {
      account: 'EF95BXRqSgdkrRxpF79UaPrjuNdZoksHuz9tTnf653CP',
      nativeBalanceChange: 0,
      tokenBalanceChanges: []
    },
    {
      account: 'ADrvoM8MbWfwojFHXwk9iVpPCTwZXDWG6hNjo7CiEsYE',
      nativeBalanceChange: 0,
      tokenBalanceChanges: []
    },
    {
      account: '32DYZZvnqNVagp573BT3hLyXeEodhSeWSBpRQF7mnrYr',
      nativeBalanceChange: 0,
      tokenBalanceChanges: []
    },
    {
      account: '3h5Dw2sVuMvkBCszhDHzy9BTvvGh98jqRNMkLp1YQLfN',
      nativeBalanceChange: 0,
      tokenBalanceChanges: []
    },
    {
      account: 'cndyAnrLdpjq1Ssp1z8xxDsB8dxe7u4HL5Nxi2K5WXZ',
      nativeBalanceChange: 0,
      tokenBalanceChanges: []
    },
    {
      account: '11111111111111111111111111111111',
      nativeBalanceChange: 0,
      tokenBalanceChanges: []
    },
    {
      account: 'SysvarRent111111111111111111111111111111111',
      nativeBalanceChange: 0,
      tokenBalanceChanges: []
    },
    {
      account: 'ComputeBudget111111111111111111111111111111',
      nativeBalanceChange: 0,
      tokenBalanceChanges: []
    },
    {
      account: '4TsDWnZTihyABRBzHjw4wGJ8jcacCzaf9ZMm9a6wxD12',
      nativeBalanceChange: 0,
      tokenBalanceChanges: []
    }
  ],
  transactionError: { InstructionError: [ 1, [Object] ] },
  instructions: [
    {
      accounts: [],
      data: 'E7NZHW',
      programId: 'ComputeBudget111111111111111111111111111111',
      innerInstructions: []
    },
    {
      accounts: [Array],
      data: '2wWy8znBn48EqEjiy4jqoJ5TYQKQ8RzLoLNVoPKNnL7pjXuajLdsVEBMqTvYKdReJ2RMBNnhegDgk6wkN2EBdXoXC7Ch8WpBGk3GZmZyo4XKrc32mSGWKrG4F',
      programId: '4TsDWnZTihyABRBzHjw4wGJ8jcacCzaf9ZMm9a6wxD12',
      innerInstructions: [Array]
    }
  ],
  events: {}
}

1. this is indeed running on the program I wrote 4TsDWnZTihyABRBzHjw4wGJ8jcacCzaf9ZMm9a6wxD12
2. who does not have any reported tx on devnet explorers, at all
3. you'll see a bunch of the exact same type of tx fail on https://solscan.io/account/4TsDWnZTihyABRBzHjw4wGJ8jcacCzaf9ZMm9a6wxD12 on main net thereafter
4. the above is a candy machine drain on devnet ( I think - the flow of native balance doesn't look right)
5. the sig 4sB56gPoffP13UNk3EZqFLpScTtjcDft1S35kFErxWviD4roNLHUWHfQJJieubBGKqxYifGLNdaKwDVKo6erdbF3 does not exist on solscan.
6. it does presently exist on xray, where it is an odd error that I was sometimes getting on main net, too

8. does not exist on solana.fm
9. does exist in Solana cli
10.

I gather from feedback on the previous security vuln report that this is not a security concern as reputation management doesn't count under the auspices of the definition in the policy, but it does paint a grim picture should it not be addressed.

Why are these nonaligned tx now redacted from nearly every interface? I am fully aware that I am probably uninformed about a process somewhere along the line and this is just the result of my own misinterpretation, but if people can explain this sufficiently then it does kill the vaporizing tx argument (which stems from this kind of behaviour).

Proposed Solution

Explain misinterpretation here more clearly and publicly.

[staccDOTsol]

note: this tx 4sB56gPoffP13UNk3EZqFLpScTtjcDft1S35kFErxWviD4roNLHUWHfQJJieubBGKqxYifGLNdaKwDVKo6erdbF3 exists on both helius main net and devnet.

funny enough it is one of the main net tx that do indeed show on solscan et. al., adding to my confusion and will surely be reason to just follow up with the folks at Helius to see why this tx appears on both main net and devnet.

I still believe this is indicative of a greater issue

I've also never heard of Big Table causing issues with some tx not being saved longer or shorter than others, if anyone can elaborate

[CriesofCarrots]

Could not identify an issue here