Bitcoin Forum>Bitcoin>Development & Technical Discussion
Author

Topic: Segwit transaction with no witness stack (Read 156 times)

NotATether
legendary
Activity: 1568
Merit: 6660
bitcoincleanup.com / bitmixlist.org
Segwit transaction with no witness stack
July 21, 2023, 08:58:29 AM
#8
Quote from: garlonicon on July 21, 2023, 08:28:41 AM
Witness stack is quite simple:
1. You read the number of elements. If it is zero, that means "no witness elements for this input", and you can just continue, just read the next input.
2. If there is non-zero number of elements, then you parse them one-by-one. First, you get the size of that data, and then you read it.

So, let's say you have a transaction with 3 inputs. You can start from that:
Code:
00 00 00
It means "no witness for each input". And then, let's say you want to have four prime numbers on your stack. You look at Script, and you encode it as "52 53 55 57". The size of the push is one in each case. So, you have this:
Code:
00 04 0152 0153 0155 0157 00
Then, let's say that you want to push one element on the stack for the first input, and put some 32-bit number:
Code:
01 04badc0ded 04 0152 0153 0155 0157 00
See? It is simple. Zero means "next input please", anything else means "start some for loop, and process N elements". And then, for each element, it is just "size+data", it is as simple as that.

That makes much more sense. Thanks!
garlonicon
copper member
Activity: 821
Merit: 1992
Re: Segwit transaction with no witness stack
July 21, 2023, 08:28:41 AM
#7
Witness stack is quite simple:
1. You read the number of elements. If it is zero, that means "no witness elements for this input", and you can just continue, just read the next input.
2. If there is non-zero number of elements, then you parse them one-by-one. First, you get the size of that data, and then you read it.

So, let's say you have a transaction with 3 inputs. You can start from that:
Code:
00 00 00
It means "no witness for each input". And then, let's say you want to have four prime numbers on your stack. You look at Script, and you encode it as "52 53 55 57". The size of the push is one in each case. So, you have this:
Code:
00 04 0152 0153 0155 0157 00
Then, let's say that you want to push one element on the stack for the first input, and put some 32-bit number:
Code:
01 04badc0ded 04 0152 0153 0155 0157 00
See? It is simple. Zero means "next input please", anything else means "start some for loop, and process N elements". And then, for each element, it is just "size+data", it is as simple as that.
NotATether
legendary
Activity: 1568
Merit: 6660
bitcoincleanup.com / bitmixlist.org
Re: Segwit transaction with no witness stack
July 21, 2023, 07:55:54 AM
#6
vjudeu if the 04 in the second line is the number of witness elements, then what is the 00 on the first line supposed to be?   Huh
vjudeu
copper member
Activity: 909
Merit: 2301
Re: Segwit transaction with no witness stack
July 21, 2023, 07:21:55 AM
#5
Quote
Looks like the locktime is at the end but I cannot for the life of me figure out what the rest of these bytes are.
This is quite simple to decode, after looking at the same things many times, I can see the code of the Matrix. Most of it is just public keys and signatures. I don't have a full interpreter to confirm all of that, but roughly, it is something like this:
Code:
00
04                                    //number of witness elements
00                                    //OP_0
473044                                //DER signature
  0220                                  //32-byte number
  2e967a59 7d10db04 d0deae85 f0934f23   //r-value
  c57508a9 a32c96fa 56bf24d7 edda3c3e
  0220                                  //32-byte number
  4bc99802 6334b2d2 3d1dd302 bcc48c39   //s-value
  635b972e 3d27ebec 5ea9579f cac94da9
  01                                    //SIGHASH_ALL
473044                                //DER signature
  0220                                  //32-byte number
  30070dde 2e2342b8 76d9ab9a 7ac827f2   //r-value
  63295d69 14296678 2500fb47 d32c5885
  0220                                  //32-byte number
  69d8cc9d 6e6948de fad031cd ee7dc88b   //s-value
  43beda6c 57d6d36a 99a6c3c5 91662473
  01                                    //SIGHASH_ALL
69                                    //OP_VERIFY
52                                    //OP_2
2102                                  //33-byte public key with 02 prefix
559e7891 00967b07 3b38ab3a c0fc6dea   //x-value of that key
87232598 163146c8 43bc993a 9ee6bca9
2103                                  //33-byte public key with 03 prefix
fb55e972 2a37e8ad 98b00499 b6e9acb3   //x-value of that key
0e75740c 7f259a2e a220a184 248b9bc2
2103                                  //33-byte public key with 03 prefix
348de996 29babc5b 1a95a53f 47b53c6c   //x-value of that key
9527ac83 1b4d9243 d1b96e8f ea765dbb
53                                    //OP_3
ae                                    //OP_CHECKMULTISIG
00
04                                    //number of witness elements
00                                    //OP_0
483045                                //DER signature
  022100                                //33-byte number >= 2^255, with leading zero
  f9f7f9eb 9e8051f3 d936ded8 c99c208d   //r-value
  a130c97d 65782dda 30ef89b5 e098bffe
  0220                                  //32-byte number
  3ded7b23 8c7f7826 bcc16d9e 56d60528   //s-value
  ce670645 a02dedc3 0a977d10 962fa4d6
  01                                    //SIGHASH_ALL
483045                                //DER signature
  022100                                //33-byte number >= 2^255, with leading zero
  e1f29f17 3348edd6 4d3fd55e 18505b69   //r-value
  96a18a12 dcf89040 904a76d8 413c27ad
  0220                                  //32-byte number
  2bad7360 17e60676 7b4f4de0 845e4823   //s-value
  077f0ddb e41476bd 94c1a787 8869bf8d
  01
69                                    //OP_VERIFY
52                                    //OP_2
2102                                  //33-byte public key with 02 prefix
  e3824ce1 7548df1f 0f144b9f 58bfcbaa   //x-value of that key
  abaf6e5e e189c6d0 4fdb1edb b4e58461
2103                                  //33-byte public key with 03 prefix
  b33878f4 2b322c9c 5b8bdde9 279fc730   //x-value of that key
  92d15f42 0f325584 b2b72d1f cfbf14e6
2103                                  //33-byte public key with 03 prefix
  d4c40700 b33dbe84 1f7f8301 12369752   //x-value of that key
  45e38be4 af4da5f4 febbe226 5ac8401d
53                                    //OP_3
ae                                    //OP_CHECKMULTISIG
00
00
00000000                              //locktime
That means, after simplifying things, you could get something like this:
Code:
OP_0 OP_VERIFY
OP_2 OP_3 OP_CHECKMULTISIG
OP_0 OP_VERIFY
OP_2 OP_3 OP_CHECKMULTISIG
But take it with a grain of salt, as I only manually separated things in my notepad, it needs to be confirmed by "decodescript" or "decoderawtransaction" in Bitcoin Core.
NotATether
legendary
Activity: 1568
Merit: 6660
bitcoincleanup.com / bitmixlist.org
Re: Segwit transaction with no witness stack
July 21, 2023, 06:48:15 AM
#4
Quote from: nc50lc on July 20, 2023, 10:50:18 AM
Quote from: NotATether on July 20, 2023, 07:45:17 AM
-snip- appears to have the Segwit flag and marker. But it has a witness count of zero.
Seems like your code is parsing those OP_0 (0x00) of the two 2-of-3 MultiSig p2sh-p2wsh outputs' txinwitness as zero witness stack items instead.
Where it's actually OP_0 [signature1] [signature2] [redeemScript]

It collects all the information about the inputs and outputs correctly. But what are all these bytes doing from position 8300 (0-indexed), immediately after the outputs?

Code:
00040047304402202e967a597d10db04d0deae85f0934f23c57508a9a32c96fa56bf24d7edda3c3e02204bc998026334b2d23d1dd302bcc48c39635b972e3d27ebec5ea9579fcac94da901473044022030070dde2e2342b876d9ab9a7ac827f263295d69142966782500fb47d32c5885022069d8cc9d6e6948defad031cdee7dc88b43beda6c57d6d36a99a6c3c5916624730169522102559e789100967b073b38ab3ac0fc6dea87232598163146c843bc993a9ee6bca92103fb55e9722a37e8ad98b00499b6e9acb30e75740c7f259a2ea220a184248b9bc22103348de99629babc5b1a95a53f47b53c6c9527ac831b4d9243d1b96e8fea765dbb53ae000400483045022100f9f7f9eb9e8051f3d936ded8c99c208da130c97d65782dda30ef89b5e098bffe02203ded7b238c7f7826bcc16d9e56d60528ce670645a02dedc30a977d10962fa4d601483045022100e1f29f173348edd64d3fd55e18505b6996a18a12dcf89040904a76d8413c27ad02202bad736017e606767b4f4de0845e4823077f0ddbe41476bd94c1a7878869bf8d0169522102e3824ce17548df1f0f144b9f58bfcbaaabaf6e5ee189c6d04fdb1edbb4e584612103b33878f42b322c9c5b8bdde9279fc73092d15f420f325584b2b72d1fcfbf14e62103d4c40700b33dbe841f7f83011236975245e38be4af4da5f4febbe2265ac8401d53ae000000000000

Looks like the locktime is at the end but I cannot for the life of me figure out what the rest of these bytes are.

I can see on Blockstream API that after 00040047 comes the witness, does that mean that Witness count is a static 4-byte field and not a varint? OK, no, that wouldn't make sense, it seems to be that there are:

0 witness items (00)
followed by a witness stack of length 4 (04)
the first witness item is 0 bytes (00)
and the second one is 47 bytes (47)
and so on...

If you look at this transaction from Blockstream or mempool.space, you can see that two of the inputs share this exact same witness stack but parsed. So why the hell is there a shadow witness if the witness length is zero?  Huh

It indeed looks like there's a multisig stack at the end of this transaction, but it makes no sense why this is placed at the end, or is there some BIP semantics on multisig I'm missing here? (BIP141 says witness data is not script.)

EDIT: Parsed in Electrum, the inputs look like this:

Code:
   "inputs": [
        {
            "coinbase": false,
            "nsequence": 4294967295,
            "prevout_hash": "c9893fef96526abb74687eb8c766cadd22143bfe72e25184a4a2a7eff07986e9",
            "prevout_n": 0,
            "scriptSig": "00483045022100d28555445d45f4c7cc6faea786e5cacb669e671257e0f191415b8369987ff291022027ae7018f6441daf0aec55f3dd5e0af56ada4c8f884c699f3c9c329fa802df0d01473044022015588ba82e271782e295af024c34d45ccc15310e9af48373b38d83673380135202204bfa0ff9f2ad645e2cc4fbbc85421e7b1d278ebc3a4bb896144efb6a3af845b2014c69522103aea4a83eafa1d5d579d92cfa5ff46c2e5c1bdc977bc88276830ec308b22003252103cac2a52195fff9a92f9ca3c8d352a5e0a3a1046b84aad12e71154a1d3aa8fd33210283e746abc4917ffc3597b14120cb439edd45272f84c92f657d4a9bfa14594efc53ae",
            "witness": "00"
        },
        {
            "coinbase": false,
            "nsequence": 4294967295,
            "prevout_hash": "d6e93f6df429eaf1b8bde58c4ab9a7dd052476f6f1a610c6081b90c43cd5092b",
            "prevout_n": 0,
            "scriptSig": "004830450221009a2a70777a656c880eb63f462ee1777186eaa999a969fe39575178d24948332202206c08d0b64b466acebfcc79bbd184d58ed8d2bce34a777e667632719b9eb0e4a701463043021f1df71ec19e36c18c87b32c91053da4fa054ee332cdad5939e3343ebb10cbc4022042846ad3a9b0d27aba49ad2e37610d286edad07a0ef7a69526bbaf7efa6f6c16014c695221028b7eb4506228f9fc780cce3ffeabc1a863668e9a27abbb5e5a777895adb2033b210201792ff3534ae4b38994cf5260ad53188651c37976ecce57ac7a850b2f5e766a2102ae25c0b280ff2a97d85c4313059d72fe078c20ad2033551856b1bc488f65085553ae",
            "witness": "00"
        },
        {
            "coinbase": false,
            "nsequence": 4294967295,
            "prevout_hash": "b87ff1421f982fef378b248ee36c3b9e4279fc3422ba72c01107a8d682444395",
            "prevout_n": 3,
            "scriptSig": "2200208bf0d642c916dca24dd8075ef62ce889796938f56fb1aa63f334197091267232",
            "witness": "040047304402202e967a597d10db04d0deae85f0934f23c57508a9a32c96fa56bf24d7edda3c3e02204bc998026334b2d23d1dd302bcc48c39635b972e3d27ebec5ea9579fcac94da901473044022030070dde2e2342b876d9ab9a7ac827f263295d69142966782500fb47d32c5885022069d8cc9d6e6948defad031cdee7dc88b43beda6c57d6d36a99a6c3c5916624730169522102559e789100967b073b38ab3ac0fc6dea87232598163146c843bc993a9ee6bca92103fb55e9722a37e8ad98b00499b6e9acb30e75740c7f259a2ea220a184248b9bc22103348de99629babc5b1a95a53f47b53c6c9527ac831b4d9243d1b96e8fea765dbb53ae"
        },
        {
            "coinbase": false,
            "nsequence": 4294967295,
            "prevout_hash": "41e1b92c2474e310ec2a75c0225c5535bacd5111a3a82f1685b1c72b90859bbc",
            "prevout_n": 0,
            "scriptSig": "00483045022100a9fb003c7f2cee0353a27edd0d9c4337839c356ca8638f72748f88d5fec323a902200727fd37bbad17ca698f811ba29c601ccd6d913cec83a66ce8906d65db819fa101483045022100f06bc8a79d2ef6657c17b5fa3bccd9764983f1777658de3d85e69dceb2de1d04022056447e2ed54e752a31bc1c579701277aaea0c693398c95f2e40083bffad324f7014c695221028b7eb4506228f9fc780cce3ffeabc1a863668e9a27abbb5e5a777895adb2033b210201792ff3534ae4b38994cf5260ad53188651c37976ecce57ac7a850b2f5e766a2102ae25c0b280ff2a97d85c4313059d72fe078c20ad2033551856b1bc488f65085553ae",
            "witness": "00"
        },
        {
            "coinbase": false,
            "nsequence": 4294967295,
            "prevout_hash": "a833ea01379511726b99deb1f134b1b63d4da65fccbc24bcf00a6eded9bcb5eb",
            "prevout_n": 27,
            "scriptSig": "22002074e48c00831f511bfff817c362a19b0025b94be563abc97073c498914cd8bb0d",
            "witness": "0400483045022100f9f7f9eb9e8051f3d936ded8c99c208da130c97d65782dda30ef89b5e098bffe02203ded7b238c7f7826bcc16d9e56d60528ce670645a02dedc30a977d10962fa4d601483045022100e1f29f173348edd64d3fd55e18505b6996a18a12dcf89040904a76d8413c27ad02202bad736017e606767b4f4de0845e4823077f0ddbe41476bd94c1a7878869bf8d0169522102e3824ce17548df1f0f144b9f58bfcbaaabaf6e5ee189c6d04fdb1edbb4e584612103b33878f42b322c9c5b8bdde9279fc73092d15f420f325584b2b72d1fcfbf14e62103d4c40700b33dbe841f7f83011236975245e38be4af4da5f4febbe2265ac8401d53ae"
        },
        {
            "coinbase": false,
            "nsequence": 4294967295,
            "prevout_hash": "a833ea01379511726b99deb1f134b1b63d4da65fccbc24bcf00a6eded9bcb5eb",
            "prevout_n": 63,
            "scriptSig": "0047304402201120b9fac7b8b513dde7bcc96a4fe777400a96c2e7064f1a1d0700d47ad93bc402207bbfa36a8ad5552de43fbeabea0986677bf40a3e33b25194441e806b7d84650f0147304402204e9c597a32cece909592a657dbd33837a1715fb2ff4f53c445f7406dc18c2b19022071fee21eaf9bf377f046cbdc84e2c0415570da01da3923cb826af82eee07b1b0014c69522102727f1b2c79d1b6bf88bca86a768ce94f5f0c2239a3a7d1f89b1150ec863a8e802103c48303ad6cbf17aeb149fc5241d2d604a3879d485d68d0997b9bed5e5be5dc6821029f70b7b7670a87c663aabf7220d1625d25005c8230ef27a2d7d96bedcfa8541c53ae",
            "witness": "00"
        },
        {
            "coinbase": false,
            "nsequence": 4294967295,
            "prevout_hash": "1b90f79fa71ee477cd19ebe8e09d11eb42da70deecde231ba99f791f3120eb14",
            "prevout_n": 1,
            "scriptSig": "00483045022100a6f7cbca6c104772d8763d5d2eb7c7dcd0c67bdf287e133b248a15139dcbfdf5022008a0953448d71823ba9506a02298f3c4fa18ebb95e1151382fae9eebaa3f409201473044022063ad60e94c7387cf451074148c9ebe3e8352a4d3b6c888eb81eb6f78e7295aa802204cdfb7bdce6d3f0a1a9796e29b675776d90f2c888cab1f11db715ed5ed4f8213014c6952210215a43283169b326e2bfd2eb6a64daa66ac64299a7e241edb475dc6faf9d4affe2103624f8a038ad24bbf03def8bd45da80db7e65271d1513ed7c2e3e6723c4e3b26a21035b840146d8ea41fbf65d689fadcdbfd0bad50174c41d6361b560ce3d7011096b53ae",
            "witness": "00"
        }
    ],


It's almost as if the witness stack is getting chopped up and distributed to the inputs.
nc50lc
legendary
Activity: 2618
Merit: 6452
Self-proclaimed Genius
Re: Segwit transaction with no witness stack
July 20, 2023, 10:50:18 AM
#3
Quote from: NotATether on July 20, 2023, 07:45:17 AM
-snip- appears to have the Segwit flag and marker. But it has a witness count of zero.
Seems like your code is parsing those OP_0 (0x00) of the two 2-of-3 MultiSig p2sh-p2wsh outputs' txinwitness as zero witness stack items instead.
Where it's actually OP_0 [signature1] [signature2] [redeemScript]
pooya87
legendary
Activity: 3472
Merit: 10611
Re: Segwit transaction with no witness stack
July 20, 2023, 08:19:12 AM
#2
Quote from: NotATether on July 20, 2023, 07:45:17 AM
My question is, why is it like that? Is it not forbidden for segwit transactions to have zero-length witness stacks?
It's fine to have no witnesses (zero length).
In a transaction with witness you have to have the same number of witness stacks as your inputs so when you have 7 inputs you have to have 7 witness stacks but some of those outputs that are being spent (like first and second) are legacy so there is no witness needed hence the empty witnesses (OP_0) but the others (like the third) have a witness stack hence the 4 items in that stack.
NotATether
legendary
Activity: 1568
Merit: 6660
bitcoincleanup.com / bitmixlist.org
Re: Segwit transaction with no witness stack
July 20, 2023, 07:45:17 AM
#1
https://blockchair.com/bitcoin/transaction/8bdbdf30bc77d7c83fb9da3e8d4e6f6b5db28f7694109f498f228ce5ff74ec56

This is a very strange transaction I have encountered while testing my code that pulls address transactions from Electrum and parses them.

This is an extremely large raw transaction predating the Ordinals days by many years, that appears to have the Segwit flag and marker. But it has a witness count of zero.

My question is, why is it like that? Is it not forbidden for segwit transactions to have zero-length witness stacks?
Bitcoin Forum>Bitcoin>Development & Technical Discussion
Jump to: