Help needed spending non-standard multisig outputs from Counterparty transaction

[nutildah]

Hi chat,

I need some big brained input on this one. I am trying to spend the multisig outputs from this transaction (I have hundreds like it and the end goal is to collect all of them, which is >$1k in BTC):

https://mempool.space/tx/ed2d8fbedc5860092ae7d72aeb0d81b31d5560f39a90692e83d0cdfef82295d8

I managed to "vibe code" my way to a broadcast-able transaction that spends the 2 outputs to the address of origin, but I received the following error on Electrum and other push tx services:

"bad-txns-inputs-missingorspent"

(I know they are unspent b/c I used a service in 2014 to redeem a bunch of similar outputs; that transaction is here).

I tried recreating the transaction for the network to recognize that multisig outputs are being spent, and now I get this error:

"scriptsig-not-pushonly"

Something to keep in mind is that this is a "fake multisig" transaction, meaning it just requires 1 of 2 signatures; the 1st public key comes from my address and the 2nd public key is fake.

This is the service I used to create the multisig output consolidation transaction in 2014, but it is no longer functioning:

http://redeem.bitwatch.co/

They even have a thread on this forum.

So my question is, if I paste the raw hex tx here, could you tell me why the transaction is being rejected?

An easier question to answer might be is there a push tx service for non-standard transactions? I'm not sure if they exist, but would be good to know if one is out there.

Thanks for your help.

[Skjadoon]

Hi chat,

I need some big brained input on this one. I am trying to spend the multisig outputs from this transaction (I have hundreds like it and the end goal is to collect all of them, which is >$1k in BTC):

https://mempool.space/tx/ed2d8fbedc5860092ae7d72aeb0d81b31d5560f39a90692e83d0cdfef82295d8

I managed to "vibe code" my way to a broadcast-able transaction that spends the 2 outputs to the address of origin, but I received the following error on Electrum and other push tx services:

"bad-txns-inputs-missingorspent"

(I know they are unspent b/c I used a service in 2014 to redeem a bunch of similar outputs; that transaction is here).

I tried recreating the transaction for the network to recognize that multisig outputs are being spent, and now I get this error:

"scriptsig-not-pushonly"

Something to keep in mind is that this is a "fake multisig" transaction, meaning it just requires 1 of 2 signatures; the 1st public key comes from my address and the 2nd public key is fake.

This is the service I used to create the multisig output consolidation transaction in 2014, but it is no longer functioning:

http://redeem.bitwatch.co/

They even have a thread on this forum.

So my question is, if I paste the raw hex tx here, could you tell me why the transaction is being rejected?

An easier question to answer might be is there a push tx service for non-standard transactions? I'm not sure if they exist, but would be good to know if one is out there.

Thanks for your help.

Only way: run your own node with non-standard TXs allowed, or pay a miner to include it.

[nutildah]

Only way: run your own node with non-standard TXs allowed, or pay a miner to include it.

Trust me if I had Bitcoin Core on my computer I would have tried it. I can't help but think there's a way to do it through a push tx service. And I wouldn't want to pay a miner to include it if its malformed, which may be the case. I tried doing it through here:

https://bitaccelerate.com/pushtx/

which says this at the bottom:

"This service is using the "sendrawtransaction" method of the Bitcoin Core client. Your transaction must be signed and must not contain unconfirmed inputs."

But still got an error.

For reference, this is the unsigned transaction, would be grateful if someone could analyze it and tell me if something is wrong:

Code:

0100000002d89522f8fecd0d83e269909af360551db3810deb2ad7e72a096058dcbe8f2ded0000000000ffffffffd89522f8fecd0d83e269909af360551db3810deb2ad7e72a096058dcbe8f2ded0100000000ffffffff01382d0000000000001976a914fc11decd0e0ab7a332459314069c027328e1dde188ac00000000

This is the error I get from blockstream.info/tx/push when attempting to broadcast the signed transaction:

"sendrawtransaction RPC error -25: bad-txns-inputs-missingorspent"

[LoyceV]

This is the service I used to create the multisig output consolidation transaction in 2014, but it is no longer functioning:
http://redeem.bitwatch.co/

To ask the obvious: have you tried emailing dexx@?

This project has served very well, but lost it's purpose, given that it is no longer economic to redeem dust-ish outputs, it costs more to retrieve the dust.

This was probably written when Bitcoin prices were much lower. It might be worth resurrecting the service.

[ABCbits]

For reference, this is the unsigned transaction, would be grateful if someone could analyze it and tell me if something is wrong:

Code:

0100000002d89522f8fecd0d83e269909af360551db3810deb2ad7e72a096058dcbe8f2ded0000000000ffffffffd89522f8fecd0d83e269909af360551db3810deb2ad7e72a096058dcbe8f2ded0100000000ffffffff01382d0000000000001976a914fc11decd0e0ab7a332459314069c027328e1dde188ac00000000

This is the error I get from blockstream.info/tx/push when attempting to broadcast the signed transaction:

"sendrawtransaction RPC error -25: bad-txns-inputs-missingorspent"

This is decode result using https://live.blockcypher.com/btc/decodetx/

Code:

{
    "addresses": [
        "1PypgzaAJXHzLPvkLQwWzqwn1AyhJd9YUi"
    ],
    "block_height": -1,
    "block_index": -1,
    "confirmations": 0,
    "double_spend": false,
    "fees": 0,
    "hash": "4fdb912af649ec80bb3a13f3d42429d69e2069cbd7880ecf87dccc51f875f7fe",
    "inputs": [
        {
            "age": 0,
            "output_index": 0,
            "prev_hash": "ed2d8fbedc5860092ae7d72aeb0d81b31d5560f39a9069e2830dcdfef82295d8",
            "script_type": "empty",
            "sequence": 4294967295
        },
        {
            "age": 0,
            "output_index": 1,
            "prev_hash": "ed2d8fbedc5860092ae7d72aeb0d81b31d5560f39a9069e2830dcdfef82295d8",
            "script_type": "empty",
            "sequence": 4294967295
        }
    ],
    "outputs": [
        {
            "addresses": [
                "1PypgzaAJXHzLPvkLQwWzqwn1AyhJd9YUi"
            ],
            "script": "76a914fc11decd0e0ab7a332459314069c027328e1dde188ac",
            "script_type": "pay-to-pubkey-hash",
            "value": 11576
        }
    ],
    "preference": "low",
    "received": "2025-07-17T09:28:27.217923583Z",
    "relayed_by": "3.239.97.190",
    "size": 126,
    "total": 11576,
    "ver": 1,
    "vin_sz": 2,
    "vout_sz": 1,
    "vsize": 126
}

prev_hash inside inputs refer to output from TXID you're trying to spend. But TXID ed2d8fbedc5860092ae7d72aeb0d81b31d5560f39a9069e2830dcdfef82295d8 isn't exist on Bitcoin blockchain (according to few Bitcoin block explorer). So you're trying to spend non-existent Bitcoin.

[nutildah]

But TXID ed2d8fbedc5860092ae7d72aeb0d81b31d5560f39a9069e2830dcdfef82295d8 isn't exist on Bitcoin blockchain (according to few Bitcoin block explorer). So you're trying to spend non-existent Bitcoin.

Hey, good catch! You're absolutely right. I fixed it and this is the proper tx, I'm pretty sure:

Code:

0100000002d89522f8fecdd0832e69909af360551db3810deb2ad7e72a096058dcbe8f2ded0000000000ffffffffd89522f8fecdd0832e69909af360551db3810deb2ad7e72a096058dcbe8f2ded0100000000ffffffff01382d0000000000001976a914fc11decd0e0ab7a332459314069c027328e1dde188ac00000000

A couple of the numbers were in reverse order, so I fixed them to match the tx in question.

Now I've graduated to the next error: "RPC error -26: bad-txns-nonstandard-inputs"

 

I guess I need someone running a custom version of Bitcoin to push the transaction through for me...

In any case, thanks, I would have never thought to decode the TX to double-check everything was in order.

To ask the obvious: have you tried emailing dexx@?

Guess I'll do that now...


Edit:

Some transactions from Counterparty were created with invalid public keys and are no longer redeemable.

See also: https://github.com/bitcoin/bitcoin/issues/5939

Oh...

[ABCbits]

I fixed it and this is the proper tx, I'm pretty sure:

Code:

0100000002d89522f8fecdd0832e69909af360551db3810deb2ad7e72a096058dcbe8f2ded0000000000ffffffffd89522f8fecdd0832e69909af360551db3810deb2ad7e72a096058dcbe8f2ded0100000000ffffffff01382d0000000000001976a914fc11decd0e0ab7a332459314069c027328e1dde188ac00000000

Edit:

Some transactions from Counterparty were created with invalid public keys and are no longer redeemable.

See also: https://github.com/bitcoin/bitcoin/issues/5939

Oh...

Yeah, UTXO you try to spend (based on new raw TX) is recognized by several Counterparty explorer. See those,
https://www.xcp.io/tx/ed2d8fbedc5860092ae7d72aeb0d81b31d5560f39a90692e83d0cdfef82295d8
https://www.tokenscan.io/tx/ed2d8fbedc5860092ae7d72aeb0d81b31d5560f39a90692e83d0cdfef82295d8

Now I've graduated to the next error: "RPC error -26: bad-txns-nonstandard-inputs"

 

I guess I need someone running a custom version of Bitcoin to push the transaction through for me...

For different case of non-standard (but valid) TX, what you need is miner who're willing to to add such TX. Other pool may do it if you contact them, while MARA currently being the only one who offer such service (MARA Slipstream) in automated way.

[Cricktor]

As ABCbits says, if your redeem transaction is valid but only non-standard, you could try to submit your transaction via slipstream.mara.com. They say they accept non-standard transactions which other nodes won't relay and thus hardly can reach any miners mempool.

The Slipstream service might impose other restrictions to non-standard transactions and I haven't used it to submit non-standard transactions because I don't need to. You pay a higher fee rate than normal, but it's quite reasonable and especially now when mempool isn't much full at all.

It would be the goto method for me if I had a non-standard transaction or a transaction that I don't want to be seen in public until it is actually confirmed and mined into a block.

[flatfly]

Not sure if you're aware of this, but your tx has an empty scriptsig, maybe that's the issue.

(Just a wild guess)

[nutildah]

Here's an interesting update & a puzzle for anyone who appreciates spotting the differences between different types of transactions. I managed to consolidate & spend some of the outputs thanks to a new Counterparty wallet feature.

Here's an example consolidation tx:

https://mempool.space/tx/17579e4d114a20678f4b869544f606437a053a2618bf11f721cc008e7db5c67d

Here's an example of a multisig output that is consolidate-able:

https://mempool.space/tx/646c03331f9ffd3d95da80896164fbf4bed2c68efc0bc646dd3146f2942f004b#vout=0

And here's some examples of multisig outputs that are not (not recognized by the wallet as such, anyway):

https://mempool.space/tx/cf747d954ea20775dc4cca2e8336dfb64a82c596afdc2e52d939677308f05486#vout=0
https://mempool.space/tx/3cf38a4fdfb47908567e276a42db1d6c18f2c3280acc24f3595f54b4fc5e5e6d#vout=0
https://mempool.space/tx/d15b15a956166447893b2f2c8849b9d2892fea0fc24bbedf74b246816025bea0#vout=0
https://mempool.space/tx/b9297449020c0eaae35e2ab38744ed59ad928300a909de2b8242c9196805ac23#vout=0

I have also prepared this post to share with the developer so maybe he can also shed some light on how the wallet logic works.

Not sure if you're aware of this, but your tx has an empty scriptsig, maybe that's the issue.

(Just a wild guess)

Right I left it out on purpose, I forget what my exact reasoning was at the time.

[nutildah]

I managed to figure out how to spend more "bare multisig" outputs, but some still cannot be spent. I am persistently met with this message in Electrum:

'Imported_Wallet' object has no attribute 'add_unspent_tx'

Using other broadcast services yield something along the lines of "bad tx input missing or spent".

I've learned this is because Bitcoin Core by default does not include my outputs, which are nonstandard multisig outputs, in their tx sets. The outputs exist but aren't being tracked by most nodes.

It appears running Core is the only way. Its unfortunate I can't just teach Electrum about where the missing inputs come from.

(I applied for a code to use MARA Slipstream but who knows if they'll respond).

Any other recommendations would be greatly appreciated.

[nc50lc]

Using other broadcast services yield something along the lines of "bad tx input missing or spent".
-snip-
It appears running Core is the only way. Its unfortunate I can't just teach Electrum about where the missing inputs come from.

Is this related to your reply in "permitbaremultisig" topic in Dev board?

I've checked the first one of your "not recognized" bare MultiSig output and it has a non-canonical public key.
However, the other 3 transactions' outputs look standard with permitbaremultisig "true" default setting.

Can you try to create another consolidation transaction but exclude cf747d954ea20775dc4cca2e8336dfb64a82c596afdc2e52d939677308f05486:1 from the original input if it'll result with the same error?

[nutildah]

In any case, thanks, I would have never thought to decode the TX to double-check everything was in order.

I should have been using AI to help me solve this problem back then. That was like a whole year wasted, but at least I still have these coins.

Some transactions from Counterparty were created with invalid public keys and are no longer redeemable.

It turns out they are theoretically redeemable if its a 1-of-3 multisig, which is all of these trapped outputs.

I've checked the first one of your "not recognized" bare MultiSig output and it has a non-canonical public key.
However, the other 3 transactions' outputs look standard with permitbaremultisig "true" default setting.

Can you try to create another consolidation transaction but exclude cf747d954ea20775dc4cca2e8336dfb64a82c596afdc2e52d939677308f05486:1 from the original input if it'll result with the same error?

So I just tried vout=0 for this one, using the same method I've managed to push a few stuck outputs through before, broadcasting via blockstream's service. It came back with the same error:

"sendrawtransaction RPC error -25: bad-txns-inputs-missingorspent"

But if you look at the output, its unspent. I should be able to harvest these somehow.

[nc50lc]

"sendrawtransaction RPC error -25: bad-txns-inputs-missingorspent"

Hmm, still the same error despite them having the transaction in their blockexplorer which is based from their node.
Unless this is an issue with wrongly sent error of "bad-txns-inputs-missingorspent" which is less likely the cause,
this may be an issue with how the transaction is constructed, similar to the initial issue in the OP.
It might have one wrong/missing/extra byte(s) or something that makes the referenced input incorrect.

Try to use decoderawtransaction on an the signed raw transaction and check if its inputs are correct in this case.
You can use an offline fresh Bitcoin Core for that command (you don't have to sync it)

[nutildah]

"sendrawtransaction RPC error -25: bad-txns-inputs-missingorspent"

Hmm, still the same error despite them having the transaction in their blockexplorer which is based from their node.
Unless this is an issue with wrongly sent error of "bad-txns-inputs-missingorspent" which is less likely the cause,
this may be an issue with how the transaction is constructed, similar to the initial issue in the OP.
It might have one wrong/missing/extra byte(s) or something that makes the referenced input incorrect.

Try to use decoderawtransaction on an the signed raw transaction and check if its inputs are correct in this case.
You can use an offline fresh Bitcoin Core for that command (you don't have to sync it)

Since you've been kind enough to attempt to help me, which I do appreciate, I should let you know I had a mistake in my last script. I corrected it, and the new broadcast result is

sendrawtransaction RPC error -26: bad-txns-nonstandard-inputs

This is slightly different from the above. They are no longer "missing or spent", just "nonstandard".

Here is what I am including in the transaction:

Code:

TXID = "cf747d954ea20775dc4cca2e8336dfb64a82c596afdc2e52d939677308f05486"
VOUT = 1
AMOUNT_SATS = 7800

# Destination: 1AaALA67rJEL2BoMRgKZFMbtA99schMZju

OUTPUT = {
    "amount": 7600,  # example: 7800 - 200 fee
    "script_pubkey_hex": "76a9146f0c7f7a8c2d2f6c6b4e0c8e2f0a5a3c9a8f3f0e88ac",}

# Bare multisig scriptPubKey for this UTXO
SCRIPT_PUBKEY_HEX = ("51210241a4702fe43c3e113b656e84be80444d1c2c2dc18c807c811d8ba45722505fed211c434e54525052545900000000000000000000000100000000013154100000000052ae")

When I try to broadcast it on other services, I get errors like "unable to parse transaction" before it gets to the broadcast phase.

I'm gonna try a few other scenarios with different output structures.

[ertil]

Let's try it in regtest, step-by-step. First, create some empty wallet:

Code:

createwallet "regtest" false true

Then, let's import some multisig, where the first private key is known, and in the second key, we know only the public key, which may be even fake:

Code:

importdescriptors '[{"desc":"multi(1,cMahea7zqjxrtgAbB7LSGbcQUr1uX1ojuat9jZodMN87JcbXMTcA,020000000000000000000000000000000000000000000000000000000000000001)#rexugqgy","timestamp":"now"}]'
[
  {
    "success": true,
    "warnings": [
      "Not all private keys provided. Some wallet functionality may return unexpected errors"
    ]
  }
]
listdescriptors
{
  "wallet_name": "regtest",
  "descriptors": [
    {
      "desc": "multi(1,0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798,020000000000000000000000000000000000000000000000000000000000000001)#h75m0gz8",
      "timestamp": 1296688602,
      "active": false
    }
  ]
}

Now, let's try to generate some regtest coins, to have something to spend:

Code:

generatetodescriptor 101 "multi(1,0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798,020000000000000000000000000000000000000000000000000000000000000001)#h75m0gz8"

And now, we need to extract the previous transaction, where our coins are stored:

Code:

getblockhash 1
54e1513fc56d8c05e34694fd0cee1db96dcad488c4cf27dd8f37944c5499a306
getblockheader 54e1513fc56d8c05e34694fd0cee1db96dcad488c4cf27dd8f37944c5499a306 false
0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fdc620565fe3b180ed1714eb33cfab9a1ed4901fd459fd1cfe18423af982aee444c58096affff7f2002000000
getblock 54e1513fc56d8c05e34694fd0cee1db96dcad488c4cf27dd8f37944c5499a306 0
0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fdc620565fe3b180ed1714eb33cfab9a1ed4901fd459fd1cfe18423af982aee444c58096affff7f200200000001020000000001010000000000000000000000000000000000000000000000000000000000000000ffffffff025100feffffff0200f2052a010000004751210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f817982102000000000000000000000000000000000000000000000000000000000000000152ae0000000000000000266a24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf90120000000000000000000000000000000000000000000000000000000000000000000000000
decoderawtransaction 020000000001010000000000000000000000000000000000000000000000000000000000000000ffffffff025100feffffff0200f2052a010000004751210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f817982102000000000000000000000000000000000000000000000000000000000000000152ae0000000000000000266a24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf90120000000000000000000000000000000000000000000000000000000000000000000000000
{
  "txid": "44ee2a98af2384e1cfd19f45fd0149eda1b9fa3cb34e71d10e183bfe650562dc",
  "hash": "f37790e9ecb5599f013c57d139ee7628c73368caa270d91d294c681d6c725dc8",
  "version": 2,
  "size": 216,
  "vsize": 189,
  "weight": 756,
  "locktime": 0,
  "vin": [
    {
      "coinbase": "5100",
      "txinwitness": [
        "0000000000000000000000000000000000000000000000000000000000000000"
      ],
      "sequence": 4294967294
    }
  ],
  "vout": [
    {
      "value": 50.00000000,
      "n": 0,
      "scriptPubKey": {
        "asm": "1 0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798 020000000000000000000000000000000000000000000000000000000000000001 2 OP_CHECKMULTISIG",
        "desc": "multi(1,0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798,020000000000000000000000000000000000000000000000000000000000000001)#h75m0gz8",
        "hex": "51210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f817982102000000000000000000000000000000000000000000000000000000000000000152ae",
        "type": "multisig"
      }
    },
    {
      "value": 0.00000000,
      "n": 1,
      "scriptPubKey": {
        "asm": "OP_RETURN aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf9",
        "desc": "raw(6a24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf9)#cav96mf3",
        "hex": "6a24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf9",
        "type": "nulldata"
      }
    }
  ]
}

Now, we can create a transaction, which will move our coins to any destination.

Code:

createrawtransaction '[{"txid":"44ee2a98af2384e1cfd19f45fd0149eda1b9fa3cb34e71d10e183bfe650562dc","vout":0}]' '[{"bcrt1pfeesnyr2tx":49.99999000}]' 0 true
0200000001dc620565fe3b180ed1714eb33cfab9a1ed4901fd459fd1cfe18423af982aee440000000000fdffffff0118ee052a010000000451024e7300000000

And we can sign it with our wallet:

Code:

signrawtransactionwithwallet "0200000001dc620565fe3b180ed1714eb33cfab9a1ed4901fd459fd1cfe18423af982aee440000000000fdffffff0118ee052a010000000451024e7300000000" '[{"txid":"44ee2a98af2384e1cfd19f45fd0149eda1b9fa3cb34e71d10e183bfe650562dc","vout":0,"scriptPubKey":"51210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f817982102000000000000000000000000000000000000000000000000000000000000000152ae","amount":50.00000000}]'
{
  "hex": "0200000001dc620565fe3b180ed1714eb33cfab9a1ed4901fd459fd1cfe18423af982aee4400000000490047304402200c433a66ae77701849190c67b85cb612c59983a5327782786e8ad98ccac5137102205643c1df8cf3ba588b6028bc1796591656d24efe22be6c1890fe54bae207eaf401fdffffff0118ee052a010000000451024e7300000000",
  "complete": true
}

Now, it is ready to be broadcasted, so we can do that from some website, or send it from our own node:

Code:

sendrawtransaction 0200000001dc620565fe3b180ed1714eb33cfab9a1ed4901fd459fd1cfe18423af982aee4400000000490047304402200c433a66ae77701849190c67b85cb612c59983a5327782786e8ad98ccac5137102205643c1df8cf3ba588b6028bc1796591656d24efe22be6c1890fe54bae207eaf401fdffffff0118ee052a010000000451024e7300000000
af081c1291acfaa49ebbac2255cbcae80ae7ac7b9ef6c0bf1575903c5d23e0bb

And now, we can confirm it, by mining next regtest blocks on top of it:

Code:

generatetodescriptor 6 "multi(1,0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798,020000000000000000000000000000000000000000000000000000000000000001)#h75m0gz8"

As we can see, it is now confirmed and valid:

Code:

getblockhash 102
1d06dc484d2c1c72f11debf59ecbe87fc94f7031094799d0ca5bfb3c4ff2c0d8
getblock 1d06dc484d2c1c72f11debf59ecbe87fc94f7031094799d0ca5bfb3c4ff2c0d8
{
  "hash": "1d06dc484d2c1c72f11debf59ecbe87fc94f7031094799d0ca5bfb3c4ff2c0d8",
  "confirmations": 6,
  "height": 102,
  "version": 536870912,
  "versionHex": "20000000",
  "merkleroot": "5f33d116ec41df2bbf9cc7ff3f011cf5fbdf5ac62316d0363656156a516c960c",
  "time": 1778998101,
  "mediantime": 1778997341,
  "nonce": 0,
  "bits": "207fffff",
  "target": "7fffff0000000000000000000000000000000000000000000000000000000000",
  "difficulty": 4.656542373906925e-10,
  "chainwork": "00000000000000000000000000000000000000000000000000000000000000ce",
  "nTx": 2,
  "previousblockhash": "6563fc8c9372f8d6b9bc4f6341f14e8888d6c34be3d589bd81055559c105435a",
  "nextblockhash": "785e3d95df47841507e5f55ec2fdd5e69c33be24cc08b2d22fd52b381b3d34a6",
  "strippedsize": 399,
  "size": 435,
  "weight": 1632,
  "coinbase_tx": {
    "version": 2,
    "locktime": 101,
    "sequence": 4294967294,
    "coinbase": "016600",
    "witness": "0000000000000000000000000000000000000000000000000000000000000000"
  },
  "tx": [
    "260b7e2d0cd02188c92aefb331d931f723c4d82d52955a54f95596d90c67c159",
    "af081c1291acfaa49ebbac2255cbcae80ae7ac7b9ef6c0bf1575903c5d23e0bb"
  ]
}

Now, you can try to repeat the same steps, and tell us, where is the problem. When it comes to "signrawtransactionwithwallet" command, it should be able to sign any transaction you want, even if you don't have the blockchain. It trusts you completely, so if you import some key, and tell Bitcoin Core, that you want to sign an input with 50 coins, or even something that doesn't exist, then it will do exactly what you will type, and sign it with your key. So, it is better to test it on some dummy keys in regtest, or any public testnet first, and then repeat the same thing on mainnet, when you will know exactly, how it works.

Also, I guess if these scripts will work, then it can be automated to execute the same commands for more coins, or include more inputs in the same transaction.

[stwenhao]

I think I can see the problem: if a public key starts from 02 or 03, then it is just a multisig. But if it starts from anything else than that, and there is some 32-byte value, then it is non-standard, and you won't get it mined, without some support from the miners.

For example: this is non-standard:

Code:

decodescript 51210326512b7899648ea87a7301d52bbd95e87c11213fbb7908e683357526061e00242120434e5452505254590000000a0000000000062fac000000000034ee3a0000000052ae
{
  "asm": "1 0326512b7899648ea87a7301d52bbd95e87c11213fbb7908e683357526061e0024 20434e5452505254590000000a0000000000062fac000000000034ee3a00000000 2 OP_CHECKMULTISIG",
  "desc": "raw(51210326512b7899648ea87a7301d52bbd95e87c11213fbb7908e683357526061e00242120434e5452505254590000000a0000000000062fac000000000034ee3a0000000052ae)#gtxnjsj7",
  "type": "nonstandard",
  "p2sh": "3MrcLTm5dY13A8TpiZTMWvdNwVHJJoADvP",
  "segwit": {
    "asm": "0 eca6e4a77e63ac037ebb221b329f25972cf9055ded3af483f19856a3098d0915",
    "desc": "addr(bc1qajnwffm7vwkqxl4mygdn98e9juk0jp2aa5a0fql3npt2xzvdpy2sr38jjj)#v7yu54sh",
    "hex": "0020eca6e4a77e63ac037ebb221b329f25972cf9055ded3af483f19856a3098d0915",
    "address": "bc1qajnwffm7vwkqxl4mygdn98e9juk0jp2aa5a0fql3npt2xzvdpy2sr38jjj",
    "type": "witness_v0_scripthash",
    "p2sh-segwit": "3AsMicPhMMXyNLCManGgXBmjoxgeYVrweB"
  }
}

And if you flip a single byte, then it is multisig:

Code:

decodescript 51210326512b7899648ea87a7301d52bbd95e87c11213fbb7908e683357526061e00242102434e5452505254590000000a0000000000062fac000000000034ee3a0000000052ae
{
  "asm": "1 0326512b7899648ea87a7301d52bbd95e87c11213fbb7908e683357526061e0024 02434e5452505254590000000a0000000000062fac000000000034ee3a00000000 2 OP_CHECKMULTISIG",
  "desc": "multi(1,0326512b7899648ea87a7301d52bbd95e87c11213fbb7908e683357526061e0024,02434e5452505254590000000a0000000000062fac000000000034ee3a00000000)#5ftlncs0",
  "type": "multisig",
  "p2sh": "38LmBLn5sQxAqHZJzKCu2SCqC3b75ECnQY",
  "segwit": {
    "asm": "0 580ecf2284b32eaa01d9480d1788d0f4f2943ceec0cfbeb69dd233415d914619",
    "desc": "wsh(multi(1,0326512b7899648ea87a7301d52bbd95e87c11213fbb7908e683357526061e0024,02434e5452505254590000000a0000000000062fac000000000034ee3a00000000))#w2kmqm50",
    "hex": "0020580ecf2284b32eaa01d9480d1788d0f4f2943ceec0cfbeb69dd233415d914619",
    "address": "bc1qtq8v7g5ykvh25qwefqx30zxs7nefg08wcr8mad5a6ge5zhv3gcvsl6d9j6",
    "type": "witness_v0_scripthash",
    "p2sh-segwit": "33s123bwKfxYwKoeQtX5wo2DTrTzdDFfAJ"
  }
}

See the difference? When Bitcoin Core will tell you "nonstandard", instead of "multisig", then it means you won't get that kind of multisig, without the help from some miners. Which also means, that mempool.space marks it differently than Bitcoin Core, and shows MULTISIG in cases, where maybe it shouldn't.

[Cricktor]

If you need to get a non-standard transaction mined, you can use https://slipstream.mara.com for a very modest transaction fee rate.

The only thing that really pisses me off now with the current state of MARA's Slipstream service is that they require you to apply for a client code and their responsiveness is, um, how to put it politely, with room for improvements.

[nutildah]

Let's try it in regtest, step-by-step. First, create some empty wallet:

Thanks, I appreciate all that, but I don't have Bitcoin Core. I am doing everything with a python script. That in itself could be the potential problem, but perhaps not.

I think I can see the problem: if a public key starts from 02 or 03, then it is just a multisig. But if it starts from anything else than that, and there is some 32-byte value, then it is non-standard, and you won't get it mined, without some support from the miners.
...
See the difference? When Bitcoin Core will tell you "nonstandard", instead of "multisig", then it means you won't get that kind of multisig, without the help from some miners. Which also means, that mempool.space marks it differently than Bitcoin Core, and shows MULTISIG in cases, where maybe it shouldn't.

Yes, I think I get it now. I will need to have the transaction included by a miner that accepts nonstandard transactions for any output that comes from a transaction with a fake public key.

If you need to get a non-standard transaction mined, you can use https://slipstream.mara.com for a very modest transaction fee rate.

The only thing that really pisses me off now with the current state of MARA's Slipstream service is that they require you to apply for a client code and their responsiveness is, um, how to put it politely, with room for improvements.

Yeah I applied for a code a couple weeks back and haven't heard anything.

[nc50lc]

-snip-

Here is what I am including in the transaction:

Code:

TXID = "cf747d954ea20775dc4cca2e8336dfb64a82c596afdc2e52d939677308f05486"
VOUT = 1

This is the UTXO that has "non-canonical public key" that I've mentioned you to exclude in my first reply.
Your blockexplorer link points to vout=0 but it's P2PKH, so it's safe to assume that you're referring to the unspent MultiSig output.

It's soft-locked by getting non-standard by an old bare MultiSig update so I instructed you to spend the other three that looks standard instead.