Topic: Confusion Surrounding Unusual Bitcoin Nonstandard Transactions in Block 831489 (Read 266 times)

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://bitcointalksearch.org/topic/m.52740519

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

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.

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.

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.

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!

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.

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.

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).

That explains how they got transactions paying 1 sat/vbyte and 0 sat/vbyte in fees confirmed.

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!

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.

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

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.

But how do you explain the possibility of using satoshis that were sent to an empty address? This is the topic I can't figure out.

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.

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.

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.

Hello,

On February 22nd, 2024, at 01:00:37, block 831489 was mined, containing several interesting transactions that I am struggling to comprehend.

Firstly, there is transaction (txid) 60e00d2ddf8990f02c6dc41d0d068e4514ae4838f3af3334557a712e1a00ab52, which appears to have sent some satoshis to an undefined destination as no address details are provided. I suspect these satoshis were burnt.

However, another transaction (txid) 65f8ac99b7167283abc5cef4dcedd82f6e86cc6e6ec9c266990d42c1d2357f55, also included in block 831489, contains vins classified as "Unknown," which seem to reference the same satoshis that, as far as I understand, should have been burnt.

I cannot comprehend how it is possible to create a transaction where the inputs (vins) point to vouts with incorrect addresses. It appears as though the satoshis were somehow retrieved from nowhere. There must be some aspect of this situation that I am failing to grasp, explaining how this anomaly occurred.

Please provide assistance!

Thank you.