Need help with non-standard multisig outputs from Counterparty transaction

Hey everyone, I could really use some smart advice here. I’m trying to spend multisig outputs from this transaction (got hundreds of these and I’m looking to gather them all, which totals over $1k in BTC): https://mempool.space/tx/ed2d8fbedc5860092ae7d72aeb0d81b31d5560f39a90692e83d0cdfef82295d8 I managed to whip up a transaction to spend the 2 outputs back to the original address, but when I tried to push it through Electrum and other services, I got this error: "bad-txns-inputs-missingorspent" I know they’re unspent because I used a service back in 2014 to redeem similar outputs; you can check that transaction here. I tried to rebuild the transaction so the network would see that those multisig outputs are being spent, but I hit another error: "scriptsig-not-pushonly" Just a heads up, this is a "fake multisig" deal, which means it only needs 1 out of 2 signatures; the first public key is from my address, and the second one is made-up. This was the service I used to create the multisig output consolidation back in 2014, but it’s not working anymore: http://redeem.bitwatch.co/ They even had a thread about it here. So my question is, if I drop the raw hex transaction here, could someone help me figure out why it’s being rejected? Also, a simpler question is if there’s any push tx service that can handle non-standard transactions? Not sure if they exist, but it’d be cool to know if there’s one out there. Appreciate the help!

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: 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"

To ask the obvious: have you tried emailing dexx@? This was probably written when Bitcoin prices were much lower. It might be worth resurrecting the service.

This is decode result using https://live.blockcypher.com/btc/decodetx/ 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.

Hey, good catch! You're absolutely right. I fixed it and this is the proper tx, I'm pretty sure: 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. Guess I'll do that now... Edit: 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 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.

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.

Not sure if you're aware of this, but your tx has an empty scriptsig, maybe that's the issue. (Just a wild guess)

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. Right I left it out on purpose, I forget what my exact reasoning was at the time.

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.

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?

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. It turns out they are theoretically redeemable if its a 1-of-3 multisig, which is all of these trapped outputs. 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.

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

Let's try it in regtest, step-by-step. First, create some empty wallet: 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: Now, let's try to generate some regtest coins, to have something to spend: And now, we need to extract the previous transaction, where our coins are stored: Now, we can create a transaction, which will move our coins to any destination. And we can sign it with our wallet: Now, it is ready to be broadcasted, so we can do that from some website, or send it from our own node: And now, we can confirm it, by mining next regtest blocks on top of it: As we can see, it is now confirmed and valid: 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.

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: And if you flip a single byte, then it is multisig: 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.

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.

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. 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. Yeah I applied for a code a couple weeks back and haven't heard anything.

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.