Bitcoin Forum

I'm referring to this tx: https://blockchain.info/tx/2ee6d8ea223e118075882edba876f01b30f407eb6c6d31c40bd6664a17f20f0c

The problem I see is that the scriptSig necessary to redeem it must contain 16 identical copies of signatures. The result will be over 1KB and thus the scriptSig length field (a varint) will be using the 3-byte long format ("fd 04 90").

I tried to push such a tx to a few places such as blockchain.info, coinb.in, and webbtc.com/relay_tx, but all of the report "parsing error".

I'm pretty sure the parsing error is caused by the 3-byte varint format for scriptSig length (for example if I only include 3 copies of signatures then the scriptSig will be shorter than 0xfd bytes and thus using the 1-byte short varint format, then I'll get "invalid signature" error instead of a parsing error).

can you post the raw transaction here?

Error messages from those services tend to suck badly.

Speaking from experience, I will say that writing a varint handler for a parser is easy, and I'd be amazed if more than one of those sites got it wrong.  More likely, they are passing it to bitcoind, which is rejecting it based on the IsStandard() check, and they simply report all errors as "parsing error"s.

But please post the raw transaction here so that we can check it.

https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L519
https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L3962

Are you going over the size limits?

Thanks! Yes each signature requires 0x49 (105) bytes of scriptSig. 16 copies would exceed the limit.

On the other hand the 16 signatures are identical. But OP_DUP is disallowed in scriptSig.

So it looks like that tx is unredeemable.

except that non-standard does not mean unredeemable

well isn't it effectively unredeemable if no nodes will relay your tx?

of course if I control a pool or own some significant hashrate maybe that isn't such a problem.

https://en.bitcoin.it/wiki/Free_transaction_relay_policy

Thank you very much!!! I've been able to relay non-standard raw tx to eligius.

Just got this 2-in-16 multisig solved:  ;D ;D

https://blockchain.info/tx/18f4c7059be729fb48d014d2a4a0658a8ba1d35798d42274691a117da91643b5

here is 20-of-20 solved (not by me unfortunately)

https://blockchain.info/tx/c4aaf7fbec7a9a079e670e50f6a672315451c7618814494ab1f89cf3fd97b3bb

WTH this is obviously way above the max scriptSig size... not even eligius accepts it  ???

So here's my solution to the 16-of-16 multisig... I know it is non-standard but the signature check should pass... but I'm simply getting "TX decode error" even from the Lightfood Hosting's node.

Anyone can tell what's wrong with this?

JSON:

{
    "hash": "51cbbcb7cf833b1406661d29f0c1a5f80c544b3bb1c28a9abba1881fd42f2df7",
    "ver": 1,
    "vin_sz": 1,
    "vout_sz": 1,
    "lock_time": 0,
    "in": [
        {
            "prev_out": {
                "hash": "2ee6d8ea223e118075882edba876f01b30f407eb6c6d31c40bd6664a17f20f0c",
                "n": "0"
            },
            "scriptSig": "OP_FALSE 3046022100c9d96032febdad642be00284ddfe71d9c42ee8b1111cecbb3086bcbfd756a77402210 0cc448b0546ba2a7f7fc454d743a213ce7afd771dfc7ef4d9456790fcb9af5ecf01 3046022100c9d96032febdad642be00284ddfe71d9c42ee8b1111cecbb3086bcbfd756a77402210 0cc448b0546ba2a7f7fc454d743a213ce7afd771dfc7ef4d9456790fcb9af5ecf01 3046022100c9d96032febdad642be00284ddfe71d9c42ee8b1111cecbb3086bcbfd756a77402210 0cc448b0546ba2a7f7fc454d743a213ce7afd771dfc7ef4d9456790fcb9af5ecf01 3046022100c9d96032febdad642be00284ddfe71d9c42ee8b1111cecbb3086bcbfd756a77402210 0cc448b0546ba2a7f7fc454d743a213ce7afd771dfc7ef4d9456790fcb9af5ecf01 3046022100c9d96032febdad642be00284ddfe71d9c42ee8b1111cecbb3086bcbfd756a77402210 0cc448b0546ba2a7f7fc454d743a213ce7afd771dfc7ef4d9456790fcb9af5ecf01 3046022100c9d96032febdad642be00284ddfe71d9c42ee8b1111cecbb3086bcbfd756a77402210 0cc448b0546ba2a7f7fc454d743a213ce7afd771dfc7ef4d9456790fcb9af5ecf01 3046022100c9d96032febdad642be00284ddfe71d9c42ee8b1111cecbb3086bcbfd756a77402210 0cc448b0546ba2a7f7fc454d743a213ce7afd771dfc7ef4d9456790fcb9af5ecf01 3046022100c9d96032febdad642be00284ddfe71d9c42ee8b1111cecbb3086bcbfd756a77402210 0cc448b0546ba2a7f7fc454d743a213ce7afd771dfc7ef4d9456790fcb9af5ecf01 3046022100c9d96032febdad642be00284ddfe71d9c42ee8b1111cecbb3086bcbfd756a77402210 0cc448b0546ba2a7f7fc454d743a213ce7afd771dfc7ef4d9456790fcb9af5ecf01 3046022100c9d96032febdad642be00284ddfe71d9c42ee8b1111cecbb3086bcbfd756a77402210 0cc448b0546ba2a7f7fc454d743a213ce7afd771dfc7ef4d9456790fcb9af5ecf01 3046022100c9d96032febdad642be00284ddfe71d9c42ee8b1111cecbb3086bcbfd756a77402210 0cc448b0546ba2a7f7fc454d743a213ce7afd771dfc7ef4d9456790fcb9af5ecf01 3046022100c9d96032febdad642be00284ddfe71d9c42ee8b1111cecbb3086bcbfd756a77402210 0cc448b0546ba2a7f7fc454d743a213ce7afd771dfc7ef4d9456790fcb9af5ecf01 3046022100c9d96032febdad642be00284ddfe71d9c42ee8b1111cecbb3086bcbfd756a77402210 0cc448b0546ba2a7f7fc454d743a213ce7afd771dfc7ef4d9456790fcb9af5ecf01 3046022100c9d96032febdad642be00284ddfe71d9c42ee8b1111cecbb3086bcbfd756a77402210 0cc448b0546ba2a7f7fc454d743a213ce7afd771dfc7ef4d9456790fcb9af5ecf01 3046022100c9d96032febdad642be00284ddfe71d9c42ee8b1111cecbb3086bcbfd756a77402210 0cc448b0546ba2a7f7fc454d743a213ce7afd771dfc7ef4d9456790fcb9af5ecf01 3046022100c9d96032febdad642be00284ddfe71d9c42ee8b1111cecbb3086bcbfd756a77402210 0cc448b0546ba2a7f7fc454d743a213ce7afd771dfc7ef4d9456790fcb9af5ecf01",
            "sequence": 4294967295
        }
    ],
    "out": [
        {
            "value": "0.00450000",
            "scriptPubKey": "OP_DUP OP_HASH160 7140b351f972295e98759a02c8f074bb7fd0c84b OP_EQUALVERIFY OP_CHECKSIG"
        }
    ]
}

Raw TX:

01000000010c0ff2174a66d60bc4316d6ceb07f4301bf076a8db2e887580113e22ead8e62e00000 000fd04a100493046022100c9d96032febdad642be00284ddfe71d9c42ee8b1111cecbb3086bcbf d756a774022100cc448b0546ba2a7f7fc454d743a213ce7afd771dfc7ef4d9456790fcb9af5ecf0 1493046022100c9d96032febdad642be00284ddfe71d9c42ee8b1111cecbb3086bcbfd756a77402 2100cc448b0546ba2a7f7fc454d743a213ce7afd771dfc7ef4d9456790fcb9af5ecf01493046022 100c9d96032febdad642be00284ddfe71d9c42ee8b1111cecbb3086bcbfd756a774022100cc448b 0546ba2a7f7fc454d743a213ce7afd771dfc7ef4d9456790fcb9af5ecf01493046022100c9d9603 2febdad642be00284ddfe71d9c42ee8b1111cecbb3086bcbfd756a774022100cc448b0546ba2a7f 7fc454d743a213ce7afd771dfc7ef4d9456790fcb9af5ecf01493046022100c9d96032febdad642 be00284ddfe71d9c42ee8b1111cecbb3086bcbfd756a774022100cc448b0546ba2a7f7fc454d743 a213ce7afd771dfc7ef4d9456790fcb9af5ecf01493046022100c9d96032febdad642be00284ddf e71d9c42ee8b1111cecbb3086bcbfd756a774022100cc448b0546ba2a7f7fc454d743a213ce7afd 771dfc7ef4d9456790fcb9af5ecf01493046022100c9d96032febdad642be00284ddfe71d9c42ee 8b1111cecbb3086bcbfd756a774022100cc448b0546ba2a7f7fc454d743a213ce7afd771dfc7ef4 d9456790fcb9af5ecf01493046022100c9d96032febdad642be00284ddfe71d9c42ee8b1111cecb b3086bcbfd756a774022100cc448b0546ba2a7f7fc454d743a213ce7afd771dfc7ef4d9456790fc b9af5ecf01493046022100c9d96032febdad642be00284ddfe71d9c42ee8b1111cecbb3086bcbfd 756a774022100cc448b0546ba2a7f7fc454d743a213ce7afd771dfc7ef4d9456790fcb9af5ecf01 493046022100c9d96032febdad642be00284ddfe71d9c42ee8b1111cecbb3086bcbfd756a774022 100cc448b0546ba2a7f7fc454d743a213ce7afd771dfc7ef4d9456790fcb9af5ecf014930460221 00c9d96032febdad642be00284ddfe71d9c42ee8b1111cecbb3086bcbfd756a774022100cc448b0 546ba2a7f7fc454d743a213ce7afd771dfc7ef4d9456790fcb9af5ecf01493046022100c9d96032 febdad642be00284ddfe71d9c42ee8b1111cecbb3086bcbfd756a774022100cc448b0546ba2a7f7 fc454d743a213ce7afd771dfc7ef4d9456790fcb9af5ecf01493046022100c9d96032febdad642b e00284ddfe71d9c42ee8b1111cecbb3086bcbfd756a774022100cc448b0546ba2a7f7fc454d743a 213ce7afd771dfc7ef4d9456790fcb9af5ecf01493046022100c9d96032febdad642be00284ddfe 71d9c42ee8b1111cecbb3086bcbfd756a774022100cc448b0546ba2a7f7fc454d743a213ce7afd7 71dfc7ef4d9456790fcb9af5ecf01493046022100c9d96032febdad642be00284ddfe71d9c42ee8 b1111cecbb3086bcbfd756a774022100cc448b0546ba2a7f7fc454d743a213ce7afd771dfc7ef4d 9456790fcb9af5ecf01493046022100c9d96032febdad642be00284ddfe71d9c42ee8b1111cecbb 3086bcbfd756a774022100cc448b0546ba2a7f7fc454d743a213ce7afd771dfc7ef4d9456790fcb 9af5ecf01ffffffff01d0dd0600000000001976a9147140b351f972295e98759a02c8f074bb7fd0 c84b88ac00000000

You have "fd 04 a1", while it should be LSB: "fd a1 04"

try this:

Thanks! Unfortunately this means the signature will be invalid because the same endianness problem exists in my TX serialization code (for the prev tx scriptPubKey).

I'll go back fuddling my script a bit and try again (if nobody else claims it).

Ok I have fixed the endianness issue with VarInts. Now I have a tx that is accepted by http://webbtc.com/relay_tx, but it reports that no other nodes will relay it ("Transaction has been relayed and propagated through approximately 0.00% of the network.")

Other portals such as http://blockchain.info/pushtx and https://coinb.in/send-raw-transaction.html both reject the TX as invalid. Also, manually send this to the bigfoot's server (bitcoind -addnode=192.3.11.20 sendrawtransaction [tx]) gets a rejected (error code 22). Any ideas?

Here it is:

01000000010c0ff2174a66d60bc4316d6ceb07f4301bf076a8db2e887580113e22ead8e62e00000 000fd910400483045022100b80cb9c9b069601e0557c22b0bddcca7018f83d4b29ec236c6a01fc4 a2e25e7f02206970e6d2080d771c198286da5894fd7da41f270c5d6be6d3fc2fddd3ea105572014 83045022100b80cb9c9b069601e0557c22b0bddcca7018f83d4b29ec236c6a01fc4a2e25e7f0220 6970e6d2080d771c198286da5894fd7da41f270c5d6be6d3fc2fddd3ea10557201483045022100b 80cb9c9b069601e0557c22b0bddcca7018f83d4b29ec236c6a01fc4a2e25e7f02206970e6d2080d 771c198286da5894fd7da41f270c5d6be6d3fc2fddd3ea10557201483045022100b80cb9c9b0696 01e0557c22b0bddcca7018f83d4b29ec236c6a01fc4a2e25e7f02206970e6d2080d771c198286da 5894fd7da41f270c5d6be6d3fc2fddd3ea10557201483045022100b80cb9c9b069601e0557c22b0 bddcca7018f83d4b29ec236c6a01fc4a2e25e7f02206970e6d2080d771c198286da5894fd7da41f 270c5d6be6d3fc2fddd3ea10557201483045022100b80cb9c9b069601e0557c22b0bddcca7018f8 3d4b29ec236c6a01fc4a2e25e7f02206970e6d2080d771c198286da5894fd7da41f270c5d6be6d3 fc2fddd3ea10557201483045022100b80cb9c9b069601e0557c22b0bddcca7018f83d4b29ec236c 6a01fc4a2e25e7f02206970e6d2080d771c198286da5894fd7da41f270c5d6be6d3fc2fddd3ea10 557201483045022100b80cb9c9b069601e0557c22b0bddcca7018f83d4b29ec236c6a01fc4a2e25 e7f02206970e6d2080d771c198286da5894fd7da41f270c5d6be6d3fc2fddd3ea10557201483045 022100b80cb9c9b069601e0557c22b0bddcca7018f83d4b29ec236c6a01fc4a2e25e7f02206970e 6d2080d771c198286da5894fd7da41f270c5d6be6d3fc2fddd3ea10557201483045022100b80cb9 c9b069601e0557c22b0bddcca7018f83d4b29ec236c6a01fc4a2e25e7f02206970e6d2080d771c1 98286da5894fd7da41f270c5d6be6d3fc2fddd3ea10557201483045022100b80cb9c9b069601e05 57c22b0bddcca7018f83d4b29ec236c6a01fc4a2e25e7f02206970e6d2080d771c198286da5894f d7da41f270c5d6be6d3fc2fddd3ea10557201483045022100b80cb9c9b069601e0557c22b0bddcc a7018f83d4b29ec236c6a01fc4a2e25e7f02206970e6d2080d771c198286da5894fd7da41f270c5 d6be6d3fc2fddd3ea10557201483045022100b80cb9c9b069601e0557c22b0bddcca7018f83d4b2 9ec236c6a01fc4a2e25e7f02206970e6d2080d771c198286da5894fd7da41f270c5d6be6d3fc2fd dd3ea10557201483045022100b80cb9c9b069601e0557c22b0bddcca7018f83d4b29ec236c6a01f c4a2e25e7f02206970e6d2080d771c198286da5894fd7da41f270c5d6be6d3fc2fddd3ea1055720 1483045022100b80cb9c9b069601e0557c22b0bddcca7018f83d4b29ec236c6a01fc4a2e25e7f02 206970e6d2080d771c198286da5894fd7da41f270c5d6be6d3fc2fddd3ea1055720148304502210 0b80cb9c9b069601e0557c22b0bddcca7018f83d4b29ec236c6a01fc4a2e25e7f02206970e6d208 0d771c198286da5894fd7da41f270c5d6be6d3fc2fddd3ea10557201ffffffff010053070000000 0001976a9147140b351f972295e98759a02c8f074bb7fd0c84b88ac00000000

Other than the part that directly checks for less than four multisigs in a tx, how do I ensure that I will relay nonstandard (but valid) transactions without getting banned from other nodes?

I've modified my bitcoind to accept non-standard but valid tx and I've also modified the config file to connect directly to 192.3.11.20 node.

It seems my tx got accepted into the local memory pool. How do I tell if it has been propagated to any other nodes?

uminatsu, push it to Eligius.

mustyoshi, you shouldn't get banned for relaying non-standard transactions. If you are, that's a bug.

Nope I've already tried to push it to Eligius (eligius.st/~wizkid057/newstats/pushtxn.php) but got a error -22. Is it possible to manually add a node IP:port to my bitcoin.conf?

This is absolutely a valid TX... my local bitcoind accepts it if I comment out the IsStandardTx check. I believe Eligius only promises to relay certain nonstandard Tx but not necessarily all of them.

I don't think I've been banned yet, but I do think that relaying any valid tx is important for network health, so I want to make sure I don't relay just the standard txs.

Here's a simpler solution to the 16-of-16 multisig. It is valid but again non-standard due to non-push opcodes in the scriptSig.

Again eligius rejected the TX for no explanation. On my local bitcoind the only error is that Tx is not standard (but otherwise it gets accepted into the mempool).  ???

01000000010c0ff2174a66d60bc4316d6ceb07f4301bf076a8db2e887580113e22ead8e62e00000 0005900483045022100d2e8211aa4c5ae6c0bb7c0082e7e76cdb216d6279c11c0bb740e512697db f8ec02205fb2380372d8cc851ec6a54cf054df3c423352c837d50478aa12bbeafe9333730176767 6767676767676767676767676ffffffff0100530700000000001976a9147140b351f972295e9875 9a02c8f074bb7fd0c84b88ac00000000

JSON:

{
    "hash": "54cea54fdafd3b1edc4423b686a5d20d6e2b2602d588d60c24d12c2b6ef7df40",
    "ver": 1,
    "vin_sz": 1,
    "vout_sz": 1,
    "lock_time": 0,
    "size": 224,
    "in": [
        {
            "prev_out": {
                "hash": "2ee6d8ea223e118075882edba876f01b30f407eb6c6d31c40bd6664a17f20f0c",
                "n": "0"
            },
            "scriptSig": "OP_FALSE 3045022100d2e8211aa4c5ae6c0bb7c0082e7e76cdb216d6279c11c0bb740e512697dbf8ec02205 fb2380372d8cc851ec6a54cf054df3c423352c837d50478aa12bbeafe93337301 OP_DUP OP_DUP OP_DUP OP_DUP OP_DUP OP_DUP OP_DUP OP_DUP OP_DUP OP_DUP OP_DUP OP_DUP OP_DUP OP_DUP OP_DUP",
            "sequence": 4294967295
        }
    ],
    "out": [
        {
            "value": "0.00480000",
            "scriptPubKey": "OP_DUP OP_HASH160 7140b351f972295e98759a02c8f074bb7fd0c84b OP_EQUALVERIFY OP_CHECKSIG"
        }
    ]
}

I spotted this around when it was created, I've seen a few spend attempts in the mempool since then, thought someone had got it by now!

Unfortunately no. Maybe Eligius used to accept nonstandard tx in the past (for example the 20-of-20 multisig one in February) but it is definitely rejecting them now.

Without a mining pool to accept nonstandard tx, it would be useless to relay them.

Theoretically there may exist a "standard" tx that can redeem this 16-of-16 multisig using less than the 500-byte limit for scriptSig, but it is very costly to find. The problem is that we only have about 31 bytes per ECDSA signature (so 28 bytes if you remove the ASN.1 DER syntax overhead), but you need 32 bytes to encode the "r" and another 32 bytes to encode the "s". The only way to get a signature that small is to try to find an exponent "k" such that both "r" and "s" are very small.

Yes just use addnode there

How about using OP_2DUP and OP_3DUP to reduce the number of opcodes?

doesn't help because OP_DUP and the like are not push opcodes, so any such scriptSig will fail the IsStandardTx() test.

I need to send this non-standard tx:
010000000147ce0e81fac45653e8f82b4edfb2873c83fc95ee67219a0b2c9a7f9a0020a0c500000 0008b48304502205814f0c588383a38c00b7f9d2317f2aeb2649e60dd341e603b22ae79f334f83c 02210094a35f42d1c9f32ea700e66354ecd457ab2bcf0247865cb037be886569a5ac7f014104227 f4a6de87d345dc08601920c1ab8b9bf4a76868e053f5f90faf307bcf0d72b014be36394a1f8a98b d8f2e5bb2243464fa67eee14e5cfc0888d7f15b7b2a1100c0000000264d31300000000001976a91 4a90cf97578df33b7d261105f3ba7b7297fd3f77d88ac00000000000000001976a9149f27c31c0b f89cb4958e7fc99c0f9117623b4e4b88ac44a70500
is it possible to do it using Eligius pool?

Yes. txid: bc23946a4335370962015d7947e37717568852a83f4b1721ee2a8eed499914a4

I tried to send this tx using this page:
http://eligius.st/~wizkid057/newstats/pushtxn.php
but it doesn't work (it says "Response = 0")

You can see txid just above that.

Try doing it again:

I tried many times, but it doesn't work.
Only this site accepted my transaction:
https://live.blockcypher.com/btc/tx/bc23946a4335370962015d7947e37717568852a83f4b1721ee2a8eed499914a4/
but it doesn't propagate into network.
The main problem with this transaction in that it re-sends 0.0 btc to the input address. I made this transaction sometimes ago using brainwallet, and I've read that this is a common problem of brainwallet (https://bitcointalk.org/index.php?topic=466347.msg5154124#msg5154124). However, there is a txfee, so it may be possible to send this tx in some ways.

Most of the nodes rejects that transaction. So it won't be confirmed. I thought you were just testing. If you want to use that UTXO, create one more transaction. Do you still have the private key?

no, i don't have the private key