Bitcoin Forum
June 25, 2024, 04:44:08 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 [2]  All
  Print  
Author Topic: Unconfirmed transaction is not even visible on block explorers  (Read 305 times)
buwaytress
Legendary
*
Offline Offline

Activity: 2842
Merit: 3540


Join the world-leading crypto sportsbook NOW!


View Profile
November 18, 2022, 01:14:58 PM
 #21

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!).

██
██
██
██
██
██
██
██
██
██
██
██
██
... LIVECASINO.io    Play Live Games with up to 20% cashback!...██
██
██
██
██
██
██
██
██
██
██
██
██
NotATether (OP)
Legendary
*
Offline Offline

Activity: 1638
Merit: 6911


bitcoincleanup.com / bitmixlist.org


View Profile WWW
November 18, 2022, 01:52:54 PM
Merited by NeuroticFish (1)
 #22

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.

.
.BLACKJACK ♠ FUN.
█████████
██████████████
████████████
█████████████████
████████████████▄▄
░█████████████▀░▀▀
██████████████████
░██████████████
████████████████
░██████████████
████████████
███████████████░██
██████████
CRYPTO CASINO &
SPORTS BETTING
▄▄███████▄▄
▄███████████████▄
███████████████████
█████████████████████
███████████████████████
█████████████████████████
█████████████████████████
█████████████████████████
███████████████████████
█████████████████████
███████████████████
▀███████████████▀
█████████
.
o_e_l_e_o
In memoriam
Legendary
*
Offline Offline

Activity: 2268
Merit: 18588


View Profile
November 19, 2022, 08:32:19 PM
Merited by LoyceV (4), hosseinimr93 (2)
 #23

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.
Pages: « 1 [2]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!