Spending P2SH-P2WPKH that used uncompressed pubkey (who needed this?)

[Coding Enthusiast]

I remember a while ago there was a topic on this forum from someone who had a large amount of bitcoin stuck in a P2SH-P2WPKH output that used an uncompressed public key and since it is non-standard it wasn't being relayed or mined and miners they contacted were also worried about their block being rejected if they included this transaction.
I can't find the topic though.

Well here is an example block with such a transaction on TestNet on block #1836615 (https://tbtc.bitaps.com/1836615) which I just mined. Maybe this can help.
The transaction is the only tx in the block apart from coinbase with hash= 134112254a1d0d687af0c4aa7185e62bbacf191165369d0150206f6c369ca417
You can see the uncompressed public key in second witness item (the second PushData):

Code:

{
  "Version": 1,
  "TxInList": [
    {
      "Outpoint": {
        "TxHash": "6b16690cdc1f4f8d6a07dd241cc8526bb075b9ad62f3d9d9a9fcc710ba94db16",
        "Index": 0
      },
      "SigScript": "PushData<0014ae456b5f88b76d858802da6996e05d5c4f084314>",
      "Sequence": 4294967295
    }
  ],
  "TxOutList": [
    {
      "Amount": 999750,
      "PubScript": "OP_DUP OP_HASH160 PushData<db1c22d11851f82e3e463f3b33c83400b15e6ab4> OP_EqualVerify OP_CheckSig"
    }
  ],
  "WitnessList": [
    "PushData<3044022009c9dca57c6e4212f471169c9c89c6d5e2ef570aa9a48b55dc2dfe4f13c9f0c202205cce77d15a383b29c45deb307cd60bcc848cfd98c52778a9c0c6699390f6889401>
     PushData<04576e65bd864ff1dca1116901833d432e1bc096e0a0f037f57cd0a09e9d3f96b3a88c3a627d3f9a4dfab5fff1d0dfcf03a68411722aed8e05cb3850652b4571ee>"
  ],
  "LockTime": "0"
}

[BASE16]

Yes it was about the other miners / nodes rejecting the block because it contained non standard.

Here is that topic https://bitcointalk.org/index.php?topic=5192454.0

But there are numerous people that have the same type of problem and there are a lot of coins that are unspendable.

[Coding Enthusiast]

Yes it was about the other miners / nodes rejecting the block because it contained non standard.

They will never reject a "block" because blocks do not follow standard rules. However, the nodes reject non-standard transactions because mempool enforces standard rules.

Here is that topic https://bitcointalk.org/index.php?topic=5192454.0

Yes, that was the topic. Thanks. Since the output is still unspent I sent the starter a PM.

But there are numerous people that have the same type of problem and there are a lot of coins that are unspendable.

Could you show me some of the cases, I often visit bitcointalk, reddit and stackexchange and this is the only case I've seen so far.

[nc50lc]

It's easier to do in tesnet because you can easily set a configuration to accept non-standard transactions to your mempool.
While in mainnet, the config wont work.

IDK if there're other ways aside from changing the code but if there is, someone should point it to kano and other pool operators.
Here's kano's decisive post to reject the bounty: /index.php?topic=5192454.msg53747843#msg53747843

[Coding Enthusiast]

It's easier to do in tesnet because you can easily set a configuration to accept non-standard transactions to your mempool.
While in mainnet, the config wont work.

Actually it was not possible in TestNet either. I've tried it and the transaction was rejected, hence mining the block myself.

IDK if there're other ways aside from changing the code but if there is

The problem is this flag: SCRIPT_VERIFY_WITNESS_PUBKEYTYPE
The way I understand bitcoin core's code is that it doesn't disable or change flags on different networks, it just skips the IsStandard check in validation.cpp on TestNet while the non-standard flag is still used for verification of scripts eg. in interpretter.cpp and rejects this non-standard script. This flag however is not present while verifying a block since it is not a consensus rule.
If I'm correct, removing this single line should fix it for accepting the transactions in mempool, or just not use standard flags in any other way that core allows it.

[nc50lc]

It's easier to do in tesnet because you can easily set a configuration to accept non-standard transactions to your mempool.
While in mainnet, the config wont work.

Actually it was not possible in TestNet either. I've tried it and the transaction was rejected, hence mining the block myself.

Have you tried adding: acceptnonstdtxn=1 to your bitcoin.conf file before sending the transaction?
AFAIK, that should work in testnet/regtest and will allow some non-standard txns to your mempool (what's not clear is which ones).

[Coding Enthusiast]

Have you tried adding: acceptnonstdtxn=1 to your bitcoin.conf file before sending the transaction?
AFAIK, that should work in testnet/regtest and will allow some non-standard txns to your mempool (what's not clear is which ones).

I don't run a synced core but it wouldn't have mattered even if I did, the other nodes on the network are rejecting this specific type of non-standard transaction so it won't propagate. Besides I'm already sending them the transaction in a tx message which is no different than what forcing it into your local mempool in core would do.

[BASE16]

Yes it was about the other miners / nodes rejecting the block because it contained non standard.

They will never reject a "block" because blocks do not follow standard rules. However, the nodes reject non-standard transactions because mempool enforces standard rules.

Here is that topic https://bitcointalk.org/index.php?topic=5192454.0

Yes, that was the topic. Thanks. Since the output is still unspent I sent the starter a PM.

But there are numerous people that have the same type of problem and there are a lot of coins that are unspendable.

Could you show me some of the cases, I often visit bitcointalk, reddit and stackexchange and this is the only case I've seen so far.

There are plenty if you invest the time to look for them.
I am not going to look them all up for you but i know that there are many unspendable coins because they used uncompressed pubkeys.

[nc50lc]

Have you tried adding: acceptnonstdtxn=1 to your bitcoin.conf file before sending the transaction?
AFAIK, that should work in testnet/regtest and will allow some non-standard txns to your mempool (what's not clear is which ones).

I don't run a synced core but it wouldn't have mattered even if I did, the other nodes on the network are rejecting this specific type of non-standard transaction so it won't propagate. Besides I'm already sending them the transaction in a tx message which is no different than what forcing it into your local mempool in core would do.

Ah, so it was mined the same way as the block on the final post of your other thread: Is there any online (web) tool where I could broadcast a new block I mined?
I though you've done it the same way a pool operator or solo miner does: a full node and a miner.

Unfortunately, most of them don't like the idea of changing a code in either their mining pool software nor Bitcoin core to include those non-standard SegWit Txns.