[~1 BTC Bounty]

[leventturksoy]

Status as of December 30, 2020: Resolved!.

[1715015902]

1715015902

[1715015902]

1715015902

[1715015902]

1715015902

[1715015902]

1715015902

[1715015902]

1715015902

[1715015902]

1715015902

[pooya87]

The address is a seg-wit address created with an uncompressed private key. This means that the outgoing transaction is considered "non-standard".

no, if the address was indeed created using an uncompressed public key then it is considered invalid and your funds are irretrievable.
edit: read this reply by @nc50lc https://bitcointalk.org/index.php?topic=5192454.msg52742722#msg52742722 (they are not invalid, they are non-standard!)

[leventturksoy]

The address is a seg-wit address created with an uncompressed private key. This means that the outgoing transaction is considered "non-standard".

no, if the address was indeed created using an uncompressed public key then it is considered invalid and your funds are irretrievable.

Maybe a Bitcoin Core dev can adjust some code so it can be retrievable?

[pooya87]

The address is a seg-wit address created with an uncompressed private key. This means that the outgoing transaction is considered "non-standard".

no, if the address was indeed created using an uncompressed public key then it is considered invalid and your funds are irretrievable.

Maybe a Bitcoin Core dev can adjust some code so it can be retrievable?

bitcoin isn't centralized to be controlled by bitcoin core devs so that they could adjust some code and change consensus rules with a snap of a finger!
what makes your output unspendable is consensus rules that dictate SegWit outputs must all use compressed public keys. in order to change that you have to create a fork and get the majority of the network to accept that fork.

i am curious, how did you create this address in first place?

[leventturksoy]

The address is a seg-wit address created with an uncompressed private key. This means that the outgoing transaction is considered "non-standard".

no, if the address was indeed created using an uncompressed public key then it is considered invalid and your funds are irretrievable.

Maybe a Bitcoin Core dev can adjust some code so it can be retrievable?

bitcoin isn't centralized to be controlled by bitcoin core devs so that they could adjust some code and change consensus rules with a snap of a finger!
what makes your output unspendable is consensus rules that dictate SegWit outputs must all use compressed public keys. in order to change that you have to create a fork and get the majority of the network to accept that fork.

i am curious, how did you create this address in first place?

Old version of Bluewallet for iOS (Android also had the bug) it let me create it without error-catching it.

They refuse to own up to their mistakes or even acknowledge it.

[nc50lc]

There are tons of threads in reddit about it and there's one with a reply from Pieter Wuille:
Created SegWit Address with Uncompressed
(don't want to click?) It said that it's not against the consensus rues but the transaction was indeed non-standard that's why nodes are rejecting it.
So it's possible to spend if a miner will include it to a block.

A single miner doesn't have enough hashrate to solo mine BTC, almost all of them are connected to a pool.
Just PM/Reply to some of the Bitcoin mining pools operators here in the forum: Mining->Pools.
They don't usually wander in this part of the forum.

[pooya87]

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?!

[leventturksoy]

There are tons of threads in reddit about it and there's one with a reply from Pieter Wuille:
Created SegWit Address with Uncompressed
(don't want to click?) It said that it's not against the consensus rues but the transaction was indeed non-standard that's why nodes are rejecting it.
So it's possible to spend if a miner will include it to a block.

A single miner doesn't have enough hashrate to solo mine BTC, almost all of them are connected to a pool.
Just PM/Reply to some of the Bitcoin mining pools operators here in the forum: Mining->Pools.
They don't usually wander in this part of the forum.

That was actually my Reddit thread. Interesting enough I have failed every attempt at reaching a mining operator. Thanks for the reassurance though, I'll keep trying

[nc50lc]

That was actually my Reddit thread. Interesting enough I have failed every attempt at reaching a mining operator. Thanks for the reassurance though, I'll keep trying

Figures, the timing and scenario look identical.
How about small mining pools? All you need is to get it included in a block, even an average 1-block per month pool will do.

[leventturksoy]

That was actually my Reddit thread. Interesting enough I have failed every attempt at reaching a mining operator. Thanks for the reassurance though, I'll keep trying

Figures, the timing and scenario look identical.
How about small mining pools? All you need is to get it included in a block, even an average 1-block per month pool will do.

I'll give that a shot, at this point I'll contact and ask anyone seeing as though my offer is just about pennies for larger pools who don't care about me

[josephdd1]

I am curious to know guys. How can pool operator dictate which blocks get mined? As far as I know they are not in control of the individual and independent miners. Would the miners get any block reward if they include this non standard segwit transaction?

The Bluewallet guys must be held responsible for this.

[pooya87]

I am curious to know guys. How can pool operator dictate which blocks get mined? As far as I know they are not in control of the individual and independent miners. Would the miners get any block reward if they include this non standard segwit transaction?

you can split bitcoin network into two parts: miners and nodes.
a miner is just a hardware (ASIC) that has computing power. the only thing they do is "calculate" (perform hashes) nothing else. but they connect to a node to receive the data they should hash. the node decides which transaction it should give the miner.
now a mining pool is a server that is running a node and the miners connect to in order to share the work. that pool/node decides which transaction to mine. for example they decide to only include transactions that are paying 2 satoshi/byte at least, another one could decide to include 0 satoshi/byte,... they could also decide which non-standard transaction to include in the blocks.
in all cases when a miner shares the work and they find a block they receive their share of the reward no matter what they mined (as long as the block was valid of course).

[DaveF]

I'll give that a shot, at this point I'll contact and ask anyone seeing as though my offer is just about pennies for larger pools who don't care about me

Sent you a message on reddit. Did you reach out to u/MemoryDealers there or here https://bitcointalk.org/index.php?action=profile;u=10310 ? He is more involved with BCH not BTC but he does run a pool and might be able to help.

He is not real popular here because of his pro BCH anti BTC attitude but he does tend to respond to people, even if it's a no answer.

-Dave

[leventturksoy]

There are tons of threads in reddit about it and there's one with a reply from Pieter Wuille:
Created SegWit Address with Uncompressed
(don't want to click?) It said that it's not against the consensus rues but the transaction was indeed non-standard that's why nodes are rejecting it.
So it's possible to spend if a miner will include it to a block.

A single miner doesn't have enough hashrate to solo mine BTC, almost all of them are connected to a pool.
Just PM/Reply to some of the Bitcoin mining pools operators here in the forum: Mining->Pools.
They don't usually wander in this part of the forum.

That forum is quite dead, where can I find a better list of smaller pools that are still active?

[DaveF]

That forum is quite dead, where can I find a better list of smaller pools that are still active?

Novablock.com is online a lot and active in their thread:

https://bitcointalk.org/index.php?topic=5183959.0

CK is on and active, but it's been months since they found a block.

-Dave

[nc50lc]

That forum is quite dead, where can I find a better list of smaller pools that are still active?

Aside from the post above, you can also click the author's profile and check "last active" date.
Just by looking, you'll know if the pool operator is still active.

Most of the threads may be inactive, but not the topic starter.

[josephdd1]

I am curious to know guys. How can pool operator dictate which blocks get mined? As far as I know they are not in control of the individual and independent miners. Would the miners get any block reward if they include this non standard segwit transaction?

you can split bitcoin network into two parts: miners and nodes.
a miner is just a hardware (ASIC) that has computing power. the only thing they do is "calculate" (perform hashes) nothing else. but they connect to a node to receive the data they should hash. the node decides which transaction it should give the miner.
now a mining pool is a server that is running a node and the miners connect to in order to share the work. that pool/node decides which transaction to mine. for example they decide to only include transactions that are paying 2 satoshi/byte at least, another one could decide to include 0 satoshi/byte,... they could also decide which non-standard transaction to include in the blocks.
in all cases when a miner shares the work and they find a block they receive their share of the reward no matter what they mined (as long as the block was valid of course).

Thank you for explaining that. I am not a very technical person when mining concerned so I was very confused. I would have given you some merit but since you are already high rank I think you can do without it.

[leventturksoy]

I'll give that a shot, at this point I'll contact and ask anyone seeing as though my offer is just about pennies for larger pools who don't care about me

Sent you a message on reddit. Did you reach out to u/MemoryDealers there or here https://bitcointalk.org/index.php?action=profile;u=10310 ? He is more involved with BCH not BTC but he does run a pool and might be able to help.

He is not real popular here because of his pro BCH anti BTC attitude but he does tend to respond to people, even if it's a no answer.

-Dave

No response on Reddit. I can't PM him here as I am a newbie, if you could PM him for me on my behalf I would greatly appreciate that

[100bitcoin]

The address is a seg-wit address created with an uncompressed private key. This means that the outgoing transaction is considered "non-standard".

no, if the address was indeed created using an uncompressed public key then it is considered invalid and your funds are irretrievable.

If a transaction from an address created with uncompressed public key is considered non-standard, then why a transaction to an address created with uncompressed public key is considered standard? I mean, if Bitcoin Core nodes consider a certain type of address to be non-standard, then Bitcoin Core nodes should reject transactions sent to it at the first place. Is not it?

[nc50lc]

The address is a seg-wit address created with an uncompressed private key. This means that the outgoing transaction is considered "non-standard".

no, if the address was indeed created using an uncompressed public key then it is considered invalid and your funds are irretrievable.

-snip- then why a transaction to an address created with uncompressed public key is considered standard?

Where did he mentioned it's standard
What pooya meant by "no" was already written in his reply: he said "invalid", what his "no" means isn't standard.
But later, it's countered by the link in my post.

P.S. Yes, most non-standard TXs wont be relayed but invalid TXs can't be mined.

[MemoryDealers]

I've asked our pool team to look into this to see if it is possible.
pool.bitcoin.com

Good luck!

[achow101]

Roger, if you tried to submit a block with that transaction, and other miners or nodes do not accept it as valid according to protocol or code, the block would be orphaned.

Now, if you want to out of your pocket try and see if the tx would be considered valid, it is your choice to do so, to help out.

But there is a significant chance the block would be rejected and orphaned.

It won't be because the transaction is consensus valid. Blocks have never been rejected for containing non-standard transactions.

If you don't think it is consensus valid, you can test it yourself. The getblocktemplate RPC allows you to submit a block proposal. It is just a block that does not have a valid proof of work, everything else needs to be valid (scripts, signatures, merkle root, etc.). That block proposal is validated for everything except the Proof of Work (and no attempt is made to relay it). The RPC will tell you whether the block proposal is valid (everything passes validation) or what the specific validation error is if not valid. So if you make a block proposal with OPs transaction, you will find that it is in fact consensus valid.

Here is a python script that will connect to a bitcoind and check whether the given txs are consensus valid: https://gist.github.com/achow101/51751f10f394ec1a5fb1cd77a3e30181

[achow101]

Really incredible. So segwit can have uncompressed keys which is larger in bytes?

Apparently yes.

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.

https://bitcoincore.org/en/segwit_wallet_dev/

The documentation is wrong and should be fixed.

[achow101]

This is wrong???:

"To create a P2SH-P2WSH address:
Define a script, called (witnessScript)
Calculate the SHA256 of the witnessScript (scripthash). Please pay attention that a single SHA256 is used, not double SHA256 nor RIPEMD160(SHA256)"

edit:

here is his tx:


            "script_type": "pay-to-script-hash",

His script isn't P2SH-P2WSH, it's P2SH-P2WPKH. It's key hash, not script hash, so it's still RIPEMD160(SHA256()), and the documentation does say that.

[achow101]

So do you know any miners off hand that would allow him to do it, and have other miners also validate the tx?


edit:

The majority of hashpower would have to allow uncompressed for that tx type.
I don't think the network would get in a hashing war over this guy (there is always one) and his boo boo.

ALL miners and nodes will allow this transaction. It is non-standard, which just means that they won't relay it for normal transaction relay as an unconfirmed transaction. But if it is included in a block, it is still consensus valid and all nodes (including miners) will validate and accept it.

Standardness only applies to the relay of unconfirmed transactions. It has no effect on transactions in blocks.

[leventturksoy]

So do you know any miners off hand that would allow him to do it, and have other miners also validate the tx?


edit:

The majority of hashpower would have to allow uncompressed for that tx type.
I don't think the network would get in a hashing war over this guy (there is always one) and his boo boo.

ALL miners and nodes will allow this transaction. It is non-standard

I see what has happened in the validation files.

So if tx checking validates it despite that, will the douche pay up what he should other than meager tx fee?

$2,000+ USD is not meager, and what did I do to be called a douche? 

[LoyceV]

ALL miners and nodes will allow this transaction. It is non-standard, which just means that they won't relay it for normal transaction relay as an unconfirmed transaction.

Would this be something a miner can easily change? Say Pool X sets up nodes that accept it, assuming the fee is above a certain very high threshold, so they become the go-to location for all similar cases?

[achow101]

ALL miners and nodes will allow this transaction. It is non-standard, which just means that they won't relay it for normal transaction relay as an unconfirmed transaction.

Would this be something a miner can easily change? Say Pool X sets up nodes that accept it, assuming the fee is above a certain very high threshold, so they become the go-to location for all similar cases?

Core does not allow accepting non-standard transactions on mainnet. There is a -acceptnonstdtxn option that can be enabled, but it does not do anything on mainnet; it only works on testnet and regtest. However, it is trivial to change that, there is just one if block that can be removed to allow accepting non-standard transactions on mainnet.

So it would be pretty easy for a pool operator to run a slightly modified version of Core that accepts non-standard transactions.

[100bitcoin]

The address is a seg-wit address created with an uncompressed private key. This means that the outgoing transaction is considered "non-standard".

no, if the address was indeed created using an uncompressed public key then it is considered invalid and your funds are irretrievable.

-snip- then why a transaction to an address created with uncompressed public key is considered standard?

Where did he mentioned it's standard
What pooya meant by "no" was already written in his reply: he said "invalid", what his "no" means isn't standard.
But later, it's countered by the link in my post.

P.S. Yes, most non-standard TXs wont be relayed but invalid TXs can't be mined.

My point is if the Tx from 34dqaqvQNWMgbMJmmxVa8LeGz7St6ATT97 is not mined by miners because it is non-standard, then why the Tx to the same address, i.e. 6e3f9e35215c3c814ee65c58d15b8cbc6b60d04d7a36b38cd11a54397195eec0, was mined? Is not it creating an asymmetry to Bitcoin network in general?

[LoyceV]

My point is if the Tx from 34dqaqvQNWMgbMJmmxVa8LeGz7St6ATT97 is not mined by miners because it is non-standard, then why the Tx to the same address, i.e. 6e3f9e35215c3c814ee65c58d15b8cbc6b60d04d7a36b38cd11a54397195eec0, was mined?

Any valid Bitcoin address can receive funds. It's not possible to see how an address was created when funds are deposited.

[100bitcoin]

My point is if the Tx from 34dqaqvQNWMgbMJmmxVa8LeGz7St6ATT97 is not mined by miners because it is non-standard, then why the Tx to the same address, i.e. 6e3f9e35215c3c814ee65c58d15b8cbc6b60d04d7a36b38cd11a54397195eec0, was mined?

Any valid Bitcoin address can receive funds. It's not possible to see how an address was created when funds are deposited.

This is turning into fallacy. A valid Bitcoin address can receive fund, but hindrance will be created in the process of moving fund out of it! IMHO, this situation was needed to be taken care of while implementing SegWit.

[achow101]

My point is if the Tx from 34dqaqvQNWMgbMJmmxVa8LeGz7St6ATT97 is not mined by miners because it is non-standard, then why the Tx to the same address, i.e. 6e3f9e35215c3c814ee65c58d15b8cbc6b60d04d7a36b38cd11a54397195eec0, was mined? Is not it creating an asymmetry to Bitcoin network in general?

It is impossible for the sender to know whether the redeemScript is a standard script. The address is a P2SH address, which means it is the hash of a redeemScript. The sender does not know whether the redeemScript is standard, or even valid, because they don't have the redeemScript, and there is no reason that they should.

Furthermore, because the redeemScript is a public key hash, even if the sender had the redeemScript, they wouldn't know whether the public key is compressed or uncompressed unless they had the public key. And there is no reason they would have the public key either.

This is turning into fallacy. A valid Bitcoin address can receive fund, but hindrance will be created in the process of moving fund out of it! IMHO, this situation was needed to be taken care of while implementing SegWit.

It is the receiver's job to ensure that the coins are spendable by them, not the sender. It is in the receiver's best interest that they can spend the coins. Why should the sender be sure the receiver can spend those coins? It would be a severe hindrance to have to check that the receiver could spend the coins, and may even make it less secure for the receiver.

[DaveF]

ALL miners and nodes will allow this transaction. It is non-standard, which just means that they won't relay it for normal transaction relay as an unconfirmed transaction.

Would this be something a miner can easily change? Say Pool X sets up nodes that accept it, assuming the fee is above a certain very high threshold, so they become the go-to location for all similar cases?

An interesting thing to think about.
In theory the pool operator would not even have to have nodes that listen for it, all they would need is a web page that you paste in the signed transaction and it can take it from there.

Core does not allow accepting non-standard transactions on mainnet. There is a -acceptnonstdtxn option that can be enabled, but it does not do anything on mainnet; it only works on testnet and regtest. However, it is trivial to change that, there is just one if block that can be removed to allow accepting non-standard transactions on mainnet.
So it would be pretty easy for a pool operator to run a slightly modified version of Core that accepts non-standard transactions.

Do you know if the larger pool operators (poolin / btc.com / viabtc / antpool) even use "stock" core or some heavily modified version of it or some custom code.
I would think that they would have something heavily customized for their use as it is now.

-Dave

[malevolent]

You could set aside one day out of the year where everyone can send in txs as a celebration to show their support of such things.

Sounds like a recipe for a lot of losses from double spending attacks

It would be better if most nodes & miners decided to start accepting non-standard transactions for good.

[checksum0]

Hello, I am offering up to 1 BTC to help recover my funds. The situation is as this: 5.87750550 BTC is stuck. I am offering 0.277 BTC as a miner fee, and up to 0.7 BTC to a person(s) who can help me retrieve it. The address is a seg-wit address created with an uncompressed private key. This means that the outgoing transaction is considered "non-standard". I have reached out to every major mining pool with no luck, hence the reason to create this bounty.

If you are a reputed member of this forum, please message me for the bounty explaining what you can do.

If you are a miner, here is a signed transaction hex containing a 0.277 BTC miner fee:

01000000000101c0ee957139541ad18cb3367a4dd0606bbc8c5bd1585ce64e813c5c21359e3f6e0 000000017160014ef3247d77adecb1f22692e899931e75e1a5cbb26ffffffff01d65f6c21000000 0017a914d7cfe4484ffb71b224a0a8eda75bbe7f9494369e8702483045022100a13fb354cde016b 28e96d7cecb9b3fce216739f92e72c832a8ba3acde6bc9eb002201ebc94729b3753291de875860e 8404c0833cf6ed96060bae8a1080956770a1ec0141044b8d17d6f5fae04c9213da069f4e9fdd25d f5f567f867a6a957a850c45a602b788c4a699afacbca54cfc5ba0cd659f20575f2fb20eee6ed73c f8bb7dd95e3fd200000000

I can't DM you unfortunately. If that transaction has not been mined yet, please send me the transaction with a 1sat/bytes fee to ian@bitcoin.com and we will mine it.

If I don't hear from you shortly I will nonetheless add the transaction on Monday and you can email me to get the fee back.

I heard about your issue from our support staff when I was travelling, I told them I only needed a valid raw tx and we would add it but I didn't hear back from the support staff and I forgot to follow up on this. Sorry about that.

[leventturksoy]

Hello, I am offering up to 1 BTC to help recover my funds. The situation is as this: 5.87750550 BTC is stuck. I am offering 0.277 BTC as a miner fee, and up to 0.7 BTC to a person(s) who can help me retrieve it. The address is a seg-wit address created with an uncompressed private key. This means that the outgoing transaction is considered "non-standard". I have reached out to every major mining pool with no luck, hence the reason to create this bounty.

If you are a reputed member of this forum, please message me for the bounty explaining what you can do.

If you are a miner, here is a signed transaction hex containing a 0.277 BTC miner fee:

01000000000101c0ee957139541ad18cb3367a4dd0606bbc8c5bd1585ce64e813c5c21359e3f6e0 000000017160014ef3247d77adecb1f22692e899931e75e1a5cbb26ffffffff01d65f6c21000000 0017a914d7cfe4484ffb71b224a0a8eda75bbe7f9494369e8702483045022100a13fb354cde016b 28e96d7cecb9b3fce216739f92e72c832a8ba3acde6bc9eb002201ebc94729b3753291de875860e 8404c0833cf6ed96060bae8a1080956770a1ec0141044b8d17d6f5fae04c9213da069f4e9fdd25d f5f567f867a6a957a850c45a602b788c4a699afacbca54cfc5ba0cd659f20575f2fb20eee6ed73c f8bb7dd95e3fd200000000

I can't DM you unfortunately. If that transaction has not been mined yet, please send me the transaction with a 1sat/bytes fee to ian@bitcoin.com and we will mine it.

If I don't hear from you shortly I will nonetheless add the transaction on Monday and you can email me to get the fee back.

I heard about your issue from our support staff when I was travelling, I told them I only needed a valid raw tx and we would add it but I didn't hear back from the support staff and I forgot to follow up on this. Sorry about that.

I can't DM you either, but I e-mailed you again. I am very appreciative for you guys at Bitcoin.com for your initiative to help me out 

[DaveF]

If you want PM me and I'll pass it on.

It would help if the slackers at bitcoin.com pool stopped playing around and found a block :-)
Seriously, I'm glad we have pool operators like you who are willing to help out.

-Dave

[gmaxwell]

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).

[pooya87]

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

well maybe it is just me, but i still think as a "documentation" (specially the BIP) it  could have been written in a much clearer way by using a slightly different terminology. for instance it doesn't mention "standardness" anywhere instead uses the term "default policy" which i interpret as meaning "consensus rule" not "standard rule".

[Lauda]

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

well maybe it is just me, but i still think as a "documentation" (specially the BIP) it  could have been written in a much clearer way by using a slightly different terminology. for instance it doesn't mention "standardness" anywhere instead uses the term "default policy" which i interpret as meaning "consensus rule" not "standard rule".

The differentiation between consensus rules and policies is widely-known, or I have presumed that this was the case. Is it not?

[leventturksoy]

The tx is still not mined as of right now!

[DaveF]

Did you email ian@bitcoin.com from above? If so what did he say?

You can also try reaching out to viabtc, they do have a twitter account:

https://twitter.com/viabtc
And a facebook page:
https://www.facebook.com/viabtc

Although not very active they are there.

-Dave

[leventturksoy]

Did you email ian@bitcoin.com from above? If so what did he say?

You can also try reaching out to viabtc, they do have a twitter account:

https://twitter.com/viabtc
And a facebook page:
https://www.facebook.com/viabtc

Although not very active they are there.

-Dave

Ian said he would offer a helping hand, but I've lost touch with him

[DaveF]

Did you email ian@bitcoin.com from above? If so what did he say?

You can also try reaching out to viabtc, they do have a twitter account:

https://twitter.com/viabtc
And a facebook page:
https://www.facebook.com/viabtc

Although not very active they are there.

-Dave

Ian said he would offer a helping hand, but I've lost touch with him

I PMd checksum0 and MemoryDealers

Let's see what they say.
Odd that there is no response.

-Dave

[leventturksoy]

Did you email ian@bitcoin.com from above? If so what did he say?

You can also try reaching out to viabtc, they do have a twitter account:

https://twitter.com/viabtc
And a facebook page:
https://www.facebook.com/viabtc

Although not very active they are there.

-Dave

Ian said he would offer a helping hand, but I've lost touch with him

I PMd checksum0 and MemoryDealers

Let's see what they say.
Odd that there is no response.

-Dave

checksum0 has been MIA for a month, and is also not responding to any e-mails. Does anyone know an alternative way to contact him/her?

[leventturksoy]

My chances seem to be dying out, does anyone here have an idea?

[pooya87]

My chances seem to be dying out, does anyone here have an idea?

did you contact those who were mentioned in this topic (-ck, NovaBlock)?
here is another one: kano https://bitcointalk.org/index.php?action=profile;u=36044

ps. weren't Roger Ver's mining pool supposed to help you?!
pps. if my calculation is correct your transaction fee is 0.27BTC, if you want to pay a 1BTC bounty you might want to increase the fee to that amount although 0.27 is still a pretty high reward for mining a simple non-standard tx. you also might want to include your tx fee value (the reward) in your messages to mining pool owners.

[kano]

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.

[leventturksoy]

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.

Your explanation at the end there is contradictory to what I know about Bitcoin - how can I "re-send" a transaction that has been confirmed for 8 months? What are my alternatives if no miner wants to take that risk for this?

[kano]

...
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.

Your explanation at the end there is contradictory to what I know about Bitcoin - how can I "re-send" a transaction that has been confirmed for 8 months? What are my alternatives if no miner wants to take that risk for this?

The transaction doesn't exist.
Transactions that transfer coins, exist in the blockchain.
There is no transaction:
c842420807d44d8214509bdffc30366416ebfe033c26b8cdc3b0713cfa3846b6
(this is the txnid = the hash of your 248 byte transaction in the first post)

Even a transaction that exists out on the net and in the "mempool", but not in a block, can be replaced before it gets confirmed (by various means)

Maybe you are confusing transactions with "some web site's accounting systems saying they've sent BTC to you"

That's the fun thing about Bitcoin, there is a 100% proof of 'transferring' coins - called transactions in the blockchain.

However, if instead you are saying there already is an "Invalid" transaction (as in "Invalid" due to being 'valid' in a block yet 'invalid' due to core not accepting it) already accepted in a block and you wish to spend some of it - then be all means point out this "Invalid" transaction.

[pooya87]

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.

the problem isn't with the rawtx OP contains, the problem is with the already confirmed transaction that this rawtx is trying to spend: 6e3f9e35215c3c814ee65c58d15b8cbc6b60d04d7a36b38cd11a54397195eec0
in that tx 5.87750550BTC is sent to a "valid" but "non-standard" output (address=34dqaqvQNWMgbMJmmxVa8LeGz7St6ATT97) that was created using an uncompressed public key instead of compressed one. that is why the rawtx in OP can not propagate throughout the network since almost all bitcoin nodes reject non-standard transactions.

nothing can change about the rawtx in OP (the spending tx), it is already valid and the only way to spend that output but non-standard.

in other words the address 34dqaqvQNWMgbMJmmxVa8LeGz7St6ATT97 that has already received the coins is a nested SegWit address (or P2WPKH-P2SH) that was created using

Code:

04-4b8d17d6f5fae04c9213da069f4e9fdd25df5f567f867a6a957a850c45a602b788c4a699afacbca54cfc5ba0cd659f20575f2fb20eee6ed73cf8bb7dd95e3fd2

public key instead of

Code:

02/03-4b8d17d6f5fae04c9213da069f4e9fdd25df5f567f867a6a957a850c45a602b7

which makes it non-standard not invalid, so any tx trying to spend that output is rejected by nodes.

[DaveF]

nothing can change about the rawtx in OP (the spending tx), it is already valid and the only way to spend that output but non-standard.

in other words the address 34dqaqvQNWMgbMJmmxVa8LeGz7St6ATT97 that has already received the coins is a nested SegWit address (or P2WPKH-P2SH) that was created using

Code:

04-4b8d17d6f5fae04c9213da069f4e9fdd25df5f567f867a6a957a850c45a602b788c4a699afacbca54cfc5ba0cd659f20575f2fb20eee6ed73cf8bb7dd95e3fd2

public key instead of

Code:

02/03-4b8d17d6f5fae04c9213da069f4e9fdd25df5f567f867a6a957a850c45a602b7

which makes it non-standard not invalid, so any tx trying to spend that output is rejected by nodes.

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

[leventturksoy]

nothing can change about the rawtx in OP (the spending tx), it is already valid and the only way to spend that output but non-standard.

in other words the address 34dqaqvQNWMgbMJmmxVa8LeGz7St6ATT97 that has already received the coins is a nested SegWit address (or P2WPKH-P2SH) that was created using

Code:

04-4b8d17d6f5fae04c9213da069f4e9fdd25df5f567f867a6a957a850c45a602b788c4a699afacbca54cfc5ba0cd659f20575f2fb20eee6ed73cf8bb7dd95e3fd2

public key instead of

Code:

02/03-4b8d17d6f5fae04c9213da069f4e9fdd25df5f567f867a6a957a850c45a602b7

which makes it non-standard not invalid, so any tx trying to spend that output is rejected by nodes.

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

Yeah I haven't heard back in months from the ones who originally told me they would do it. I'd appreciate any help possible - I'm throwing rewards on top of the 0.277 to whoever can help, directly or indirectly, lead the transaction to be mined. I'm willing to wait months no problem. Thanks for the initiative Dave.

[kano]

nothing can change about the rawtx in OP (the spending tx), it is already valid and the only way to spend that output but non-standard.

in other words the address 34dqaqvQNWMgbMJmmxVa8LeGz7St6ATT97 that has already received the coins is a nested SegWit address (or P2WPKH-P2SH) that was created using

Code:

04-4b8d17d6f5fae04c9213da069f4e9fdd25df5f567f867a6a957a850c45a602b788c4a699afacbca54cfc5ba0cd659f20575f2fb20eee6ed73cf8bb7dd95e3fd2

public key instead of

Code:

02/03-4b8d17d6f5fae04c9213da069f4e9fdd25df5f567f867a6a957a850c45a602b7

which makes it non-standard not invalid, so any tx trying to spend that output is rejected by nodes.

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

...

Ah OK, then that matches as I said at the end of my last post, that's the situation here.

The problem isn't the new transaction from someone else claiming to have sent to him (as I thought), but the previous one he is trying to spend.

...
However, if instead you are saying there already is an "Invalid" transaction (as in "Invalid" due to being 'valid' in a block yet 'invalid' due to core not accepting it) already accepted in a block and you wish to spend some of it - then be all means point out this "Invalid" transaction.

So this leads directly back to my first comment also:

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.
...

and the rest after that - i.e. asking a pool to change the code they run for block work generation ... and the risks involved.

[DaveF]

and the rest after that - i.e. asking a pool to change the code they run for block work generation ... and the risks involved.

No code changes needed.
As achow101 said above if you call getblocktemplate with the signed transaction that the OP posted it is valid. He even provided a python script to check it.
Other nodes will not relay the transaction, but once it's in your own mempool it will be part of a valid block that will be accepted.

-Dave

[kano]

and the rest after that - i.e. asking a pool to change the code they run for block work generation ... and the risks involved.

No code changes needed.
As achow101 said above if you call getblocktemplate with the signed transaction that the OP posted it is valid. He even provided a python script to check it.
Other nodes will not relay the transaction, but once it's in your own mempool it will be part of a valid block that will be accepted.

-Dave

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.

[leventturksoy]

and the rest after that - i.e. asking a pool to change the code they run for block work generation ... and the risks involved.

No code changes needed.
As achow101 said above if you call getblocktemplate with the signed transaction that the OP posted it is valid. He even provided a python script to check it.
Other nodes will not relay the transaction, but once it's in your own mempool it will be part of a valid block that will be accepted.

-Dave

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.

So in short, you won't do it using your own pool?

[leventturksoy]

This is depressing 

[iluvbitcoins]

This is depressing  

Don't worry for the future.
Right now, maybe the chances are slim, but with each coming halving your proposal is going to be more and more appealing.

[BrewMaster]

This is depressing 

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.

[leventturksoy]

This is depressing 

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.

I'm open to negotiate with pools, I have offered more to many pools but still it seems like the associated risk can't be measured accurately enough for them to take my offer.

[leventturksoy]

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

[leventturksoy]

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

I'll up this even more as needed, please contact me if you can help

[Vod]

Old version of Bluewallet for iOS (Android also had the bug) it let me create it without error-catching it.

They refuse to own up to their mistakes or even acknowledge it.

Sue them!

They are entitled to the profit they made from the app, and that means they are responsible for app programming errors if they cost you money.

[LoyceV]

that means they are responsible for app programming errors if they cost you money.

I highly doubt that, BlueWallet uses the same MIT License as Bitcoin Core:

Code:

MIT License

Copyright (c) 2018 Igor Korsakov

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

If the software creator would be liable for damages caused by bugs, that could very well be the end of open source software.

Even large software corporations get away with bugs that cause much more damage.

[leventturksoy]

Legal action is virtually not even an option. I would feel as if the core devs are more responsible than anyone else for even letting this be a possibility.

[pooya87]

Legal action is virtually not even an option. I would feel as if the core devs are more responsible than anyone else for even letting this be a possibility.

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.

[leventturksoy]

Legal action is virtually not even an option. I would feel as if the core devs are more responsible than anyone else for even letting this be a possibility.

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 am the OP. And I understand that, however, this specific situation could have easily been avoided, both on my part, and the developers.

[leventturksoy]

It's been 2 months since the halving, if you have any interest in helping me please do contact me!

[leventturksoy]

The BTC is still sitting in my wallet.

[seoincorporation]

The BTC is still sitting in my wallet.

I know you are trying to deal with mines, but there is another way you can recover some of that money, let me offer a solution.

I know this will sound crazy, but for crazy problems crazy solutions. You can make an auction for the private key of 34dqaqvQNWMgbMJmmxVa8LeGz7St6ATT97 addy... Just like selling an old car with some engine problems. Maybe some people or even miners could make an offer... I recommend to start it from 1BTC and a signed message with the 34dq private key.

The right place to do it is in:

https://bitcointalk.org/index.php?board=73.0

And i would add this post to let people know about the main problem of that address.

https://bitcointalk.org/index.php?topic=5192454.msg53728095#msg53728095

That's what i would do if i were in your shoes, good luck and i hope you can recover at least some of that money.

[pooya87]

You can make an auction for the private key of 34dqaqvQNWMgbMJmmxVa8LeGz7St6ATT97 addy...

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.

[BASE16]

You can make an auction for the private key of 34dqaqvQNWMgbMJmmxVa8LeGz7St6ATT97 addy...

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.

Well this depends on how you look at it.
There can also be a problem as follows, suppose i manage to push this tx into the network, then it will be mined by some unknown miner, or pool, which will get a high .27 fee, then he will be happy, and the OP will be happy to see that he regained access to his funds, but i will be here empty handed.

[seoincorporation]

....
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.

The way he is doing it he can only deal with miners... The way i proposed any user could be interested.

I know the only way to fix this is by making the miners put the transaction in the block, but if the goal for OP is to recover the coins then there is another solution 

[leventturksoy]

You can make an auction for the private key of 34dqaqvQNWMgbMJmmxVa8LeGz7St6ATT97 addy...

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.

If 0.27 isn't enough, then what is? I'm seriously considering bumping the fee, but I don't see that as a make it or break it saving move.

[pooya87]

You can make an auction for the private key of 34dqaqvQNWMgbMJmmxVa8LeGz7St6ATT97 addy...

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.

Well this depends on how you look at it.
There can also be a problem as follows, suppose i manage to push this tx into the network, then it will be mined by some unknown miner, or pool, which will get a high .27 fee, then he will be happy, and the OP will be happy to see that he regained access to his funds, but i will be here empty handed.

the only ones that could solve OPs issue are the pool operators (or theoretically a solo miner who runs their own node) and they have to disable standard rules or remove the SCRIPT_VERIFY_WITNESS_PUBKEYTYPE flag from their policy.
you as an individual can not do this!

~
If 0.27 isn't enough, then what is? I'm seriously considering bumping the fee, but I don't see that as a make it or break it saving move.

possibly 6.25 since according to what @kano said in previous page the miners may be worried that the block they find (which would give them 6.25 bitcoin reward + whatever fee) could become invalid and rejected by the rest of the network!!

[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.

[malevolent]

possibly 6.25 since according to what @kano said in previous page the miners may be worried that the block they find (which would give them 6.25 bitcoin reward + whatever fee) could become invalid and rejected by the rest of the network!!

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.

[pooya87]

possibly 6.25 since according to what @kano said in previous page the miners may be worried that the block they find (which would give them 6.25 bitcoin reward + whatever fee) could become invalid and rejected by the rest of the network!!

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.

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.

[ABCbits]

possibly 6.25 since according to what @kano said in previous page the miners may be worried that the block they find (which would give them 6.25 bitcoin reward + whatever fee) could become invalid and rejected by the rest of the network!!

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.

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.

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.

[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.

[nc50lc]

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.

Hmm, I don't know what you're suggesting but AFAIK, there's no convenient way to reverse a transaction that was already included in the blockchain.
He's trying to spend a UTXO from the blockchain that can only be spent with a non-standard transaction.

[leventturksoy]

@nc50lc @Timelord2067

Out of curiosity, I created a transaction with a much lower fee (50k sats/b). Obviously its not being mined, but it seems like Blockcypher is putting its mining priority as high? I find it interesting that the numbers can be so drastically different when the fee is this much lower.

[nc50lc]

I think the "Miner Preference" is solely based from the fee/vbyte of your transaction, since it has a higher fee than the current highest fee, it's displayed as "high".
But it will still depend if a miner will pick-up your transaction.

The "Confidence" however, is based from their algorithm for the confidence factor: https://www.blockcypher.com/dev/bitcoin/#confidence-factor
That includes the fee rate, number of mempools that has the txn and other factors.

Can you click the "!" in the "confidence" to check how many nodes (that they see in average) have accepted your transaction?

[leventturksoy]

I think the "Miner Preference" is solely based from the fee/vbyte of your transaction, since it has a higher fee than the current highest fee, it's displayed as "high".
But it will still depend if a miner will pick-up your transaction.

The "Confidence" however, is based from their algorithm for the confidence factor: https://www.blockcypher.com/dev/bitcoin/#confidence-factor
That includes the fee rate, number of mempools that has the txn and other factors.

Can you click the "!" in the "confidence" to check how many nodes (that they see in average) have accepted your transaction?

It says 156 memory pools have the tx.

[Timelord2067]

@nc50lc @Timelord2067

Out of curiosity, I created a transaction with a much lower fee (50k sats/b). Obviously its not being mined, but it seems like Blockcypher is putting its mining priority as high? I find it interesting that the numbers can be so drastically different when the fee is this much lower.

I hope it works for you, I have a list of websites that [Guide] Broadcast Your RAW Transaction BTC & Alts coins - there aren't as many as a year ago, but if you can get the RAW transaction, then you should be able to broadcast it again.  (if you post the new RAW TX perhaps some people here can sendrawtransaction via their own wallets?)

Hope it works out for you.

[nc50lc]

Can you click the "!" in the "confidence" to check how many nodes (that they see in average) have accepted your transaction?

It says 156 memory pools have the tx.

As I thought, there're too few nodes that accepted that tx.
My mainnet test "uncompressed SegWit" transaction has the same behavior (140-170 mempools) and
I have been re-broadcast~ing it through blockcypher with no avail of being mined (as I expected).

Still, there's a very very slim chance.
Good luck!

[MrFreeDragon]

Just curios, this segwit address (with stuck 5.8BTC) was created based on uncompressed public key:
https://blockchair.com/bitcoin/address/34dqaqvQNWMgbMJmmxVa8LeGz7St6ATT97

Is there exist another private with the compressed public key leads to the same segwit address?

[nc50lc]

Is there exist another private with the compressed public key leads to the same segwit address?

Theoretically, there might be.
Because there are more private keys than the total number of '3' addresses.
Here's a similar discussion, but about P2PKH: how many possible private keys can be generated for a public key

Since we're talking about P2SH here, there's also a chance that a different script might produce that address.

But take note that the numbers are too high for a collision to be possible.

[leventturksoy]

Can you click the "!" in the "confidence" to check how many nodes (that they see in average) have accepted your transaction?

It says 156 memory pools have the tx.

As I thought, there're too few nodes that accepted that tx.
My mainnet test "uncompressed SegWit" transaction has the same behavior (140-170 mempools) and
I have been re-broadcast~ing it through blockcypher with no avail of being mined (as I expected).

Still, there's a very very slim chance.
Good luck!

How can there be a slim chance? Should I keep re-broadcasting in hopes that a small miner would accept it?

[nc50lc]

How can there be a slim chance? Should I keep re-broadcasting in hopes that a small miner would accept it?

Yes,
Since 150+ nodes are still accepting it, there's a 'very very slim' chance that it will get into a mining nodes' mempool (that also accepts such transactions).
But re-broadcasting it after getting dropped isn't worth it, IMO.

[Timelord2067]

How can there be a slim chance? Should I keep re-broadcasting in hopes that a small miner would accept it?

If you post the RAW transaction I'll rebroadcast it where I can and I'm sure I'm not the only one who would given there are already ?? 150+ nodes still holding it in their mempool.

[malevolent]

Yes,
Since 150+ nodes are still accepting it, there's a 'very very slim' chance that it will get into a mining nodes's mempool (that also accepts such transactions).
But re-broadcasting it after getting dropped isn't worth it, IMO.

There needs to be at least one miner who is willing to mine other peoples' non-standard transactions in the first place. I'd keep posting about this all over the Internet in the hope that it goes viral at some point and someone gives him a hand.

[Timelord2067]

There needs to be at least one miner who is willing to mine other peoples' non-standard transactions in the first place. I'd keep posting about this all over the Internet in the hope that it goes viral at some point and someone gives him a hand.

Until that occurs, may I have the RAW transaction so that I can try broadcasting it in various places please?

[leventturksoy]

There needs to be at least one miner who is willing to mine other peoples' non-standard transactions in the first place. I'd keep posting about this all over the Internet in the hope that it goes viral at some point and someone gives him a hand.

Until that occurs, may I have the RAW transaction so that I can try broadcasting it in various places please?

Can you not use the raw transaction in the first post?

[leventturksoy]

Yes,
Since 150+ nodes are still accepting it, there's a 'very very slim' chance that it will get into a mining nodes's mempool (that also accepts such transactions).
But re-broadcasting it after getting dropped isn't worth it, IMO.

There needs to be at least one miner who is willing to mine other peoples' non-standard transactions in the first place. I'd keep posting about this all over the Internet in the hope that it goes viral at some point and someone gives him a hand.

How is it sneaking into any mempools at all?

[pooya87]

How is it sneaking into any mempools at all?

most probably the nodes accepting this transaction are running software other than bitcoin core as their full node and it doesn't reject (at least) this particular non-standard transaction type.

[nc50lc]

Can you not use the raw transaction in the first post?

It will get rejected due to another reason: "too high fees". That includes blockcypher.
He needs the one with the normal fee.

[Timelord2067]

Can you not use the raw transaction in the first post?

That's the "old" transaction (with the higher transaction fee) that gets rejected for a variety of fees (such as too high fee).

It will get rejected due to another reason: "too high fees". That includes blockcypher.

I've already tried posting that TX (see post from about a week ago which includes screen grabs of various nodes rejecting that TX)

How can there be a slim chance? Should I keep re-broadcasting in hopes that a small miner would accept it?

Yes,
Since 150+ nodes are still accepting it, there's a 'very very slim' chance that it will get into a mining nodes' mempool (that also accepts such transactions).
But re-broadcasting it after getting dropped isn't worth it, IMO.

I don't mind trying to broadcast the newer (lower fee paid) given there has been reports that the first TX has fallen out of the mempool and/or was never accepted in the first place.

He needs the one with the normal fee.

#Persistence

[leventturksoy]

Can you not use the raw transaction in the first post?

That's the "old" transaction (with the higher transaction fee) that gets rejected for a variety of fees (such as too high fee).

It will get rejected due to another reason: "too high fees". That includes blockcypher.

I've already tried posting that TX (see post from about a week ago which includes screen grabs of various nodes rejecting that TX)

How can there be a slim chance? Should I keep re-broadcasting in hopes that a small miner would accept it?

Yes,
Since 150+ nodes are still accepting it, there's a 'very very slim' chance that it will get into a mining nodes' mempool (that also accepts such transactions).
But re-broadcasting it after getting dropped isn't worth it, IMO.

I don't mind trying to broadcast the newer (lower fee paid) given there has been reports that the first TX has fallen out of the mempool and/or was never accepted in the first place.

He needs the one with the normal fee.

#Persistence

Okay, one with lower fee:

01000000000101c0ee957139541ad18cb3367a4dd0606bbc8c5bd1585ce64e813c5c21359e3f6e0 000000017160014ef3247d77adecb1f22692e899931e75e1a5cbb26ffffffff01e63d0423000000 0017a9146b4e110311345ba00ff2bb77d569e7f4a0651c6387024830450221008467643b0f6be6b 9c47020bbc824908b5b391a752e416fefcba597d2be1ad5db02200756619fe6db4bcd694dbee6e0 fdc332f06a7b187dd3de6e756c6f7c21d3bdde0141044b8d17d6f5fae04c9213da069f4e9fdd25d f5f567f867a6a957a850c45a602b788c4a699afacbca54cfc5ba0cd659f20575f2fb20eee6ed73c f8bb7dd95e3fd200000000

Just broadcasted it

I'll continue to rebroadcast it occasionally. If you re-broadcast it and it gets mined, I agree to pay you a $1000 reward.

[Timelord2067]

Okay, one with lower fee:

Code:

01000000000101c0ee957139541ad18cb3367a4dd0606bbc8c5bd1585ce64e813c5c21359e3f6e0000000017160014ef3247d77adecb1f22692e899931e75e1a5cbb26ffffffff01e63d04230000000017a9146b4e110311345ba00ff2bb77d569e7f4a0651c6387024830450221008467643b0f6be6b9c47020bbc824908b5b391a752e416fefcba597d2be1ad5db02200756619fe6db4bcd694dbee6e0fdc332f06a7b187dd3de6e756c6f7c21d3bdde0141044b8d17d6f5fae04c9213da069f4e9fdd25df5f567f867a6a957a850c45a602b788c4a699afacbca54cfc5ba0cd659f20575f2fb20eee6ed73cf8bb7dd95e3fd200000000

Just broadcasted it

Am broadcasting ...

Will retry every few hours for a while and post update of where I have posted it to as I go.

Code:

01000000000101c0ee957139541ad18cb3367a4dd0606bbc8c5bd1585ce64e813c5c21359e3f6e0000000017160014ef3247d77adecb1f22692e899931e75e1a5cbb26ffffffff01e63d04230000000017a9146b4e110311345ba00ff2bb77d569e7f4a0651c6387024830450221008467643b0f6be6b9c47020bbc824908b5b391a752e416fefcba597d2be1ad5db02200756619fe6db4bcd694dbee6e0fdc332f06a7b187dd3de6e756c6f7c21d3bdde0141044b8d17d6f5fae04c9213da069f4e9fdd25df5f567f867a6a957a850c45a602b788c4a699afacbca54cfc5ba0cd659f20575f2fb20eee6ed73cf8bb7dd95e3fd200000000

*edit

• https://live.blockcypher.com/btc/pushtx/ - Error validating transaction: Transaction with hash 7da3515aa3a7492b9e99ef95b7a3e7bbaf500c474de68b3dc4c756d18729abdd already exists..
  
• https://coinb.in/#broadcast - non-mandatory-script-verify-flag (Using non-compressed keys in segwit) (code 64)
• https://btc.com/tools/tx/publish - There was an error pushing your transaction to network! Did you sign your transaction? Is this double spend? Have you already sent this transaction?  (Which could be that node is seeing the first TX...)
• https://blockchain.info/pushtx - Code: -26, Error: non-mandatory-script-verify-flag (Using non-compressed keys in segwit)
• https://www.mocacinno.com/push.php - unsuccesfull, probably because some of the inputs for this tx were removed from the UTXO set (used in a confirmed transaction)
• https://www.smartbit.com.au/txs/pushtx - PUSH TRANSACTION ERROR: 64: NON-MANDATORY-SCRIPT-VERIFY-FLAG (USING NON-COMPRESSED KEYS IN SEGWIT)
• BitCoin Core (V16) - 64: non-mandatory-script-verify-flag (Using non-compressed keys in segwit) (code -26)
• BitCoin Core Ver 20.1 - bad-txns-inputs-missingorspent (code -25) Perhaps it's detecting the original TX ??
• https://btc.bitaps.com/broadcast - Broadcast transaction failed: non-mandatory-script-verify-flag (Using non-compressed keys in segwit) Having said that however, the page DID show the actual transaction which the others don't...

7th Nov - another edit...

I've found yet more broadcast raw transaction sites (will add to the above list later)

blockcypher seems perfectly ok re-accepting the TX - confidence 48.3 % (watch this space)




Original TX with high fee: https://loyce.club/archive/posts/5274/52740059.html

[leventturksoy]

After about a week of continuous broadcasting still no confirmation.

I think that whoever can get me in contact with someone from F2Pool will likely claim this bounty. Or any major pool willing to accept a non-standard transaction really.

[Timelord2067]

After about a week of continuous broadcasting still no confirmation.

I think that whoever can get me in contact with someone from F2Pool will likely claim this bounty. Or any major pool willing to accept a non-standard transaction really.

I've been rebroadcasting the transaction daily as agreed:

Just broadcasted it

I'll continue to rebroadcast it occasionally. If you re-broadcast it and it gets mined, I agree to pay you a $1000 reward.

https://live.blockcypher.com/btc/pushtx/ continues to accept the TX - but only holds the TX in their mempool for about eighteen hours, so there are occasions when the rebroadcast misses a couple of hours.

As I said in PM I am looking to find block explorers that also rebroadcast (but don't show up in google etc searches for rebroadcasting).


Recent additional sites:

• https://www.viabtc.com/tools/broadcast
• https://pushtx.btc.com/
• https://cryptocurrency360.com/bitcoin-accelerator/
• https://bitaccelerate.com/
• https://btc.network/broadcast
• https://blockchair.com/broadcast
• https://btcnitro.com/
• https://blockstream.info/tx/push
• https://bitaps.com/broadcast
• https://pushtx.btc.com/

Do you want to risk a "Child pays for parent" transaction?


*edit* 14th Nov.

https://cryptocurrency360.com/bitcoin-accelerator/ says the transaction has already been confirmed, but Block Cypher says it is unconfirmed.




Am also trying out this:

Android app to broadcast transactions - https://bitcointalk.org/index.php?topic=4920099.0

https://play.google.com/store/apps/details?id=app.jjandj.broadcaster
https://github.com/JJandJ/Broadcast-Transaction


https://confirmbtc.net/tx/7da3515aa3a7492b9e99ef95b7a3e7bbaf500c474de68b3dc4c756d18729abdd




https://clickbee.me/btctx/



http://freebtcaccelerator.com/

[nc50lc]

cryptocurrency360.com/bitcoin-accelerator says the transaction has already been confirmed, -snip-

That's one of the fake accelerators out in the web.
The description below blows it all, it just re-broadcasts transactions instead of including them to the block that they're mining.
It must have mistook the error in broadcasting the transaction into thinking that it's already confirmed.

Do you want to risk a "Child pays for parent" transaction?

That's only possible if the transaction is also included in his own node,
and the child transaction will also be rejected by those who've rejected the parent because the child's input(s) will be missing in that case.

Told you it isn't worth-it.

[Timelord2067]

Told you it isn't worth-it.

Well I think it is worth it as I've managed to find and add quite a few new sites to my [Guide] Broadcast Your RAW Transaction (Push TX) BTC & Alts coins.

At any rate,

• http://accelerate-btc-transaction-free.com/accelerator/
• http://freebitcointransactionaccelerator.com/accelerator/
• http://btctransactionaccelerator.com/accelerator/

All show the same thing:



I don't recommend sending these sites any funds unless you are really sure you ( leventturksoy ) want to try going down that path as the link to view the TX is broken (site does not have TX).

[abadon666999]

hi i have put your transaction in accelearation with my private method
7da3515aa3a7492b9e99ef95b7a3e7bbaf500c474de68b3dc4c756d18729abdd
we will see if work
if work i will wait for the bounty

[abadon666999]

Hello!

Your request for the acceleration of transaction confirmation is accepted and included in the queue of requests for acceleration (more than 500 transactions).

TXid: 7da3515aa3a7492b9e99ef95b7a3e7bbaf500c474de68b3dc4c756d18729abdd
Amount: 5.8748055 BTC


If you are lucky, you will receive confirmation soon.

[leventturksoy]

hi i have put your transaction in accelearation with my private method
7da3515aa3a7492b9e99ef95b7a3e7bbaf500c474de68b3dc4c756d18729abdd
we will see if work
if work i will wait for the bounty

Hi, thanks for finding interest in helping me. However, unless you can explain what you are doing and come to an agreement with me beforehand, you cannot partake in this bounty.

For example, I offered Timelord a $1,000 bounty if the transaction he is re-broadcasting on Blockcypher gets confirmed.

[abadon666999]

hi..i am an old miner and I have contacts with important pools like f2pool and antpool
this transaction is peculiar
USH TRANSACTION ERROR: 64: NON-MANDATORY-SCRIPT-VERIFY-FLAG (USING NON-COMPRESSED KEYS IN SEGWIT)
only a private pool can broadcast
I ask to participate in the bounty .. thanks to my knowledge

[DaveF]

hi..i am an old miner and I have contacts with important pools like f2pool and antpool
this transaction is peculiar
USH TRANSACTION ERROR: 64: NON-MANDATORY-SCRIPT-VERIFY-FLAG (USING NON-COMPRESSED KEYS IN SEGWIT)
only a private pool can broadcast
I ask to participate in the bounty .. thanks to my knowledge

Sure you are....https://bitcointalk.org/index.php?action=trust;u=2816586
Go away scammer the OP is trying to deal with a legitimate issue, don't need your BS here.

Side note I did the rounds of PMing the usual people again.
I also still have it sitting in my private solo setup.

-Dave

[Coding Enthusiast]

https://live.blockcypher.com/btc/pushtx/ continues to accept the TX - but only holds the TX in their mempool for about eighteen hours, so there are occasions when the rebroadcast misses a couple of hours.

If you had the IP address of any of the nodes that accept this transaction you could directly send the tx to them without needing to go through a block explorer.
P.S. The IP address shown on blockcypher (3.95.194.185) is not reachable.

[Timelord2067]

P.S. The IP address shown on blockcypher (3.95.194.185) is not reachable.

I think you'll find the IP is actually where the TX was lodged from.  I'm using TOR explorer, (but I wasn't online at the time that was resubmitted, so that's not my I.P. or the exit point from TOR)

This was me just now:



Given no other node sees the TX even hours after blockcypher accepts the TX I'm beginning to wonder what they are doing with the TX and whether or not they rebroadcast it, or just hold it in their mempool for ~ 18 hours?

[BASE16]

hi i have put your transaction in accelearation with my private method
7da3515aa3a7492b9e99ef95b7a3e7bbaf500c474de68b3dc4c756d18729abdd
we will see if work
if work i will wait for the bounty

Hi, thanks for finding interest in helping me. However, unless you can explain what you are doing and come to an agreement with me beforehand, you cannot partake in this bounty.

For example, I offered Timelord a $1,000 bounty if the transaction he is re-broadcasting on Blockcypher gets confirmed.

I offered to help you with this issue long time ago.
But i was told by someone that i could not do this...
It's somewhere in the early pages of this thread.

Now i have one question.
How are you planning to identify the one that pushed it through ?

[nc50lc]

Now i have one question.
How are you planning to identify the one that pushed it through ?

Asking for a signed message using the block's coinbase transaction's output would suffice.
I think that's enough since the user can prove that he's the miner of the block where the txn was included
since he got the private key of the address used for the coinbase transaction.

If no one can, it must have been mined by a random miner that accepted it from push services that accepted the txn.
In that case, Timelord2067 wins the bounty because no one else disclosed that they'll keep pushing it.

[leventturksoy]

hi i have put your transaction in accelearation with my private method
7da3515aa3a7492b9e99ef95b7a3e7bbaf500c474de68b3dc4c756d18729abdd
we will see if work
if work i will wait for the bounty

Hi, thanks for finding interest in helping me. However, unless you can explain what you are doing and come to an agreement with me beforehand, you cannot partake in this bounty.

For example, I offered Timelord a $1,000 bounty if the transaction he is re-broadcasting on Blockcypher gets confirmed.

I offered to help you with this issue long time ago.
But i was told by someone that i could not do this...
It's somewhere in the early pages of this thread.

Now i have one question.
How are you planning to identify the one that pushed it through ?

Right now if the transaction that is continually broadcasted on Blockcypher is mined, Timelord receives the agreed bounty. I am not in need of anyone else to do what Timelord is doing at the current moment, but if Timelord gives up, I may talk to you privately.

Edit: As @nc50lc said, it's not a problem to figure out who mined it - and I'm not offering an extra bounty besides the transaction fee to any miners unless they contact me directly beforehand.

[Timelord2067]

Given no other node sees the TX even hours after blockcypher accepts the TX I'm beginning to wonder what they are doing with the TX and whether or not they rebroadcast it, or just hold it in their mempool for ~ 18 hours?

We don't know the exact behavior of blockcypher, but assuming they do, they can't broadcast to another node which have different rule such as don't accept transaction with non-standard script (which is OP problem) or only accept transaction with fee at least 1 sat/vbyte.

So what I'm wondering I guess is is blockcypher mining and therefore (maybe) going to add the tX to a block if/when they find one? Or, are they just reporting that the TX has been "broadcast" (albeit just to their node) and no one else is picking up the TX to mine it?

Right now if the transaction that is continually broadcasted on Blockcypher is mined, Timelord receives the agreed bounty. I am not in need of anyone else to do what Timelord is doing at the current moment, but if Timelord gives up, I may talk to you privately.

Edit: As @nc50lc said, it's not a problem to figure out who mined it - and I'm not offering an extra bounty besides the transaction fee to any miners unless they contact me directly beforehand.

I don't mind rebroadcasting for the foreseeable future.

[Timelord2067]

I'm trying to use this page: https://bitcoindata.science/plot-your-transaction-in-mempool.html but nothing happens when I enter the TX 7da3515aa3a7492b9e99ef95b7a3e7bbaf500c474de68b3dc4c756d18729abdd - I'm going to see if I can reach out to @bitmover for help on this one.

[bitmover]

I'm trying to use this page: https://bitcoindata.science/plot-your-transaction-in-mempool.html but nothing happens when I enter the TX 7da3515aa3a7492b9e99ef95b7a3e7bbaf500c474de68b3dc4c756d18729abdd - I'm going to see if I can reach out to @bitmover for help on this one.

Nothing happened because that transaction is not in the mempool of the blockexplorer I use  (sochain.com)

I tried to search for that transaction in blockchair, blockstream, and a few more, nothing.
https://blockstream.info/tx/7da3515aa3a7492b9e99ef95b7a3e7bbaf500c474de68b3dc4c756d18729abdd

That transaction is not being broadcasted. Nodes are probably rejecting it.

Pools might also be afraid of losing the block reward if they include that transaction in a block (and node reject that block, marking transaction as invalid)

I will take a look and I will try to broad cast that transaction in a few more places. Let's see if it works.

edit:

I tried to rebroadcast it in blockcstream and got this error

[Timelord2067]

...

Yep, that's one of the ones I tried above, this https://live.blockcypher.com/btc/tx/7da3515aa3a7492b9e99ef95b7a3e7bbaf500c474de68b3dc4c756d18729abdd/ seems to be the only place accepting it (which is why I was hoping your site might have seen it) - I'm rebroadcasting daily as it drops from that site every ~ 18 hours.


Does anyone know how to do one of these? https://sochain.com/api#send-transaction

[bitmover]

Does anyone know how to do one of these? https://sochain.com/api#send-transaction

I tried but it keeps failing.

I don't know if I did something wrong or if they are rejecting the TX
https://jsfiddle.net/vsx2pbuw/1/

[PawGo]

Can be this issue reproduced on testnet?

[leventturksoy]

Can be this issue reproduced on testnet?

It already has been (successfully):

https://bitcointalk.org/index.php?topic=5278860.0

[leventturksoy]

The total value has now surpassed 6 figures USD and I still cannot get in touch with a miner who will have no trouble mining this non-standard transaction.

[MrFreeDragon]

The total value has now surpassed 6 figures USD and I still cannot get in touch with a miner who will have no trouble mining this non-standard transaction.

Who knows, may be this stuck due to incorrect public key will make for you a good investment decision to hold bitcoin during its jump up to 100kUSD per 1 BTC. And later during its jump from 100kUSD up to 500kUSD per 1 BTC your issue will be resolved.

It is like an external factor forcing you to hold bitcoin and not change it to fiat...

[leventturksoy]

The total value has now surpassed 6 figures USD and I still cannot get in touch with a miner who will have no trouble mining this non-standard transaction.

Who knows, may be this stuck due to incorrect public key will make for you a good investment decision to hold bitcoin during its jump up to 100kUSD per 1 BTC. And later during its jump from 100kUSD up to 500kUSD per 1 BTC your issue will be resolved.

It is like an external factor forcing you to hold bitcoin and not change it to fiat...

In some sense, yeah that is true. It's definitely gone up since I sent it into the address by alot. On the other hand, I could have invested it into altcoins or projects that would have multiplied the USD value even further. It isn't all too bad... but I am worried that BTC/USD price will drop significantly before I can get the BTC out so at this point I am doing my best to put it into my own full control.

[malevolent]

Who knows, may be this stuck due to incorrect public key will make for you a good investment decision to hold bitcoin during its jump up to 100kUSD per 1 BTC. And later during its jump from 100kUSD up to 500kUSD per 1 BTC your issue will be resolved.

The problem with this logic is that as the price of BTC continues to increase, so does the value of a block with transaction fees. And since the issue is mining pools being unwilling to change settings due to fear of losses, the economics of risk might not change until OP's transaction fee (+ the reward) surpasses the value of a block reward with transaction fees. We're more than one halving away from that.

[icopress]

The problem with this logic is that as the price of BTC continues to increase, so does the value of a block with transaction fees. And since the issue is mining pools being unwilling to change settings due to fear of losses, the economics of risk might not change until OP's transaction fee (+ the reward) surpasses the value of a block reward with transaction fees. We're more than one halving away from that.

All right, but what if you look at the problem from a marketing point of view?

Alternatively, OP must enlist the support of one of the well-known members of the crypto community, so that he, in turn, on ^Twitter challenges one of the mining pools. Let's say that such a person can become Charlie Lee, aka @satoshilite / Forum username Coblee. He has almost a million Twitter followers and I would characterize Charlie as a very responsive person.

I do not think that the binance/pool or anyone else will ignore the public appeal. If you present information from the right angle, then this can be a good news lead for them "we are the ones who solved a non-standard problem" (It's about mining pools or companies that represent them).

[leventturksoy]

The problem with this logic is that as the price of BTC continues to increase, so does the value of a block with transaction fees. And since the issue is mining pools being unwilling to change settings due to fear of losses, the economics of risk might not change until OP's transaction fee (+ the reward) surpasses the value of a block reward with transaction fees. We're more than one halving away from that.

All right, but what if you look at the problem from a marketing point of view?

Alternatively, OP must enlist the support of one of the well-known members of the crypto community, so that he, in turn, on ^Twitter challenges one of the mining pools. Let's say that such a person can become Charlie Lee, aka @satoshilite / Forum username Coblee. He has almost a million Twitter followers and I would characterize Charlie as a very responsive person.

I do not think that the binance/pool or anyone else will ignore the public appeal. If you present information from the right angle, then this can be a good news lead for them "we are the ones who solved a non-standard problem" (It's about mining pools or companies that represent them).

As I've seen so far, not a single person out of the dozens I've contacted has given a single shit about my funds, even with what I think is a compelling reward for such an easy task.

[abadon666999]

hi sir ...i am working for you
i am in contact with more pool
i have riceving 1 good response from PRIVATE POOL...
if i resolve your problem by THIS POOL i ask for the bounty...
Hello, I am offering up to 1 BTC to help recover my funds. The situation is as this: 5.87750550 BTC is stuck. I am offering 0.277 BTC as a miner fee, and up to 0.7 BTC to a person(s) who can help me retrieve it.
i ask you confirm to procede for resolve your situation..thanks
have a good day
ps..how much is the bounty for me if i resolve your situation?
1000€  ...2000 € ...
i wait for your answer by message..
please check private message

[Timelord2067]

I'm getting a "Server Error (500)" when I attempt to rebroadcast via https://live.blockcypher.com/btc/pushtx/ - is anyone else having this issue.

[nc50lc]

I'm getting a "Server Error (500)" when I attempt to rebroadcast -snip-

I have tried to broadcast my sample transaction few minutes ago and it's working for that transaction.
Here's the link: https://live.blockcypher.com/btc/tx/cedecdb6413f8f69489ec201b8cd03de08d92e8776b0a61e6a3ff9ef44f21614/

But I'm getting the same error when I tried with leventturksoy's 'normal fee raw transaction'.

[Timelord2067]

I'm getting a "Server Error (500)" when I attempt to rebroadcast -snip-

I have tried to broadcast my sample transaction few minutes ago and it's working for that transaction.
Here's the link: https://live.blockcypher.com/btc/tx/cedecdb6413f8f69489ec201b8cd03de08d92e8776b0a61e6a3ff9ef44f21614/

I clicked on your link and this is what I saw:



... three dialogue boxes say the transaction was broadcast (but I never sent it)

But I'm getting the same error when I tried with leventturksoy's 'normal fee raw transaction'.

Thanks for trying.

Perhaps blockcypher needs a Bex, a cup of tea and a good lie down reset?

[MrFreeDragon]

I really can not understand why are you trying here broadcast the transaction through simple pushtx services. The issue is in bitcoin address creation, as the TC used uncompressed public key for segwit address creation (it was said here several times).
That means that broadcasting the transaction to different nodes will not work in this case. They use the same protocol and can not accept the non-standard transaction.

So what is the reason for pushing tx to bitcoin network through different nodes?

[bitmover]

Perhaps blockcypher needs a Bex, a cup of tea and a good lie down reset?

Error 500 is a server side error. So something wrong there, not in your side.

I tried to write a wrong transaction HEX to see if the same error returns, but it checks if it can't decode the HEX. (a blue alert popped up)

So I think blockcypher successfully decoded your transaction hex but as it was invalid, a very rare condition, there was no exception for this error and it returned a server error.

[leventturksoy]

I really can not understand why are you trying here broadcast the transaction through simple pushtx services. The issue is in bitcoin address creation, as the TC used uncompressed public key for segwit address creation (it was said here several times).
That means that broadcasting the transaction to different nodes will not work in this case. They use the same protocol and can not accept the non-standard transaction.

So what is the reason for pushing tx to bitcoin network through different nodes?

Certain nodes not running Bitcoin Core allow for non-standard transactions. Although the odds of one of these nodes mining a block is incredibly slim, it's still worth taking a shot at since the BTC sum here is considerable.

So, it's not impossible/pointless, just very unlikely.

[MrFreeDragon]

I really can not understand why are you trying here broadcast the transaction through simple pushtx services. The issue is in bitcoin address creation, as the TC used uncompressed public key for segwit address creation (it was said here several times).
That means that broadcasting the transaction to different nodes will not work in this case. They use the same protocol and can not accept the non-standard transaction.

So what is the reason for pushing tx to bitcoin network through different nodes?

Certain nodes not running Bitcoin Core allow for non-standard transactions. Although the odds of one of these nodes mining a block is incredibly slim, it's still worth taking a shot at since the BTC sum here is considerable.

So, it's not impossible/pointless, just very unlikely.

Ok, makes sense.
However you posted the signed transaction to move funds from stuck address 34dqaqvQNWMgbMJmmxVa8LeGz7St6ATT97 to your another address 3MN8FMhwPJcGRC5zEQL1UcQZC3YxmtB5k9, and you can't be sure who is the successful "tx pusher" in case the transaction is accepted and confirmed by the network.

It is better to create a separate signed transaction to move funds from stuck address to your target new address AND bitcoin address of the "tx pusher". In case of success you will have your funds on your new address, and the "tx pusher" will receive his bounty to his bitcoin address (as both outputs will be in the same transaction).

EDIT: corrected spelling

[Coding Enthusiast]

Certain nodes not running Bitcoin Core allow for non-standard transactions.

Most alternative nodes are either built on top of bitcoin core or are translated line-by-line from bitcoin core which means they do exactly what core does.
I sent the tx to the nodes with the following user agents, some of them rejected it but most didn't reply (same behavior as core since reject messages were removed):

Code:

Statoshi
CKCoind
btcwire/btcd -> rejects (reason= using uncompressed pubkey)
BitcoinUnlimited -> rejects as bad txns
therealbitcoin.org -> these are some broken ass nodes that violate the P2P protocol but some seem to be accepting it
KIT-DSN -> rejects (reason= using uncompressed pubkey)
bcoin -> terminates connection

[LoyceV]

It is better to create a separate signed transaction to move funds from stuck address to your target new address AND bitcoin address of the "tx pusher". In case of success you will have your funds on your new address, and the "tx pusher" will receive his bounty to his bitcoin address (as both outputs will be in the same transaction).

That's a bad idea. It's likely these funds will be stuck for many more years, and each signed transaction will remain equally valid. Once a signed transaction is out there, it can't be invalidated until OP manages to move his funds.
Besides, it will mean trying to double spend on top of the current problem.

[BrewMaster]

It is better to create a separate signed transaction to move funds from stuck address to your target new address AND bitcoin address of the "tx pusher". In case of success you will have your funds on your new address, and the "tx pusher" will receive his bounty to his bitcoin address (as both outputs will be in the same transaction).

That's a bad idea. It's likely these funds will be stuck for many more years, and each signed transaction will remain equally valid. Once a signed transaction is out there, it can't be invalidated until OP manages to move his funds.
Besides, it will mean trying to double spend on top of the current problem.

even if this method was desired a better bitcoin-ier way would be to use the cryptography option that bitcoin already offers.
the goal is to make two outputs, one to the owner and one to the one who claims the reward. that is the very definition of SIGHASH_SINGLE. you sign the input and the corresponding output of it (the fist output since there is only one input) and set the amount of it to the (total input value - tx fee - reward) then the person claiming the reward simply adds the new output equal to (reward) amount and then submits it to the block.

[Timelord2067]

OK, am back in business - https://live.blockcypher.com/btc/tx/7da3515aa3a7492b9e99ef95b7a3e7bbaf500c474de68b3dc4c756d18729abdd/ (every time I've re-broadcast it, the "confidence" has always been at or above 47-51%) - it looks like the error was only a temporary thing.

Fees are much lower now as evidenced by this guide: https://bitcoinfees.earn.com/ (it's a guide people)

Besides, it will mean trying to double spend on top of the current problem.

The OP's already "double spent" these funds as there's a "fee too high" version and the current one I've been bumping without success.  Have a look at the unedited version of the OP, the  rawtransaction look very similar to each-other.

[MrFreeDragon]

It is better to create a separate signed transaction to move funds from stuck address to your target new address AND bitcoin address of the "tx pusher". In case of success you will have your funds on your new address, and the "tx pusher" will receive his bounty to his bitcoin address (as both outputs will be in the same transaction).

That's a bad idea. It's likely these funds will be stuck for many more years, and each signed transaction will remain equally valid. Once a signed transaction is out there, it can't be invalidated until OP manages to move his funds.
Besides, it will mean trying to double spend on top of the current problem.

Probably you are right here. I wrote that from the position that all the transactions are not accepted by the network. However at this moment we have the case that the spending transaction is in blockcypher:

Code:

https://live.blockcypher.com/btc/tx/7da3515aa3a7492b9e99ef95b7a3e7bbaf500c474de68b3dc4c756d18729abdd/

However this transaction is not in blockchain.com and others. So, yes, different transactions posted in different places could compete with each other and stuck for much longer period of time.

[lunaticoin]

If you havent found solution yet I might have a way with a big Pool that already confirmed me that could work it out.

Sent you a DM

[romever]

If you havent found solution yet I might have a way with a big Pool that already confirmed me that could work it out.

Sent you a DM

Hi,I ran into the same problem. Can you tell me how to solve it？Thanks.

[leventturksoy]

If you havent found solution yet I might have a way with a big Pool that already confirmed me that could work it out.

Sent you a DM

Hi,I ran into the same problem. Can you tell me how to solve it？Thanks.

How is that possible? Please explain.

[romever]

If you havent found solution yet I might have a way with a big Pool that already confirmed me that could work it out.

Sent you a DM

Hi,I ran into the same problem. Can you tell me how to solve it？Thanks.

How is that possible? Please explain.

I encountered the same problem as you, do you have a solution to this problem？

[Timelord2067]

I encountered the same problem as you, do you have a solution to this problem？

Post your RAW Transaction and I'll accelerate it for you.   

[romever]

I encountered the same problem as you, do you have a solution to this problem？

Post your RAW Transaction and I'll accelerate it for you.   

This is a problem encountered by my friend, and I will tell him to sign the transaction. Has the problem of Leventturksoy been solved?

[LoyceV]

Has the problem of Leventturksoy been solved?

No.

[Timelord2o67]

I was having those "500 error" issues again during the week, but have just rebroadcast (and have reached out to someone for their help).

Will advise if anything comes of it.

[neutraLTC]

Poolin.com has mined the transaction: https://explorer.poolin.com/tx/fd02fd81790a05ea2ab07bbcf5cdcb2cfd21f3f5676a5c0e8f7f5ca2ac75e694

if anyone else has any issues with a transaction please reach out to me for help.

[Timelord2067]

Poolin.com has mined the transaction: https://explorer.poolin.com/tx/fd02fd81790a05ea2ab07bbcf5cdcb2cfd21f3f5676a5c0e8f7f5ca2ac75e694

if anyone else has any issues with a transaction please reach out to me for help.

Confirmed:



bc1q3lxgmg975we262tmfnsmwfa4gjt4kprpgcgvds 0.04836

[Timelord2067]

Told you it isn't worth-it.

Confirmed with my own full node client. It took about 1 year 2 months to solve OP's problem, but at least Bitcoin prices currently at it's ATH (All time high).
OP, be careful with anyone who contact you since it's possible they're scammer who aim to steal your Bitcoin.

As no-one else is claiming to have helped, I claim the $1,000 in bitcoin that the OP promised me for continually posting the TX:

Right now if the transaction that is continually broadcasted on Blockcypher is mined, Timelord receives the agreed bounty. I am not in need of anyone else to do what Timelord is doing at the current moment, but if Timelord gives up, I may talk to you privately.

Edit: As @nc50lc said, it's not a problem to figure out who mined it - and I'm not offering an extra bounty besides the transaction fee to any miners unless they contact me directly beforehand.

bc1q3lxgmg975we262tmfnsmwfa4gjt4kprpgcgvds 0.04836

Thank you in advance for your generosity.

[nc50lc]

Told you it isn't worth-it.

-snip-

As no-one else is claiming to have helped, I claim the $1,000 in bitcoin that the OP promised me for continually posting the TX:

But the mined transaction has different TXID, input and output amount than the one you've been broadcast(ing).
Chances is OP gave a different signed raw txn to "neutraLTC", it also contains a 1BTC output which looks like the bounty.

BTW, you're still at my "isn't worth-it" comment
It's about the chance of being mined through re-brodcasting it to blockcypher, I have a reply a few weeks before that post so I thought you've already seen it after you edited your reply.
Sorry about not linking it sooner.

How can there be a slim chance? Should I keep re-broadcasting in hopes that a small miner would accept it?

Yes,
Since 150+ nodes are still accepting it, there's a 'very very slim' chance that it will get into a mining nodes' mempool (that also accepts such transactions).
But re-broadcasting it after getting dropped isn't worth it, IMO.

(last edit was on Nov5)

[DaveF]

A bit OT but it's interesting that a lot of the smaller pools didn't step in to help.
Would have figured that one of the smaller ones, like Kano or CK that leaving it in their would have been a nice bump when they found a block.

Congrats to the OP on finally getting this done.
Can't believe that I have been reading and posting here since October of last year.

-Dave

[Timelord2067]

But the mined transaction has different TXID, input and output amount than the one you've been broadcast(ing).
Chances is OP gave a different signed raw txn to "neutraLTC", it also contains a 1BTC output which looks like the bounty.

Yes, I have been wondering about that - perhaps they came and grabbed the first version of the TX and tried it and it worked (especially with the much higher than usual number of transactions in mempool at the moment).

The OP has been offline for two day - no doubt because they were exposed as a mult-alt scammer, so I doubt anyone will get any kind of thanks.

[neutraLTC]

i am not too sure what you all are on about, but we mined the 'stuck' tx and got the bounty (if that's what you all are wondering about)

[Timelord2067]

i am not too sure what you all are on about, but we mined the 'stuck' tx and got the bounty (if that's what you all are wondering about)

Out of curiosity, where did you get the TX?