Unexistent transactions on successful run of the attoken spawn command.

[buhtignew]

I've run attoken spawn johns_attoken3 mgpiP2Dc5QweKFS55HvRqsWyQ6PMXJCVCk -f 538869 -e 638868 -c n3MtPoPaAREU5GEhAErBPuju83bVog2opz and attoken spawn johns_attoken3 mgpiP2Dc5QweKFS55HvRqsWyQ6PMXJCVCk -f 538869 -e 638868 -c n3MtPoPaAREU5GEhAErBPuju83bVog2opz -d And have produced 0e04a38392b99e0b3b53445b93ece8ad721c8ee7d72b037d1fcc3a2ad8ab4712 and 069ea610b6045bfd18766048374010181bf561caf0b664574db337ac73b076a4 transactions. However I was not able to see those decks in the token list -a output. So I've tried transaction show 0e04a38392b99e0b3b53445b93ece8ad721c8ee7d72b037d1fcc3a2ad8ab4712 -s and transaction show 069ea610b6045bfd18766048374010181bf561caf0b664574db337ac73b076a4 -s and got:

Error: Transaction does not exist or is corrupted.

I've run attoken send_coins mie75nFHrNAHHKfQ141fWfWozdMnaec8mb 1 and pobtoken spawn my3 -f 538869 -e 638869 -c n3MtPoPaAREU5GEhAErBPuju83bVog2opz and these commands have produced regular transactions (65afc44b9ec94ec6ebcd8733817f490f1b58906a1cfcf1142ee86cbd8be294b1 and 5b15a52c08554c2f3859fb274338622d52ce6702e2fcaca73e63ab445f1c29f1).

[d5000]

Indeed these transactions (0e04a38392b99e0b3b53445b93ece8ad721c8ee7d72b037d1fcc3a2ad8ab4712 and 069ea610b6045bfd18766048374010181bf561caf0b664574db337ac73b076a4) are not confirmed, I don't see them. Do you see them in your mempool? (slimcoind getmemorypool)?

If not, then the transactions were probably created but invalid. It would then be helpful if you run the spawn commands again and if the transactions don't confirm, then post the transaction hex strings, so I can see if there is something preventing the transactions from being confirmed.

[buhtignew]

Here is my slimcoind getmemorypool output:

{
    "version" : 1,
    "previousblockhash" : "0000003cb67a96c458a0ea9108db8f94694c51008f37a0a18a026447e5ef3212",
    "transactions" : [
    ],
    "coinbasevalue" : 12210000,
    "coinbaseflags" : "062f503253482f",
    "time" : 1726216711,
    "mintime" : 1726215956,
    "curtime" : 1726216711,
    "bits" : "1e00e932"
}

Here are the transaction hex strings of the above mentioned transactions:

• 0e04a38392b99e0b3b53445b93ece8ad721c8ee7d72b037d1fcc3a2ad8ab4712:

  010000006e82d96603a460a223707ca94cec135d0a2403c8de32ab7eba4207f9b82fd05a2f6b944796020000006b483045022100faa923b9efd27118eaef9f045a2f39599d49d0beed118beb9c18e2fe8533f8ed0220377020bbb1809f631b65490709ab80dc7acb6e6319683ca1898e466d7bce81ce01210222cb84a16ecd0fbb092bd104e3fb0b59db069932a711bfaf7c0c0c7a1b627534ffffffff81ccc41e51155ae6f0a44ab62b538a5930325ed436c589117fb795736c8ac2b1020000006a473044022059a6a665c406508575069b116fd357f37dbf20b549b95d98dede898c23075e5102204c5a0d16d8d78481d4a65a26339d98c26bd1914d55c5b64a8f66e759b5eca60e01210222cb84a16ecd0fbb092bd104e3fb0b59db069932a711bfaf7c0c0c7a1b627534ffffffffb57a896bde89dbaeda56d3a8b59ed3a2114d0a3c5ec723ac7d1c17373e22dcb2020000006b483045022100fd66521375b4a5128d23a68cd2e01a9f84640a26701dd814afc71645662d6cdd02200b789b0ba25d8403057769d1f321378a2acc861c111033ce9e5cf6128373d4f801210222cb84a16ecd0fbb092bd104e3fb0b59db069932a711bfaf7c0c0c7a1b627534ffffffff0310270000000000001976a9141e667ee94ea8e62c63fe59a0269bb3c091c86ca388ac10270000000000003e6a3c0801120e6a6f686e735f6174746f6b656e33180220012a24100240014a140e53ff7bcc1812463cf48185f33cf8ce1de723cb50025894ff2660f5f12000000000000000001976a914ef9bc46b51278e60631ca709fd21bf9d2d0abf1588ac00000000

• 069ea610b6045bfd18766048374010181bf561caf0b664574db337ac73b076a4:

  01000000957fd96603a460a223707ca94cec135d0a2403c8de32ab7eba4207f9b82fd05a2f6b944796020000006b4830450221008f20c9a481c97ff1c41fc28c9ff547881b53c5d1f74c68f7f06707f2dbd2f826022065d4b5772a0b14b6051f5e7cd9f6795252a7d0be4dc7deb46778112ea772619d01210222cb84a16ecd0fbb092bd104e3fb0b59db069932a711bfaf7c0c0c7a1b627534ffffffff81ccc41e51155ae6f0a44ab62b538a5930325ed436c589117fb795736c8ac2b1020000006a473044022017f06597ea37bd4c300b08b09ea17143245ca34c7f779e3914c2be1ae6f6c87e02203d72da03e5e537ec97a71e21a8cf09b1010de06741a8b6bff12f2d84afee867e01210222cb84a16ecd0fbb092bd104e3fb0b59db069932a711bfaf7c0c0c7a1b627534ffffffffb57a896bde89dbaeda56d3a8b59ed3a2114d0a3c5ec723ac7d1c17373e22dcb2020000006a47304402200d24974e9f3b33d992f28dd191eaf09000ea2402ed3024e1a16c4fc30536441602204a51f2dd3a444b2b9632a7e3d13ff09ab64c36f93b8e688ecdb82affd09af91301210222cb84a16ecd0fbb092bd104e3fb0b59db069932a711bfaf7c0c0c7a1b627534ffffffff0310270000000000001976a9141e667ee94ea8e62c63fe59a0269bb3c091c86ca388ac10270000000000003e6a3c0801120e6a6f686e735f6174746f6b656e33180220012a24100240014a140e53ff7bcc1812463cf48185f33cf8ce1de723cb50025894ff2660f5f12000000000000000001976a914ef9bc46b51278e60631ca709fd21bf9d2d0abf1588ac00000000

  _ However I've just run attoken spawn johns_attoken3 mgpiP2Dc5QweKFS55HvRqsWyQ6PMXJCVCk -f 538869 -e 638868 -c n3MtPoPaAREU5GEhAErBPuju83bVog2opz and was able to create a deck so maybe the issue has been solved with the recent upgrade.

[d5000]

I've seen the problem already: Both transactions have an output with a value of 0 SLM. This is not allowed by the protocol.

I will investigate, that looks like a bug.

UPDATE: I could reproduce the bug and the problem seems to be located in the core of pypeerassets. The problem will appear if you have outputs which sum exactly 0.03 coins (often happens when "grabbing" P2TH outputs), which is the exact needed value for the transaction normally, but it will afterwards create an additional output with 0 coins.

[d5000]

Fixed in pypeerassets commit 4d15fb9. The program was creating a change output always, even if the change was zero. This has been modified now in a way that only if the input volume is greater than the outputs + fees, a change output is created.

Steps to reproduce and test the bug:

• Send exactly 0.03 SLM to an address which doesn't contain any coins.
• Change to that address and then spawn an AT or PoB token.

Have pre-tested it, the problem no longer occurred. So it can be closed.

[buhtignew]

I've tested it, seems to work.

The only doubt I have is that the address I've been spawning the tokens from (n3MtPoPaAREU5GEhAErBPuju83bVog2opz) has 3169.874 coins right now and it had enough coins to spawn tokens because I've been able to spawn attokens afterwards, as you can see from the OP.

[d5000]

Yes, the case that 0.03 are taken as an input can also happen if the address has outputs with more coins on it. The PeerAssets coin selection algorithm is quite complex and has several criteria. It can even "grab" coins which are "on other addresses" in your wallet, and so in the deck spawns you posted in this issue that didn't work it "grabbed" P2TH fees from the P2TH addresses.

In the cases I did the two steps I listed in the last post however it worked as expected: the algorithm took exactly these 0.03 coins I had transferred and created a deck spawn transaction from it, with only 2 outputs (P2TH and OP_RETURN), with no additional change output added.

The bug was also quite obvious so testing is not really needed.