Examples of transactions that got accepted in the Mempool but not in a block

[RoxxR]

Note: this is a question loosely related to the « intentionally slow » discussion.

Are there any documented examples (in current or past versions of bitcoin) of non-standard transactions that got accepted in the Mempool but fail to get included in a block because they
break some rules?

And how does the mempool get rid of such transactions ?
Is there a protocol timeout after which they expire, to avoid being spammed?

[1714876729]

1714876729

[BlackHatCoiner]

but fail to get included in a block because they
break some rules?

Any transaction that doesn't comply with the consensus rules doesn't get into the mempool. It's simply dumped immediately. I believe you meant transactions that were valid, but were dumped after a certain period from each mempool. I don't think there's a way to verify that, but there should be some.

And how does the mempool get rid of such transactions ?

Each node has time limit for each transaction that is held in memory. The default value is around 2 weeks, but it can change from the configuration file. Theoretically, a node can decide to never dump unconfirmed transactions.

Is there a protocol timeout after which they expire, to avoid being spammed?

As I said, after about 2 weeks.


Note that mempool isn't the same to everybody. Each node can have their own mempool, based on the order of the transactions they've received and the configuration they're run upon.

[garlonicon]

I don't think there's a way to verify that, but there should be some.

You can get them if you set your minimal transaction fees to zero and if you will be lucky enough to connect to such node (or find a path of connections, where all nodes will relay such transactions). The same with negative fees and any other "now-invalid-but-could-be-extended" transactions.

Theoretically, a node can decide to never dump unconfirmed transactions.

Exactly, but keeping for example 300 MB limit is quite useful, because if there is no limit, then malicious nodes can broadcast their spam for free.

Note that mempool isn't the same to everybody.

That's also important, you can always have some unique transactions in store and relay (or include into blocks) under some conditions.

Note: this is a question loosely related to the « intentionally slow » discussion.

Still unconfirmed, so I guess negative fees are even better way to do this than zero fees. Also, it is a nice way to be paid and accumulate dust at the same time, then the buyer can handle that cost, so only one transaction is needed, instead of two.

[NeuroticFish]

Note: this is a question loosely related to the « intentionally slow » discussion.

Are there any documented examples (in current or past versions of bitcoin) of non-standard transactions that got accepted in the Mempool but fail to get included in a block because they
break some rules?

And how does the mempool get rid of such transactions ?
Is there a protocol timeout after which they expire, to avoid being spammed?

Since each node has its own mempool, it's not really relevant what is non-standard in a few mempools. What is relevant is what's in mining pool mempools.
And I expect that they are careful to not allow there anything that could make them lose a block because of something non-standard (and wrong).



There was not too long ago a thread - but I just cannot find it now - somebody needed a non-standard transaction mined, he even offered some nice money, but it took *very* long time (at least months) until he managed to convince people that his transaction is correct and there's no risk in including his transaction into a block, and also to find a miner willing to "risk" it. Maybe somebody can find more. However, I don't think that the transaction was sitting in mempools, I think that was not even accepted...

[n0nce]

There was not too long ago a thread - but I just cannot find it now - somebody needed a non-standard transaction mined, he even offered some nice money, but it took *very* long time (at least months) until he managed to convince people that his transaction is correct and there's no risk in including his transaction into a block, and also to find a miner willing to "risk" it. Maybe somebody can find more. However, I don't think that the transaction was sitting in mempools, I think that was not even accepted...

Yeah, for this type of stuff you'll be best off sending it directly to the mining pools. Some even have (or had in the past) a tool / way to submit it via a web form.

As to the OP: the only transactions that actually got into 'standard' mempools, were propagated via gossip and reached miners, but were not mined, will be standard transactions with simply too low fee rates in times of high blockchain utilization.


Imagine submitting a transaction with 1 or 2sat/vB on 1st of December 2017. Once the mempool size went over 300MB, many nodes might have deleted it due to the standard 300MB limit. Jochen Hoenicke's node seems to have a very high limit so that the transaction was not dropped (otherwise we'd see a 'cap' at 300MB mark), however we can safely assume that he could have been the only node holding on to it.

[PrimeNumber7]

Are there any documented examples (in current or past versions of bitcoin) of non-standard transactions that got accepted in the Mempool but fail to get included in a block because they
break some rules?

As NeuroticFish pointed out, there is no "the" mempool. Each node has its own mempool, along with its own rules for accepting transactions. Some nodes will not relay certain transactions that follow consensus rules, but are non-standard, while others will relay those same transactions.

And how does the mempool get rid of such transactions ?
Is there a protocol timeout after which they expire, to avoid being spammed?

I assume you are referring to transactions that have a sufficiently high fee that would normally result in the transaction getting confirmed. To my knowledge, miners will generally confirm a transaction provided it has a sufficiently large fee, and follows consensus rules.

On occasion, miners may confirm a transaction that has a lower fee than a competing transaction that has been propagated. This is typically due to the time a miner found the block and when the miner became aware of the two transactions.

Due to software misconfiguration, various block explorers have displayed outright invalid transactions that never got confirmed. The miners did not confirm these transactions because they are not valid, not because they are non-standard.

[RoxxR]

Due to software misconfiguration, various block explorers have displayed outright invalid transactions that never got confirmed. The miners did not confirm these transactions because they are not valid, not because they are non-standard.

Interesting! Any specific examples of such invalid transactions? Or how to construct one to test the outcome (ad detect possible software misconfigurations in block explorers)?

[PrimeNumber7]

Due to software misconfiguration, various block explorers have displayed outright invalid transactions that never got confirmed. The miners did not confirm these transactions because they are not valid, not because they are non-standard.

Interesting! Any specific examples of such invalid transactions? Or how to construct one to test the outcome (ad detect possible software misconfigurations in block explorers)?

Blockchain.com (at the time, I believe they were blockchain.info) has in the past, inadvertently accepted invalid transactions. I don't remember exactly how their software was tricked. IIRC, people had submitted the invalid transactions to an interface on blockchain.info's website.

If you want to test if a particular block explorer will accept an invalid transaction, you can submit a transaction that does not follow the consensus rules to the block explorer and see if the transaction is displayed on the block explorer. A block explorer is not going to accept every invalid transaction if their software is misconfigured unless they have done something horribly wrong.

[garlonicon]

Any specific examples of such invalid transactions?

Of course. For example, by using https://live.blockcypher.com/btc-testnet/pushtx/ I made some invalid transactions that were accepted by their block explorer. I don't know if it is now fixed, but they had many missing things, for example they accepted a transaction with OP_RETURN that was too small and had only 64 bytes in size. They even displayed over 50% mining confidence, but after one hour or so, that transaction vanished completely, and I could push some completely different 64-byte transaction, spending the same coins to a different OP_RETURN.

[pooya87]

I made some invalid transactions that were accepted by their block explorer. ~ for example they accepted a transaction with OP_RETURN that was too small and had only 64 bytes in size.

Having a small size is not against the consensus rules. There is only a standard rule that rejects 64-byte transactions if I'm not mistaken.

[garlonicon]

Other "push-transaction-to-testnet" pages:

Code:

sendrawtransaction "02000000000101fb4d9857e1951bd1baac29ef9d4609af5573a89bbfc29767fd45726c8e022c310000000000fdffffff01281d010000000000015102473044022067fe462104f7d55b5e1f72ad50e722241662350d34d47afa25909d4c49a9d2fa02207d0442d0e790767d22d12d19296d4d8329e472d3d417c1110fcacf70f215770301210260d31c40d9f8c07fd4f455818bc1dcc47dd40410dca61379fb1e60beae453d8a00000000"
sendrawtransaction RPC error: {"code":-26,"message":"tx-size-small"}

Their explorer after pushing: https://live.blockcypher.com/btc-testnet/tx/cdb563743322c8944ac496a04badd60fbd4e10ec9a335a108fec84a9af6501cb/
(if it vanished in the meantime, you can try again and get the same result, if it is not yet fixed)

In testnet3, many non-standard transactions are broadcasted, I wonder why this one is not. I checked on regtest and yes, this kind of transaction is valid, when included into a block, so you are right that it is only non-standard, not invalid.

[pooya87]

That's not the smallest transaction you could make by far (it still has a signature in its witness). The smallest you can make is when you design the scripts in a way that you skip the need for any kind of spending script. Like this which is 61 bytes. I believe you should be able to shrink it by 1 more byte if you set the pubscript to empty too.

[garlonicon]

That's not the smallest transaction you could make by far (it still has a signature in its witness).

I know, it was just a setup for such transaction and even that is too small to be broadcasted. To spend my output, the input script could be empty, because the output is just OP_TRUE. And then, the output could contain nothing more than OP_RETURN. It would take 60-something bytes, so could be easily adjusted to have 64-bytes, then it may be possible to attack some SPV nodes, that's why small transactions should not be used, just to avoid "transaction-and-merkle-proof" attack or "transaction-and-block-header" attack.

[HCP]

Blockchain.com (at the time, I believe they were blockchain.info) has in the past, inadvertently accepted invalid transactions. I don't remember exactly how their software was tricked. IIRC, people had submitted the invalid transactions to an interface on blockchain.info's website.

Sounds like something that ol' mate "amaclin" did once upon a time with his "bitcoin doubler" escapades... 

It seemed they were able to get a large number of "non-standard" transactions showing on blockchain.info as it was called at the time. (refer: https://bitcointalk.org/index.php?topic=1356143.msg13804131#msg13804131)

[PrimeNumber7]

Blockchain.com (at the time, I believe they were blockchain.info) has in the past, inadvertently accepted invalid transactions. I don't remember exactly how their software was tricked. IIRC, people had submitted the invalid transactions to an interface on blockchain.info's website.

Sounds like something that ol' mate "amaclin" did once upon a time with his "bitcoin doubler" escapades... 

It seemed they were able to get a large number of "non-standard" transactions showing on blockchain.info as it was called at the time. (refer: https://bitcointalk.org/index.php?topic=1356143.msg13804131#msg13804131)

Yes, that is one example of what I was referring to. I am fairly confident that blockchain.info (at the time, now .com) accepted non-standard transactions that other nodes would reject in other cases as well.

[buwaytress]

You can get them if you set your minimal transaction fees to zero and if you will be lucky enough to connect to such node (or find a path of connections, where all nodes will relay such transactions). The same with negative fees and any other "now-invalid-but-could-be-extended" transactions.

I think this could have happened several years ago, Viabtc (I think) had or has a paid acceleration service. They'd take those zero-fee txs and add in into a block, for a fee.

Essentially, you're still paying them a fee. This was 2017/18, I still remember myself making some 0-fee txs but pretty sure this was before that became non-standard (if I use the term correctly). Wasn't really ever a power user to understand much back then.

Myself never successfully got a tx dumped from mempool back when I did for-fun testing of min txs to see how long they'd take to finally confirm.