Why this transaction cannot be pushed?

[ertil]

Code:

02000000000104f621f4aba4d2eea7198d58b6f08a13c2ecc89c21bad6e58af718d6bab9445926000000001716001491b24bf9f5288532960ac687abb035127b1d28a5fdffffffdc5c73297fe9c5bc8a3485311645c6b754fc75ed3fa1e836d121e31e82f3a6f5000000001716001491b24bf9f5288532960ac687abb035127b1d28a5fdffffffb473c4f3e06ac922835f2b054a39d671d847c2bf9d20fa2f65845358a33aedf3000000001716001491b24bf9f5288532960ac687abb035127b1d28a5fdffffffba7c0607b57302404bd49457355fc87c645d001c2af5bfdbb5062884737b19ca010000001716001491b24bf9f5288532960ac687abb035127b1d28a5fdffffff0180b50100000000001976a9141348f140b223a5d954a04a557b13eef49527920188ac02473044022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f8179802205fe27fe483106c409cbf35dec15a7270dd182448dca878ba3cb483faa6362cc701410479be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b802473044022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f8179802202215a83215bc5b7ebceec69cc86a84b9390cf7c9fcc38cf369ff377bbe78acb601410479be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b802473044022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f8179802203309eeddd2ac9a54e73879a90b570b6ecad7154e66ed2f029f524b2e960655f401410479be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b802473044022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f8179802204794b439c1902d4b9fc93291caa40e4683579845eac642328b1942546f47a5b501410479be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b800000000

The private key is equal to one. However, for 3JvL6Ymt8MVWiCNHC7oWU6nLeHNJKLZGLN it is possible to sweep coins, but for 33q2i3GDkpHFAXnD3UdBsKhxzg7pvwAqtN it cannot be done. Why?

[1715111691]

1715111691

[1715111691]

1715111691

[hosseinimr93]

The private key is equal to one. However, for 3JvL6Ymt8MVWiCNHC7oWU6nLeHNJKLZGLN it is possible to sweep coins, but for 33q2i3GDkpHFAXnD3UdBsKhxzg7pvwAqtN it cannot be done. Why?

I just tried to broadcast the transaction in question using coinb.in and got the following error.
non-mandatory-script-verify-flag (Using non-compressed keys in segwit) (code 64)

If I am not wrong, the transaction isn't standard due to spending bitcoin from a segwit address derived from an uncompressed private key.
The only thing you can do is to contact a mining pool and ask them to include the transaction in a block. (It's very unlikely that any mining pool will accept such a request.)

[nc50lc]

The private key is equal to one. However, for 3JvL6Ymt8MVWiCNHC7oWU6nLeHNJKLZGLN it is possible to sweep coins, but for 33q2i3GDkpHFAXnD3UdBsKhxzg7pvwAqtN it cannot be done. Why?

The reply above is correct.
And to answer this question, 3JvL6Ymt8MVWiCNHC7oWU6nLeHNJKLZGLN is derived from the compressed public key of the private key 0x01
While 33q2i3GDkpHFAXnD3UdBsKhxzg7pvwAqtN is derived from the uncompressed public key.

It's published in BIP143 as the default policy: github.com/bitcoin/bips/blob/master/bip-0143

[LoyceV]

The only thing you can do is to contact a mining pool and ask them to include the transaction in a block. (It's very unlikely that any mining pool will accept such a request.)

The last time I saw a mining pool do this, the owner paid the pool 1 Bitcoin. It looks like no miner is interested into manually adding a transaction for 0.00112653BTC. You can't blame them: if they make a mistake, they risk creating an invalid block.

[LoyceV]

I wonder if they're willing to include OP's transaction at more reasonable cost.

I wouldn't call it "OP's transaction", those 4 inputs came from other users. It makes me wonder what they were thinking: not only using "1" as private key, but also creating Segwit-address in a non-standard way. That can't just be a mistake, so they were planning to lock their (small) funds.

[DaveF]

I wonder if they're willing to include OP's transaction at more reasonable cost.

I wouldn't call it "OP's transaction", those 4 inputs came from other users. It makes me wonder what they were thinking: not only using "1" as private key, but also creating Segwit-address in a non-standard way. That can't just be a mistake, so they were planning to lock their (small) funds.

At a quick look the 1st input was from years ago. It *might* have been the same bug that the other person had. But in the end, it probably does not matter due to the amount involved. As others have said it's not worth blowing a block for under $25 even if BTC goes to $250000 it's still under $300.

OP what wallet were you using? How did you wind up with this? Deliberate thing you did or did it just happen?

-Dave

[LoyceV]

As others have said it's not worth blowing a block for under $25 even if BTC goes to $250000 it's still under $300.

It may become interesting in the far future: 50 years from now, the block reward is about the same as the value held in this address. I'm ignoring uncertain transaction fees in this scenario.

OP what wallet were you using? How did you wind up with this? Deliberate thing you did or did it just happen?

I don't think he used any wallet that produced this, he must have just stumbled upon private key "1".

[Husires]

If I am not wrong, the transaction isn't standard due to spending bitcoin from a segwit address derived from an uncompressed private key.
The only thing you can do is to contact a mining pool and ask them to include the transaction in a block. (It's very unlikely that any mining pool will accept such a request.)

Why does this transaction need to be added manually using mining pool? I know the nodes will reject it because it's non-standard but isn't it after a while it will drop from the mempool and he will be able to rebroadcast it just like it happens with transactions that have very low fees?
Why is the transaction in this example https://bitcointalk.org/index.php?topic=5192454.msg52740059#msg52740059 (~1 BTC Bounty] ) continued for more than a year without being dropped? 

[LoyceV]

Why is the transaction in this example https://bitcointalk.org/index.php?topic=5192454.msg52740059#msg52740059 (~1 BTC Bounty] ) continued for more than a year without being dropped? 

That transaction wasn't in mempool during that year, OP posted a signed transaction with high fee, and later sent a custom transaction in private to whoever included it in the block.

[hosseinimr93]

Why does this transaction need to be added manually using mining pool? I know the nodes will reject it because it's non-standard but isn't it after a while it will drop from the mempool and he will be able to rebroadcast it just like it happens with transactions that have very low fees?

As you said yourself, the transaction OP is referring to isn't standard and nodes will reject it. This means that the transaction doesn't enter the mempool of any node at all.
If a mining pool want to include that transaction, they keep it on their candidate block until they find a block.