Blockchain tutorials for double spending and signature verification

Question

I've been studying blockchain from basics, and studying the TPCoin python codes line by line. While looking into the code, I found that there is no validation method that will prevent the double spending issues or reject the transaction request with invalid signatures.

I was studying with article below: https://morioh.com/p/7bfc126c22c2

class Transaction:

    def __init__( self, sender, recipient, value ):
        self.sender = sender 
        self.recipient = recipient 
        self.value = value
        self.time = datetime.datetime.now()
        self.signer = ""
    
    def to_dict( self ):

        if self.sender == "Genesis":
            identity = "Genesis"
        else:
            identity = self.sender.identity

        return collections.OrderedDict( { 'sender': identity, 'recipient': self.recipient, 'value': self.value, 'time' : self.time } )

    def sign_transaction( self ):

        private_key = self.sender._private_key
        signer = PKCS1_v1_5.new( private_key )
        h = SHA.new( str( self.to_dict( ) ).encode( 'utf8' ) )
        self.signer = binascii.hexlify( signer.sign( h ) ).decode( 'ascii' )
        return self.signer

    def display_transaction( self ):
        dict = self.to_dict( )
        print ("sender: " + dict['sender'])
        print ('-----')
        print ("recipient: " + dict['recipient'])
        print ('-----')
        print ("value: " + str(dict['value']))
        print ('-----')
        print ("time: " + str(dict['time']))
        print ('-----')
        print ("signature: " + self.signer)
        print ('-----')

    def validate_transaction( self ):
        ### Double spending? Signature Verification?
        return

I think there should be a sort of validation function within the Transaction class...but not quite sure what to do. I would like to see some brilliant ideas on how to handle this.

Answer 1

You can technically "try to spend" the coins as many times as you want. However, only one transaction can be added to the block, and the others will be rejected. The leftover transactions can't be added to newer blocks either as the output is no longer a UTXO.

The tricky part is when two different miners grab two different transactions from the same output and there is network latency so they both add the block to their own chain. At this point you would need to look at the longest chain concept and understand orphaned chains, why we have confirmations to begin with, proof-of-work, etc.