[~1 BTC Bounty]

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