Unconfirmed transaction is not even visible on block explorers

[buwaytress]

Though now I'm curious also about seoincorporation's post... what did they change to get a diff ID? Is it that "clam-speech" bit? What's that?

I don't really know what's "clam-speech".
As I see in the post made by seoincorporation the "time" has been also changed.

It's in the code provided by seoincorporation... but I guess have to wait for him to respond to understand how the ID changed, and what variable changed it.

Code:

    "clam-speech" : "Expression of Political Freedom: Autocracy",

OK I'm suddenly curious now and want to try this next time I fire up as I actually never noticed. I don't know how it all works but using explanations above... if tx ID is made by hashing tx data, and the data doesn't change (destination, amount fee, locktime, etc), then the hash result will always be the same, correct?

Isn't this related to not reusing the same k value?

It's easy to test by signing the same message twice: the signature changes.

 k value def new to me (bearing in mind I'm always finding out new things from a very basic user perspective). And don't even know what it means to me. Also always thought signature remains same, as that's how people can verify if I give them the message and signature... right?

In any case, tx ID is created at creation of raw tx, not at signature stage (refer above).

P.S. that link you shared, crazy it still holds 59 BTC (7 more than when it was first alerted in 2013!).

[1715554750]

1715554750

[1715554750]

1715554750

[1715554750]

1715554750

[NotATether]

I made a second transaction with the same source/destination address and amount, just with a higher fee. From there I got the same transaction hex.

This is not possible.
For increasing transaction fee, you have to either add an extra input or decrease the output value. With the change in transaction data, the transaction hash should change as well.

You are right, it looks like the successful transaction has a different txid: 265fc8f27bee89e81a184aba89088784ea8ed09289c2429fc3f17ec2242cd9b9

^--- this is the one that is using a higher fee and had confirmed. The leading "2" looked suspiciously like a 3, and they both are followed by "65...." or similar.

I pulled this via Guarda, so I can be sure they don't have a complete RPC meltdown.

[o_e_l_e_o]

How can you have a different signature if you sign the same message from the same address? Shouldn't you have the same signature every time you sign the the same message from the same address?

Usually yes, but it also depends on your wallet software/implementation.

Most good wallets use RFC 6979 to generate a k value for signing. This means k is produced deterministically, using a combination of your private key, the message you are signing, and a hash function. So the same message signed from the same private key will always generate the same k value and therefore the same signature. RFC 6979 is used to ensure that k is always unique and stop k accidentally being reused across different transactions, which would leak your private key.

However, if you are using a wallet implementation (I don't know of any that still do this) which just randomly generates k, then every time you sign the same message from the same private key it will use a different value for k, resulting in a different signature.