Signature is changed after submitting transaction

[donhardman]

We have weird issue.. That signature is changed for submitted transaction. How is it possible?

So we sent transaction

02604b65ee5b04a4032fbf1344010a1871d5506ff30f784d4e1f20f8022cb35f4301594c64da108d0b949f5c962ca9480c98968c5f89131534881aff56a24b5fc394000202a9192d6d3fdf38347606e58e96960b4126b6f3c1fb53244032700cdc97a00b18d0860302a0b40718cf8e70aa2ac59236df101a9979ef0df756457cd239c74c9fb48cad999fff0202002102a0b40718cf8e70aa2ac59236df101a9979ef0df756457cd239c74c9fb48cad99020c4469616d6f6e644c6576656c01020f4469616d6f6e64506f7374486173682026654fcb595f8dcab57924e362657faa5d4cdb62492090ad26b4ec44e96b3b554730450220453c24096c44ff521cff91790164f4c0855f16936a22bc85ee7c22ef2a4bb79d022100fdfb9c04ff076db2936712c337ac3b499fd821c1969333001a7f1b7592b44d5e

and after we can see that there is no such transaction but we have same body and different signature after

02604b65ee5b04a4032fbf1344010a1871d5506ff30f784d4e1f20f8022cb35f4301594c64da108d0b949f5c962ca9480c98968c5f89131534881aff56a24b5fc394000202a9192d6d3fdf38347606e58e96960b4126b6f3c1fb53244032700cdc97a00b18d0860302a0b40718cf8e70aa2ac59236df101a9979ef0df756457cd239c74c9fb48cad999fff0202002102a0b40718cf8e70aa2ac59236df101a9979ef0df756457cd239c74c9fb48cad99020c4469616d6f6e644c6576656c01020f4469616d6f6e64506f7374486173682026654fcb595f8dcab57924e362657faa5d4cdb62492090ad26b4ec44e96b3b554630440220453c24096c44ff521cff91790164f4c0855f16936a22bc85ee7c22ef2a4bb79d0220020463fb00f8924d6c98ed3cc853c4b51ad6bb2518b56d3ba55343173d81f3e3

Somehow it happens with diamonds transaction (seems only)

Also it seems like happens not all the time.

What are we missing?

[donhardman]

We fully reproduced it. It happens when you send 2 diamond transactions in a row with using last utxo as input and happens on 2nd one.

So we sent using bundle transaction by protocol 1st diamond tx

02b8fd099d83a0ca0a7aaae1f44e5d408df775c419622aee86396c28ea86a136cf01623e0ee41dc0696bb7a788bb8282c7e52944dda49a251125127a443a9d2bfddb0002038a4c86f8b9bfa8d63b4e13c302ba6b14b6dbcae86475f6636340f9b78616b436d0860303a7698289f6fb08d6948dae644484c4462d4340ce376961f661c63de10b4b111cccea0102002103a7698289f6fb08d6948dae644484c4462d4340ce376961f661c63de10b4b111c020c4469616d6f6e644c6576656c01020f4469616d6f6e64506f73744861736820c60a2921295e9fa79f9f2ef53f296be2df185d2e625f2f8c5cb64cf30358810a473045022100ae6a8c6b41ce6f251bbb125dca162611a950689570df6faec076855fabf08e2f02204839257b419d661d19950a5b5912ad3e406fc66b2b50ecc750f7b175f1a7fbd9

It has id 3JuEU8EdT2LXSxY9vBnEHAszEwaqc5gDNH7ktmJkmgjea29WVPsM1b same as we can see in explorer

After we prepared and send 2nd diamond transaction USING node submit tx method

02b6b407f35f62ba227b81344872dbd291c97a926c42b38c55410295e409811570010cc53776d01aa8681db71de82881b831b0b34f850be50f0d16b5a886a397774c00020210fa89e270193ec7b8213b8efa49f9d7f4c2a12c06208da33da945b52359c7ded0860303a7698289f6fb08d6948dae644484c4462d4340ce376961f661c63de10b4b111cb1e00102002103a7698289f6fb08d6948dae644484c4462d4340ce376961f661c63de10b4b111c020c4469616d6f6e644c6576656c01020f4469616d6f6e64506f7374486173682005a5dffb97abfd4656540ca08dcac299dc554752012fa108ed918fb65d61f9f047304502205639417c7bdfc707575004f2f64b748b8060e4bcf4d2ede17924d7c422ffd0ca02210087711a017253c62151ed575fc2d282f7403c2967003655bbb71a975403334a1e

So if you calculate ID of it, should be – *3JuETUCoGUsKT2KmeMGGjjhGs8tRtW9fTqtzVoGCWrS8cjPr72QqWX`

Node returned

{"Transaction":{"TxInputs":[{"TxID":[182,180,7,243,95,98,186,34,123,129,52,72,114,219,210,145,201,122,146,108,66,179,140,85,65,2,149,228,9,129,21,112],"Index":1},{"TxID":[12,197,55,118,208,26,168,104,29,183,29,232,40,129,184,49,176,179,79,133,11,229,15,13,22,181,168,134,163,151,119,76],"Index":0}],"TxOutputs":[{"PublicKey":"AhD6ieJwGT7HuCE7jvpJ+df0wqEsBiCNoz2pRbUjWcfe","AmountNanos":50000},{"PublicKey":"A6dpgon2+wjWlI2uZESExEYtQ0DON2lh9mHGPeELSxEc","AmountNanos":28721}],"TxnMeta":{},"PublicKey":"A6dpgon2+wjWlI2uZESExEYtQ0DON2lh9mHGPeELSxEc","ExtraData":{"DiamondLevel":"Ag==","DiamondPostHash":"BaXf+5er/UZWVAygjcrCmdxVR1IBL6EI7ZGPtl1h+fA="},"Signature":{"R":39000067230444674001272252541461828365331923160522036074209205380682163933386,"S":61262067761465946934116689200031670164735809632710522612600934551819883072030},"TxnTypeJSON":2},"TxnHashHex":"679cc1fd614c8a6e3adf77bf70fa678c1bb6ce58e9571aeb298507be5e7ad570","PostEntryResponse":null}

Screenshot

Checking in mempool and OMG. Signature changed??? how?

New ID - * 3JuETXQMinRcn5XBskY1ZPmn41vEFexzJLg6cjHcT2mn32jRoBVGRQ* 3JuETXQMinRcn5XBskY1ZPmn41vEFexzJLg6cjHcT2mn32jRoBVGRQ

Body hex

02b6b407f35f62ba227b81344872dbd291c97a926c42b38c55410295e409811570010cc53776d01aa8681db71de82881b831b0b34f850be50f0d16b5a886a397774c00020210fa89e270193ec7b8213b8efa49f9d7f4c2a12c06208da33da945b52359c7ded0860303a7698289f6fb08d6948dae644484c4462d4340ce376961f661c63de10b4b111cb1e00102002103a7698289f6fb08d6948dae644484c4462d4340ce376961f661c63de10b4b111c020c4469616d6f6e644c6576656c01020f4469616d6f6e64506f7374486173682005a5dffb97abfd4656540ca08dcac299dc554752012fa108ed918fb65d61f9f046304402205639417c7bdfc707575004f2f64b748b8060e4bcf4d2ede17924d7c422ffd0ca0220788ee5fe8dac39deae12a8a03d2d7d077a72b37faf124a8008b7c738cd02f723

You can see SAME body but DIFFERENT signature (not same that was send)

02b6b407f35f62ba227b81344872dbd291c97a926c42b38c55410295e409811570010cc53776d01aa8681db71de82881b831b0b34f850be50f0d16b5a886a397774c00020210fa89e270193ec7b8213b8efa49f9d7f4c2a12c06208da33da945b52359c7ded0860303a7698289f6fb08d6948dae644484c4462d4340ce376961f661c63de10b4b111cb1e00102002103a7698289f6fb08d6948dae644484c4462d4340ce376961f661c63de10b4b111c020c4469616d6f6e644c6576656c01020f4469616d6f6e64506f7374486173682005a5dffb97abfd4656540ca08dcac299dc554752012fa108ed918fb65d61f9f0

Looking for clarification how it's possible? Why orignal signature of transaction CHANGED by node without prior notice?

[donhardman]

I believe this was incorrect behavior because I expected my original BODY to be used and not modified like this when I sent the transaction.

Any chances to get fixed it? If the tx is not OK, it should be rejected but NOT MODIFIED, in my opinion.

[donhardman]

OK, I just wrote a small script and found an issue. Go lang is not my language, so I do not know why it happens, and not so familiar with its libs.

package main

import (
  "encoding/hex"
  "fmt"

  "github.com/btcsuite/btcd/btcec"
)

func main() {
  sigBytes, _ := hex.DecodeString("304502205639417c7bdfc707575004f2f64b748b8060e4bcf4d2ede17924d7c422ffd0ca02210087711a017253c62151ed575fc2d282f7403c2967003655bbb71a975403334a1e")
  sig, _ := btcec.ParseDERSignature(sigBytes, btcec.S256())
  fmt.Println("%v", hex.EncodeToString(sig.Serialize()))
}

go run script.go

And now we can see that signature changed:

%v 304402205639417c7bdfc707575004f2f64b748b8060e4bcf4d2ede17924d7c422ffd0ca0220788ee5fe8dac39deae12a8a03d2d7d077a72b37faf124a8008b7c738cd02f723

[diamondhands0]

@donhardman we're looking into this. How did you prepare the signature? Did you use Identity to prepare it or some other mechanism? We need to inspect the code that prepared the signature in order to debug this.

There are two ways to fix this:

• Fix the code that is preparing the signature
• Fix the code that is parsing the signature to standardize or error when there is a nonstandard signature

I believe the first path is far easier.

[diamondhands0]

Please explain the full process you used to:

1. Generate the txn
2. Sign the txn
3. Submit the txn

We need to be able to trace all of the code from beginning to end in order to help.

[donhardman]

1. We prepare the transaction on the client-side by using only UTXOs information.
2. An official identity frame signs the transaction.
3. Transaction is submitted by using DeSo protocol in bundle (but even when we submit using core node API, it's the same)

[donhardman]

I fully agree that the way to fix how the signature is built is the best. So it's about identity service, then.

[lazynina]

@donhardman - are you still experiencing this issue or did the update to identity resolve your concern? If so, may we close this issue?

[donhardman]

Seems like it's okay now. Sorry for late reply! Thank you for fixing it