Too many Repeated R in transaction

[harvysam]

I'm not sure if this is the right section to ask this question.
I recently noticed a transaction with almost every transaction having the same "Signature R", this address belongs to segwit address.
But the strange part I notice for the same is there is no "Signature S", I actually used the Sean-Bradley's 2coin.org site to find details of the transactions.

Should the P2WSH transaction be without "Signature S"? Or, is it getting stored elsewhere??

[1713570927]

1713570927

[pebwindkraft]

if you could show the tx ID, it would be interesting to analyze it ...

[harvysam]

if you could show the tx ID, it would be interesting to analyze it ...

Here is the TX ID of the repeated R.

e89c5b66193074c50b452f67847c210e9745a446a8289ecdb2c15c5c80224c65


Also, I'm a bit confused here, I believe this is not the actual Signature R, as I had looked thru so many articles in this forum that the P2SH-P2WPKH transaction works in a bit different way but the 2.coin.org gives some value as Signature R which is repeated in all these transactions and no values in Signature S but without the Signature S it is showing Signature Z.

[pebwindkraft]

Looking at the tx, and decoding, it is a segwit transaction, having several segwit data at the end:

Code:

VERSION 01000000
SEGWIT (BIP141): this is a segwit tx, marker=00
       (BIP141): flag=01
TX_IN COUNT [var_int]:     hex=01, decimal=1
 TX_IN[0] OutPoint hash:  880C7B67BFB6D70EDAA74292EDCD1B3585B91890762EAFE123799F6D6599A1EB
 TX_IN[0] OutPoint index: hex=01000000, reversed=00000001, decimal=1
 TX_IN[0] Script Length:  hex=23, decimal=35
 TX_IN[0] Script Sig (uchar[])
 22002065D416C48A8072E0AC51C2D111EB194F009CAEF0332446C1BF2097316CF07FA9 
 ### decode SIG_script OPCODES 
  22: OP_Data(0x01-0x4b):  34 byte(s) to be pushed to the stack
      002065D416C48A80:72E0AC51C2D111EB
      194F009CAEF03324:46C1BF2097316CF0
      7FA9
 TX_IN[0] Sequence: FFFFFFFF
TX_OUT COUNT, hex=03, decimal=3
 TX_OUT[0] Value: hex=D013270000000000, dec=2560976, bitcoin=0.02560976
  TX_OUT[0] PK_Script Length: hex=17, dec=23
  TX_OUT[0] pk_script: A9148C6C69AC0FECCA4925CA2E0B5EE7EE69F590096A87
   This is a P2SH script, and translates base58 encoded into this bitcoin address:
   3EVWQ3yfCuotskvbWGY33UJwZtyuLohn4D
 TX_OUT[1]
  TX_OUT[1] Value: hex=BCBB5B0000000000, dec=6011836, bitcoin=0.06011836
  TX_OUT[1] PK_Script Length: hex=19, dec=25
  TX_OUT[1] pk_script: 76A91499BC1C4D87B84CC6AEF493799E0DFFF49F259C8788AC
   This is a P2PKH script, and translates base58 encoded into this bitcoin address:
   1F1sjW3ZM3mvoBJzZFQntiV2BhF3wmTSfL
 TX_OUT[2]
  TX_OUT[2] Value: hex=018D310600000000, dec=103910657, bitcoin=1.03910657
  TX_OUT[2] PK_Script Length: hex=17, dec=23
  TX_OUT[2] pk_script: A9141988A27E3C2DF4DDEE7FAD5A2303D086179B2A3087
   This is a P2SH script, and translates base58 encoded into this bitcoin address:
   3422VtS7UtCvXYxoXMVp6eZupR252z85oC
 
WITNESS TXIN[0] stack elements: hex=04, decimal=4
 WITNESS[0] data length, hex=00, decimal=0, data(uchar[]):
  - missing ? -
 WITNESS[1] data length, hex=48, decimal=72:
  304502210092263215EE8790FB10911CE34530BDE179EDF60176C6E1A6591629D36C8C1E9C022059577755C935B4A7C6A63F12D293B1018600F9A464F7AEAEF67D492A08AED9F501
 WITNESS[2] data length, hex=48, decimal=72:
  3045022100C357C4DD36AA24D3AB2FBEEFA3730C9D5C9441D7171B72286481F0138744A091022056A7C5E3176A9A09432B959BA0DFFD8941FC6D6655CDC91508A0E1D2DAAD4BF501
 WITNESS[3] data length, hex=69, decimal=105:
  522102F44ABCF9E23C9A460DA309CCCA56C619C04EED3BDE2C2CFF5E7D78FBCD980B9C2103C9443CF3047BB6C2C82F1B0C44C36109CDC3D0D601D16D1189A1602BF8D1A0A02103BFE867059274412412E088AF5572B92168C2EF495CFE6C9B7A753A009EB37C4853AE
 
 LOCK_TIME 00000000

Looking at the witness scripts, Witness[1]:

Code:

    30: OP_SEQUENCE_0x30:    type tag indicating SEQUENCE, begin sigscript
    45: OP_LENGTH_0x45:      length of R + S
    02: OP_INT_0x02:         type tag INTEGER indicating length
    21: OP_LENGTH_0x21:      this is SIG R (33 Bytes)
        0092263215EE8790:FB10911CE34530BD
        E179EDF60176C6E1:A6591629D36C8C1E
        9C
    02: OP_INT_0x02:         type tag INTEGER indicating length
    20: OP_LENGTH_0x20:      this is SIG S (32 Bytes)
        59577755C935B4A7:C6A63F12D293B101
        8600F9A464F7AEAE:F67D492A08AED9F5
    01: OP_SIGHASHALL:       this terminates the ECDSA signature (ASN1-DER structure)

Witness[2]:

Code:

    30: OP_SEQUENCE_0x30:    type tag indicating SEQUENCE, begin sigscript
    45: OP_LENGTH_0x45:      length of R + S
    02: OP_INT_0x02:         type tag INTEGER indicating length
    21: OP_LENGTH_0x21:      this is SIG R (33 Bytes)
        00C357C4DD36AA24:D3AB2FBEEFA3730C
        9D5C9441D7171B72:286481F0138744A0
        91
    02: OP_INT_0x02:         type tag INTEGER indicating length
    20: OP_LENGTH_0x20:      this is SIG S (32 Bytes)
        56A7C5E3176A9A09:432B959BA0DFFD89
        41FC6D6655CDC915:08A0E1D2DAAD4BF5
    01: OP_SIGHASHALL:       this terminates the ECDSA signature (ASN1-DER structure)

Witness[3]:

Code:

    52: OP_2:                the number 2 is pushed onto stack
        ################### we go multisig ####################################
    21: OP_DATA_0x21:        compressed pub key (33 Bytes)
        02F44ABCF9E23C9A:460DA309CCCA56C6
        19C04EED3BDE2C2C:FF5E7D78FBCD980B
        9C
        This is MultiSig's compressed Public Key (X9.63 form)
        corresponding bitcoin address is:    1FiVRNmCHaHxXB9eJ5gG25bzzjzYWVbp2u
    21: OP_DATA_0x21:        compressed pub key (33 Bytes)
        03C9443CF3047BB6:C2C82F1B0C44C361
        09CDC3D0D601D16D:1189A1602BF8D1A0
        A0
        This is MultiSig's compressed Public Key (X9.63 form)
        corresponding bitcoin address is:    12mUsc3d6x1wkcaT6zRPKNpG2bHBtJvG8N
    21: OP_DATA_0x21:        compressed pub key (33 Bytes)
        03BFE86705927441:2412E088AF5572B9
        2168C2EF495CFE6C:9B7A753A009EB37C
        48
        This is MultiSig's compressed Public Key (X9.63 form)
        corresponding bitcoin address is:    1ENPdt21dRXeNVFXL9BTaXUHf2Drfmi9hc
    53: OP_3:                the number 3 is pushed onto stack
        ################### 2-of-3 Multisig ###################################
    AE: OP_CHECKMULTISIG:    terminating multisig
        corresponding bitcoin address is:    3LTsBuaRozhM1VNUk8tiNUea4G7yakjYJX

So I can see different R-Values for signatures, which looks ok. I also tried to look into 2coin.org, but couldn't find the repeating R-values. Did you mention several different tx IDs? I could only check this single tx...

[pebwindkraft]

also I am looking at 2coin.org, but can not see all witness data:

Code:

"vin": [
    {
      "txid": "880c7b67bfb6d70edaa74292edcd1b3585b91890762eafe123799f6d6599a1eb",
      "vout": 1,
      "scriptSig": {
        "asm": "002065d416c48a8072e0ac51c2d111eb194f009caef0332446c1bf2097316cf07fa9",
        "hex": "22002065d416c48a8072e0ac51c2d111eb194f009caef0332446c1bf2097316cf07fa9"
      },
      "sequence": 4294967295,
      "n": 0,
      "addr": "3422VtS7UtCvXYxoXMVp6eZupR252z85oC",
      "valueSat": 112485041,
      "value": 1.12485041,
      "doubleSpentTxID": null,
      "sigR": "16c48a8072e0ac51c2d111eb194f009caef0332446c1bf2097316cf07fa9ffffffff",
      "sigS": "",
      "sigZ": "7f9dad303b47a86e29a4e362b0e9aaa878ce708c41fe451401fda8e5d6a33800"
    }
  ]

Just wondering if things are not yet fully (segwit-) developed?  I do not understand were the sigR value comes from. Do you have more examples?

[harvysam]

also I am looking at 2coin.org, but can not see all witness data:

Code:

"vin": [
    {
      "txid": "880c7b67bfb6d70edaa74292edcd1b3585b91890762eafe123799f6d6599a1eb",
      "vout": 1,
      "scriptSig": {
        "asm": "002065d416c48a8072e0ac51c2d111eb194f009caef0332446c1bf2097316cf07fa9",
        "hex": "22002065d416c48a8072e0ac51c2d111eb194f009caef0332446c1bf2097316cf07fa9"
      },
      "sequence": 4294967295,
      "n": 0,
      "addr": "3422VtS7UtCvXYxoXMVp6eZupR252z85oC",
      "valueSat": 112485041,
      "value": 1.12485041,
      "doubleSpentTxID": null,
      "sigR": "16c48a8072e0ac51c2d111eb194f009caef0332446c1bf2097316cf07fa9ffffffff",
      "sigS": "",
      "sigZ": "7f9dad303b47a86e29a4e362b0e9aaa878ce708c41fe451401fda8e5d6a33800"
    }
  ]

Just wondering if things are not yet fully (segwit-) developed?  I do not understand were the sigR value comes from. Do you have more examples?

Exactly is what I've seen in this site.
Now, in this site if you look at all the outgoing transactions of this address "3422VtS7UtCvXYxoXMVp6eZupR252z85oC" it show's the same SIG R: "16c48a8072e0ac51c2d111eb194f009caef0332446c1bf2097316cf07fa9ffffffff",

After looking at few articles about segwit that is when a question raised in me about the 2coin.org website that it could be not developed for SEGWIT.

[pebwindkraft]

ahh, now I can see - the R-Value ("sigR": "16c48a8072e0ac51c2d111eb194f009caef0332446c1bf2097316cf07fa9ffffffff") is part of the tx input section. Directly after the signature itself. Specifically it "runs" into the pubkey, it starts at position 8 and runs until "ffffffff", which is the sequence number:

Code:

   22: OP_Data(0x01-0x4b):  34 byte(s) to be pushed to the stack
    002065D4
-->    16C48A80 72E0AC51C2D111EB 194F009CAEF03324 46C1BF2097316CF0 7FA9
  TX_IN[0] Sequence: FFFFFFFF

Some counters seem to go wrong. I guess the logic expects sequence number directly after signature (4 bytes of "ff"), but doesn't find it, and runs through the hex data until he got sequence.
The sigR would then be displayed everytime, when the tx re-uses the address (and its pub key), which is in itself a bad attitude.

maybe drop a message to Sean-Bradley's 2coin.org site?

[harvysam]

@pebwindkraft, thank you for clearing my doubt, it was really helpful.
I'll surely drop in a mail to Sean Bradley on this.