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

nc50lc

legendary

Activity: 2534

Merit: 6080

Self-proclaimed Genius

Quote from: Coding Enthusiast on September 29, 2020, 04:54:26 AM

Quote from: nc50lc on September 29, 2020, 04:09:46 AM

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.

BASE16

member

Activity: 180

Merit: 38

Quote from: Coding Enthusiast on September 29, 2020, 01:33:53 AM

Quote from: BASE16 on September 29, 2020, 01:16:15 AM

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.

Quote

Here is that topic https://bitcointalksearch.org/topic/1-btc-bounty-5192454

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

Quote

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.

Coding Enthusiast

legendary

Activity: 1042

Merit: 2805

Bitcoin and C♯ Enthusiast

Quote from: nc50lc on September 29, 2020, 04:09:46 AM

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.

nc50lc

legendary

Activity: 2534

Merit: 6080

Self-proclaimed Genius

Quote from: Coding Enthusiast on September 29, 2020, 02:07:32 AM

Quote from: nc50lc on September 29, 2020, 01:47:01 AM

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

legendary

Activity: 1042

Merit: 2805

Bitcoin and C♯ Enthusiast

Quote from: nc50lc on September 29, 2020, 01:47:01 AM

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.

Quote from: nc50lc on September 29, 2020, 01:47:01 AM

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

legendary

Activity: 2534

Merit: 6080

Self-proclaimed Genius

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

legendary

Activity: 1042

Merit: 2805

Bitcoin and C♯ Enthusiast

Quote from: BASE16 on September 29, 2020, 01:16:15 AM

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.

Quote

Here is that topic https://bitcointalksearch.org/topic/1-btc-bounty-5192454

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

Quote

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.

BASE16

member

Activity: 180

Merit: 38

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

Here is that topic https://bitcointalksearch.org/topic/1-btc-bounty-5192454

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

Coding Enthusiast

legendary

Activity: 1042

Merit: 2805

Bitcoin and C♯ 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 OP_EqualVerify OP_CheckSig"
}
],
"WitnessList": [
"PushData<3044022009c9dca57c6e4212f471169c9c89c6d5e2ef570aa9a48b55dc2dfe4f13c9f0c202205cce77d15a383b29c45deb307cd60bcc848cfd98c52778a9c0c6699390f6889401>
PushData<04576e65bd864ff1dca1116901833d432e1bc096e0a0f037f57cd0a09e9d3f96b3a88c3a627d3f9a4dfab5fff1d0dfcf03a68411722aed8e05cb3850652b4571ee>"
],
"LockTime": "0"
}

Topic: Spending P2SH-P2WPKH that used uncompressed pubkey (who needed this?) (Read 283 times)