[~1 BTC Bounty]

[pooya87]

I still don't see the point, unless it (accepting non-standard script) is enabled by default. Bitcoin Core already have some option such as changing minrelayfee, but i almost never hear people intentionally change it.

the point would be for a miner to not have to modify the code themselves, instead they just change an option (a variable at runtime similar as mintxrelayfee, addnode, etc.) to accept this particular case which is valid but is being rejected by their mempool.

[DaveF]

Maybe the offer could become more appealing after a couple halvings. OP could also try raising the issue on github, hopefully Bitcoin Core could be updated to remedy this problem.

It's known and been discussed:

It said that it's not against the consensus rues but the transaction was indeed non-standard that's why nodes are rejecting it.

that is really messed up! every single documentation that i have ever seen has always said "it must not be compressed or it will not be mined". now i went back and checked the out, they are all are ambiguous about it!
take BIP143 for example:
https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#restrictions-on-public-key-type

As a default policy, only compressed public keys are accepted in P2WPKH and P2WSH. Each public key passed to a sigop inside version 0 witness program must be a compressed key: the first byte MUST be either 0x02 or 0x03, and the size MUST be 33 bytes. Transactions that break this rule will not be relayed or mined by default.

from bitcoincore.com: https://bitcoincore.org/en/segwit_wallet_dev/#creation-of-p2sh-p2wpkh-address

P2SH-P2WPKH uses the same public key format as P2PKH, with a very important exception: the public key used in P2SH-P2WPKH MUST be compressed, i.e. 33 bytes in size, and starting with a 0x02 or 0x03. Using any other format such as uncompressed public key may lead to irrevocable fund loss.

the orange parts are the ambiguity! why did they do this?!

It's not at all ambiguous, it states it exactly how it is.

It was the wish with segwit to prohibit the use of uncompressed keys. But there was a concern that problem's like OP's would arise from incompetent buggy software-- potentially involving really large funds losses.  In an abundance of caution these the rule was made initially standardness-only.  It has turned out to be less of an issue than had been feared (the OP's is the only sizable case I've heard of, at least).

The TX is valid. By default core will not accept it because of the mining fee. And it will not relayed.
But with 1 small tweak it will be accepted into the memepool of a node.
I have it sitting in my solo lottery node and on the very very very very [millions more very] small chance it hits the tx will be done.

Most of the bigger pools the OP contacted do not want to either alter their software / configuration because they are worried that it might cause other issues causing the block to be orphaned. Or, (AFAIK) they just never responded.

I personally figured that after the 12.5 to 6.25 halving that some pool would be interested. I was wrong.
Still the OP should keep asking pools for help. Sooner or later one of them might want to take a risk for an extra $10k

-Dave

[leventturksoy]

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

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

With such little imposed risk, I'm finding fault in seeing why my transaction has not been mined yet. I can create a tx with a 1 BTC fee if you reading this now would like to inquire about it.

[malevolent]

It's known and been discussed:

i seriously doubt anything about bitcoin core is going to change unless there is an overwhelming number of similar cases that have lost their coins to this type of non-standard scripts.
although i think the change itself is very easy (possibly it needs changing one line of code), the addition of an option to let the user enable/disable through command line may not be.

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.

[2double0]

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.

Can a group of miners be formed if they are interested in doing this not for money but to help out the guy stuck in the transaction while the amount of BTC could be worth 5-10 years of spends for him? I know that this will be against the protocol because some rules may be broken, but can't this happen for ever? Or can this guy be provided help with a soft fork?

[LoyceV]

With such little imposed risk, I'm finding fault in seeing why my transaction has not been mined yet. I can create a tx with a 1 BTC fee if you reading this now would like to inquire about it.

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.

[leventturksoy]

With such little imposed risk, I'm finding fault in seeing why my transaction has not been mined yet. I can create a tx with a 1 BTC fee if you reading this now would like to inquire about it.

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.

I understand, however the transaction went smooth in testnet: https://bitcointalk.org/index.php?topic=5278860.0

It's up to the miner to measure and decide the risk of replicating this on mainnet. It's not preferable to wait 12 years, and things can change by then.

[leventturksoy]

It's known and been discussed:

i seriously doubt anything about bitcoin core is going to change unless there is an overwhelming number of similar cases that have lost their coins to this type of non-standard scripts.
although i think the change itself is very easy (possibly it needs changing one line of code), the addition of an option to let the user enable/disable through command line may not be.

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 think the change required is very very small, how can I request the change to be made?

[pooya87]

~
I think the change required is very very small, how can I request the change to be made?

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=

[Timelord2067]

TL;DR

Why not zap wallet and resend with a lower TX fee?  Scrolling down the thread you keep saying you're going to increase the fees, why not lower the TX fee paid to one satoshi?

I get this:

Blue Wallet

Well... if you have a blue wallet, then you have a mnemonic seed that you can user to recreate the wallet via another service - possibly one that enables you to export the priv key of the wallet that contains the funds, then install priv key on a wallet (e.g. core) the zap the transactions and create a new transaction either after the first has slipped from mempool, or with much lower fees.

Code:

sendrawtransaction 01000000000101c0ee957139541ad18cb3367a4dd0606bbc8c5bd1585ce64e813c5c21359e3f6e0000000017160014ef3247d77adecb1f22692e899931e75e1a5cbb26ffffffff01d65f6c210000000017a914d7cfe4484ffb71b224a0a8eda75bbe7f9494369e8702483045022100a13fb354cde016b28e96d7cecb9b3fce216739f92e72c832a8ba3acde6bc9eb002201ebc94729b3753291de875860e8404c0833cf6ed96060bae8a1080956770a1ec0141044b8d17d6f5fae04c9213da069f4e9fdd25df5f567f867a6a957a850c45a602b788c4a699afacbca54cfc5ba0cd659f20575f2fb20eee6ed73cf8bb7dd95e3fd200000000

Can a negative value be used to pay a TX fee of another TX?  (probably not, but just a suggestion)

[pooya87]

Why not zap wallet and resend with a lower TX fee?  Scrolling down the thread you keep saying you're going to increase the fees, why not lower the TX fee paid to one satoshi?

the problem here has nothing to do with "high fees", read the first page and you'll figure out what it is!
additionally the "absurdly high fee" error is only faced when you try to broadcast it from your wallet, the other nodes' don't have that check when adding the tx to their mempool.

[nc50lc]

TL;DR

Why not zap wallet and resend with a lower TX fee?  Scrolling down the thread you keep saying you're going to increase the fees, why not lower the TX fee paid to one satoshi?

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

{"code": - 26, "message": "non-mandatory-script-verify-flag (Using non-compressed keys in segwit)"}

Here's an example on mainnet:

Code:

0100000000010102ddb7407d8b0ef56a6b3cf0cd5249880791ba721b427d2b70d91003c8f230810000000017160014ec222555455433681092344ed034943eebfe8999fdffffff0158020000000000001976a9142153b0ab155a86f569627ae478be99480fc23b1588ac024830450221008a09367dd99bf01c240c68b0d71d1141455505faf0434cc390d47ee13d181a4002207577ebf1eeac3478ea070b3453b636b75e92de5f435965c8c043b3067384e0c8014104ad8a47c11881ed75b9660e7728ef211db2a719e536fc357674a70151708cbe0354ce9325368c020a5a99dce742480150546d1895a3e6a9e1b0aa96c9d652cc6c00000000

Broadcast on blockstream - error:


Broadcast on blockchair - error:


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

[leventturksoy]

~
I think the change required is very very small, how can I request the change to be made?

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=

Thank you, I've done so here: https://github.com/bitcoin/bitcoin/issues/20178

Someone there took note of this in order to sidestep policies: https://github.com/bitcoin/bitcoin/pull/7533

[leventturksoy]

TL;DR

Why not zap wallet and resend with a lower TX fee?  Scrolling down the thread you keep saying you're going to increase the fees, why not lower the TX fee paid to one satoshi?

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

{"code": - 26, "message": "non-mandatory-script-verify-flag (Using non-compressed keys in segwit)"}

Here's an example on mainnet:

Code:

0100000000010102ddb7407d8b0ef56a6b3cf0cd5249880791ba721b427d2b70d91003c8f230810000000017160014ec222555455433681092344ed034943eebfe8999fdffffff0158020000000000001976a9142153b0ab155a86f569627ae478be99480fc23b1588ac024830450221008a09367dd99bf01c240c68b0d71d1141455505faf0434cc390d47ee13d181a4002207577ebf1eeac3478ea070b3453b636b75e92de5f435965c8c043b3067384e0c8014104ad8a47c11881ed75b9660e7728ef211db2a719e536fc357674a70151708cbe0354ce9325368c020a5a99dce742480150546d1895a3e6a9e1b0aa96c9d652cc6c00000000

Broadcast on blockstream - error:


Broadcast on blockchair - error:


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

Is there a reason why Blockcypher was able to broadcast it in the first place? Normally the broadcast code rejects it on most other websites but Blockcypher seemed to let it through.

[malevolent]

Is there a reason why Blockcypher was able to broadcast it in the first place? Normally the broadcast code rejects it on most other websites but Blockcypher seemed to let it through.

They assume that 99.9% of the time someone tries broadcasting a transaction with an extremely high fee does so by mistake.

[Timelord2067]

Is there a reason why Blockcypher was able to broadcast it in the first place? Normally the broadcast code rejects it on most other websites but Blockcypher seemed to let it through.

If they did accept the TX in the first place, then they don't now:

Blue Wallet

Well... if you have a blue wallet, then you have a mnemonic seed that you can user to recreate the wallet via another service - possibly one that enables you to export the priv key of the wallet that contains the funds, then install priv key on a wallet (e.g. core) the zap the transactions and create a new transaction either after the first has slipped from mempool, or with much lower fees.

Code:

sendrawtransaction 01000000000101c0ee957139541ad18cb3367a4dd0606bbc8c5bd1585ce64e813c5c21359e3f6e0000000017160014ef3247d77adecb1f22692e899931e75e1a5cbb26ffffffff01d65f6c210000000017a914d7cfe4484ffb71b224a0a8eda75bbe7f9494369e8702483045022100a13fb354cde016b28e96d7cecb9b3fce216739f92e72c832a8ba3acde6bc9eb002201ebc94729b3753291de875860e8404c0833cf6ed96060bae8a1080956770a1ec0141044b8d17d6f5fae04c9213da069f4e9fdd25df5f567f867a6a957a850c45a602b788c4a699afacbca54cfc5ba0cd659f20575f2fb20eee6ed73cf8bb7dd95e3fd200000000

Can a negative value be used to pay a TX fee of another TX?  (probably not, but just a suggestion)

Did you try recreating the wallet on another platform as I suggested?

[leventturksoy]

Did you try recreating the wallet on another platform as I suggested?

You said this:

Well... if you have a blue wallet, then you have a mnemonic seed that you can user to recreate the wallet via another service - possibly one that enables you to export the priv key of the wallet that contains the funds, then install priv key on a wallet (e.g. core) the zap the transactions and create a new transaction either after the first has slipped from mempool, or with much lower fees.

Creating a new transaction with lower fees will not bypass the non-standard error, which is the main reason that my transactions cannot just be added into a mempool and included in a block. The transaction will still be non-standard, and the only way for a transaction coming from my address to be mined is for a mining pool to manually include it. This can be done by editing source code, or even without doing that using the github link I included above.

Alternatively, my Github request could be implemented but that is near impossible as I am seemingly the only one with this issue who has a significant amount in limbo. Recreating the wallet doesn't help any of that

[Timelord2067]

Alternatively, my Github request could be implemented but that is near impossible as I am seemingly the only one with this issue who has a significant amount in limbo. Recreating the wallet doesn't help any of that

My reasoning in suggesting it was perhaps the unconfirmed transaction *might* not get restored and hence the funds are freed-up enabling you to create a new transaction that hopefully works given the previous one seems to have slipped out of the mem-pool.

[nc50lc]

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

Is there a reason why Blockcypher was able to broadcast it in the first place? Normally the broadcast code rejects it on most other websites but Blockcypher seemed to let it through.

Probably, they have a few nodes that's configured to accept some non-standard transactions.
I've noticed it a few month ago after I accidentally added a non-standard script and it was accepted by blockcypher's push service (it didn't propagate as well).

Alternatively, my Github request could be implemented but that is near impossible as I am seemingly the only one with this issue who has a significant amount in limbo. Recreating the wallet doesn't help any of that

My reasoning in suggesting it was perhaps the unconfirmed transaction *might* not get restored and hence the funds are freed-up enabling you to create a new transaction that hopefully works given the previous one seems to have slipped out of the mem-pool.

The funds aren't locked in any node's mempool nor his wallet;
The problem is: he can't propagate the 'Signed RAW Transaction' over the network because almost all nodes are rejecting it, thus it can't reach any mining nodes.
Most pools/solo miners' nodes are also configured not to accept such transactions so he's looking for a miner who'll accept the txn - that's what the bounty is for.

[Timelord2067]

The funds aren't locked in any node's mempool nor his wallet;
The problem is: he can't propagate the 'Signed RAW Transaction' over the network because almost all nodes are rejecting it, thus it can't reach any mining nodes.
Most pools/solo miners' nodes are also configured not to accept such transactions so he's looking for a miner who'll accept the txn - that's what the bounty is for.

Yep, I get that - I'm talking about re-creating the wallet as it was (hopefully) before that TX occurred and (for want of a better description) creating a double spend via a TX that the nodes WILL process.

Worth a shot.