It will also be rejected by blockexplorers with an error (except from blockcypher but it wont propagate):

Here's an example on mainnet:

Broadcast on blockstream - error:


Broadcast on blockchair - error:


Broadcast on blockcypher - didn't propagate well because it's non-standard:

sign up on GitHub then open a new issue requesting a new feature[1] and in there ask for addition of an easy option to enable relaying and mining non-standard P2SH-P2WPKH transactions that use uncompressed public keys.
[1] https://github.com/bitcoin/bitcoin/issues/new?assignees=&labels=Feature&template=feature_request.md&title=

It's unrealistic to ask for changes to help a single person but if the change required seems to be small, it's tempting to ask 'why not?'. Perhaps it's not yet small enough at current price and block reward levels.

Anyone who's making a new product is also unlikely to be using uncompressed keys in 2020 anyway.

I guess they don't want to risk somehow losing their block reward over this. But: are you in a hurry? Current block reward is 6.25 BTC, in 12 years it's going to be less than you're willing to offer as fee.

What's stopping you from creating and posting that transaction already? Just make sure you don't lose access to it's destination address if it's mined years in the future.

Someone did this in tesnet: https://bitcointalk.org/index.php?topic=5278860.0

I am in search of a pool looking for free money.

he has already done that in a much better way which is to place the reward as a high transaction fee. the 0.27 bitcoin is currently worth nearly $2500 which he could increase in the same manner (bumping the fee).
if a miner wanted to accept the offer they could just include the transaction in their next block they mine and claim its fee. others that aren't miners can't do anything about it.

bitcoin core developers don't own the right to developing bitcoin! and they dictate what other people hash to get their scripts. there has been a lot of cases where people simple hash a wrong encoded public key, hash a broken redeem script,... and end up with unspendable coins. at least the OP's case is just a non-standard case not invalid one.

I'll bump my offer up to 0.5 BTC for any pool who can mine it.

if you really want to give such a big reward then maybe you should create an additional transaction and put the entire 1 bitcoin reward in that new transaction itself instead of the current smaller reward of 0.27 bitcoin that the tx in your first post offers.

Well, as far as I can see, there's no way to get getblocktemplate to return a transaction of your choice that's not in the mempool.

... and as I already pointed out above, core bitcoind won't accept the transaction to put it into the mempool without a code change.

So the only possible way I see, related to your comment, is for the pool code to add it directly into the transactions after getblocktemplate, and thus into the "submitblock"
Which means either the pool already allows putting random transactions into their blocks not already known on the network, so those pools "might" consider it and ignore the risks I stated before, or they'd have to change their work generator to allow that.

So it's still back to changing code for any pool that doesn't already allow this, and the risks I already mentioned for any pool that does allow it, or do change some code to allow it.

I'm glad you posted that, when I saw what kano posted I thought I was missing something obvious.

@leventturksoy I am going to poke the pool ops who at least gave some response before to see what is up. They both said look into it then went dark. Odd that there was not even a "no it can't be done" or "yes it can be but we will not do it" response.
It might actually be easier to get this done after the May halving. The .277 fee is going to be much bigger fee percentage wise then. (Ignoring the rest of the reward you are offering)

-Dave

What you are actually asking for here is some pool to change their bitcoind code to allow the transaction.
It may be a minor change, but it is still a change.

The replies you have from core members are already dodgy at best.
Saying "It's allowed but core wont allow it" is pointless since it just means there's the risk of losing a block if any large pools won't accept it in a block if their rules didn't follow this ambiguous definition correctly:
a transaction that IS allowed in a block but NOT allowed to be created

Comments like "It was a wish" and "but there was a concern" are, to be blunt, absolutely ridiculous when it comes to coding.
They've enforced it in the transaction code anyway, so it's pointless.

#error code: -26
#error message:
#non-mandatory-script-verify-flag (Using non-compressed keys in segwit) (code 64)

Other pools may or may not accept a block with this transaction in it, since it is inconsistent about the rules accepting things:
Create "No" Block "Yes"

The sending bitcoins haven't been spent, so the source still has the bitcoins and the transaction CLEARLY does not exist on the network.
c842420807d44d8214509bdffc30366416ebfe033c26b8cdc3b0713cfa3846b6

So you need (them) to send it again to a "valid" address
If the bitcoins are sourced from someone else - then they have effectively stolen them from you and they can spend them at any time they choose using a different transaction.
If they are sourced from your wallet, just create a new transaction.