Hey everyone,
On February 22nd, 2024, at 01:00:37, block 831489 was mined and it has some pretty odd transactions that I can't wrap my head around.
The first one is transaction (txid) 60e00d2ddf8990f02c6dc41d0d068e4514ae4838f3af3334557a712e1a00ab52. It seems like some satoshis were sent to a destination that isn’t defined, no address info is available. I'm thinking those satoshis were likely burnt.
Then there's another transaction (txid) 65f8ac99b7167283abc5cef4dcedd82f6e86cc6e6ec9c266990d42c1d2357f55, which is also in block 831489. This one has inputs (vins) marked as "Unknown," and it looks like they reference the same satoshis that I assumed were burnt.
I just can't figure out how a transaction can have inputs pointing to outputs with wrong addresses. It feels like those satoshis were somehow pulled back from nowhere. There’s got to be something about this situation that I’m missing, explaining how this weirdness happened.
Can anyone help me out with this?
Thanks a lot.
I looked up both transactions on the Mempool and obviously both of them are not burning transactions. If they were the recipient address will have multiple inputs but zero output.
I believe the first transaction is either a dust related ( probably a dust attacks on several addresses) or probably something related to starting block rewards.
Unlikely. Normal wallets can't send transactions under the dust limit (1 sat), and 1 sat/vbyte isn't enough to get it confirmed. The receiving address format reminds me of Blockchair's interpretation of OP_RETURN, but those can't send funds anymore. That makes me thing it's Taproot-related, but I don't know the details.
You have a nice point because even if those transactions were broadcasted, nodes will definitely just purge it out making the TXID not found on any explorer.
These are Ordinal transactions. For the former, you can see that the transaction exists when you query on the ordinal explorer: https://ordiscan.com/inscription/61847582. You can see that the subsequent transaction that you've referenced is a transfer of this ordinal. Most explorers can't or doesn't really want to deal with ordinals and that's why you don't see any details on this and it just appears to be a weird malformed transaction.
Hey Ranochigo,
Thanks for the clarification regarding ordinal transactions; it provided me with some insight into what they could entail. However, upon further analysis, I compared this particular transaction with others ordinal ones that were transferred, and I noticed that it is the only one with an UNKNOWN address as the source of the satoshis. I apologize for the persistence, but this discrepancy is still confusing me.
Thanks once again for all the support
Addresses don't exist. There are no addresses in bitcoin transactions.
Addresses are an abstraction that we humans use to make it easier to talk about the transfer of control over value using a standard set of locking and unlocking scripts.
Bitcoin transactions use a scripting language to encumber transaction outputs with requirements that must be met for any node to allow those outputs to be used as inputs into a new transaction. There are a standard set of such scripts that have been given names (P2PKH, P2SH, P2WPKH, etc).
Rather than needing to use the name of the script and then the data needed to correctly build the script in every conversation where we are talking about transfering the control over some value, we have created the concept of an "address" which encodes all the necessary details into a single string of letters and numbers. Then the wallet software that we use converts that "address" into the appropriate script for the transaction.
There is nothing in Bitcoin that REQUIRES one of those standard scripts to be used. Anyone can use the scripting language to create any script to accomplish any goal they want when they create a transaction. If the transaction script is not recognized as one of the "standard" ones, some block explorers and wallets will identify that script as being "unknown", others may just show the actual script itself, while still others may choose to create a RIPEMD160 hash of the script and present that as if it were an "address". It's up to the block explorer programmer (or wallet software programmer) to decide how they want to present these non-standard scripts to their users.
As long as someone knows how to satisfy the requirements placed by the "locking" script in the output, they can use that output as an input to a transaction where they want to "spend" that value. It doesn't need to be a "valid address", it just needs to be an "unlocking" script that presents the correct data in the correct format.
FWIW the malicious mining pool known as MARA Pool that was involved in censoring transactions is the pool that accepted these non-standard spam transactions that are now going to effectively bloat the UTXO set forever!
Can confirm that parsing the witness data of each transaction input is a very painful and needlessly hard process that is almost never worth the amount of system resources that it consumes. I usually just strip witness data out of all of the transactions I process nowadays.
MARA meaning the Marathon mining group based in USA?
There is a solution I think I have wrote before which is to have an option to prune the UTXO set to exclude unspendable outputs (not provably unspendable outputs, but using a filter I guess).
Yeah, MARA is that pool.
I think that these outputs aren't technically unspendable (2nd tx), because you can see that they are spendable, just non-standard. Probably would face too much pushback to purge UTXOs, instead of defining a new standard for this. It's just too bad.
All I know is mempool.space calls it MARA Pool. I don't know what to make of this: they filled most of this block with low-fee spam transactions.
OP showed 1 sat dust inputs being used in transactions again. If you prune them from your UTXO set, you can't verify that transaction and get stuck at that block.
The correct solution to get rid of these dust spam with non-standard outputs that "anyone can spend" (eg. OP_NOP OP_NOP ... OP_1) is for a mining pool to just create the transaction spending them and sending the sum to their own address, maybe as fee to collect in coinbase tx.
Something like this garbage that F2Pool cleaned up.
Here they clear a lot of non-standard outputs with 0 values/amount and create a provably pruneable output (OP_RETURN) effectively purging all of them from UTXO set. That is 0 in, 0 out, 0 fee!
That's 9 years ago. Nowadays "normal" mining pools are more scared about doing stuff like this!
Correct, but the fact that these exists is probably facilitated by another pool so it'll be more of a cat and mouse game. I don't think mining pools would be particularly inclined to sacrifice their revenue from fees in this manner, it's expensive and doesn't do much for them. In addition, they would have to answer to their miners as well, not too popular. It's a real problem that can possibly only be solved at a protocol level.
There was also this transaction which contained 1000 single satoshi outputs in that same block.
https://mempool.space/tx/3c2284977f93a1395f1b0e06fd3a843c3e8ce2277a0d770781f6655d1aadfe13
These transactions were due to Marathon testing out their new service called Slipstream, where users can directly submit non-standard transactions that would otherwise not be mined.
This might help people whose Bitcoin stuck due to non-standard address (e.g. SegWit address with uncompressed keys) or weird spending condition. Although in practice, i expect it'll be mainly used to include arbitrary data.
Can see this service being used for people who wind up with issues like this due to problems with TXs due to programmer error.
https://bitcointalk.org/index.php?topic=5192454.msg52740519#msg52740519
Sadly there have been a bunch of problems like this over the years from different wallets / apps . And for some reason no pool operator until now has wanted to provide a service like this.
-Dave