Bitcoin Forum
May 24, 2024, 09:31:08 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: What is the best way to handle malleable transactions?  (Read 1418 times)
vineyard (OP)
Hero Member
*****
Offline Offline

Activity: 546
Merit: 500


EOS Auctions


View Profile WWW
February 18, 2014, 05:56:47 PM
 #1

Because the current Bitcoin protocol allows for malleable transactions, the TXID which is a hash of the certain portions of the transaction cannot be used to uniquely identify a transaction. Supposedly, this is the problem MtGox and others ran into recently. One way to handle malleable transactions is to listen to the Bitcoin network for any transactions associated with Bitcoin addresses you care about. If you see a transaction with an TXID that you don't know about, look back into the transactions that you did create and try to match the VINs and VOUTs (since these cannot be changed in a malleable transaction). Does anyone else have a better way of dealing with this?
halcyon
Member
**
Offline Offline

Activity: 70
Merit: 10


View Profile
February 18, 2014, 06:59:09 PM
 #2

look at the github releases of the bitcoin developers Wink

Directbet livebetting
vineyard (OP)
Hero Member
*****
Offline Offline

Activity: 546
Merit: 500


EOS Auctions


View Profile WWW
February 18, 2014, 07:50:04 PM
 #3

look at the github releases of the bitcoin developers Wink

I have rummaged around and found 2 techniques. The first is to embed some message in the transaction itself that can help you identify it later on. This is kind of frowned on because it creates "blockchain spam". The second is what I think is the best so far is to simply match VINs and VOUTs of unknown transactions on addresses you care about to your own recorded data. Just wondering if there is a third way (or a fourth)?
fbueller
Sr. Member
****
Offline Offline

Activity: 412
Merit: 275


View Profile
February 19, 2014, 02:06:30 PM
 #4

I'm using blocknotify to scan all transactions in a block for transactions paying to addresses I care about. I then log the txid/vout/address it was sent to. These are funding multsig addresses in my case.
It also checks if the inputs in the new blocks transactions are known about, gathered by the above process. These would be payments leaving the multisig address.

By parsing blocks for transactions (blocknotify) instead of just learning about a new transaction (walletnotify) at least the transaction has one confirmation. This avoids the malleability issue altogether.

Bitwasp Developer.
limpybud
Newbie
*
Offline Offline

Activity: 10
Merit: 0


View Profile
February 19, 2014, 05:10:02 PM
 #5

I have recently joined this community and this post is luckily answer to one of the questions I was concerned about
vineyard (OP)
Hero Member
*****
Offline Offline

Activity: 546
Merit: 500


EOS Auctions


View Profile WWW
February 19, 2014, 05:55:12 PM
 #6

I'm using blocknotify to scan all transactions in a block for transactions paying to addresses I care about. I then log the txid/vout/address it was sent to. These are funding multsig addresses in my case.
It also checks if the inputs in the new blocks transactions are known about, gathered by the above process. These would be payments leaving the multisig address.

By parsing blocks for transactions (blocknotify) instead of just learning about a new transaction (walletnotify) at least the transaction has one confirmation. This avoids the malleability issue altogether.

I think we are doing the same thing. I use walletnotify and disregard transactions with 0 confirms (walletnotify executes the callback both at the time a new transaction is accepted by a node on the network and then again when the transaction has 1 confirm). When I am notified of a transaction with 1 confirm, I see if I have it in my database. This is the easy case when the transaction ID was not altered. If I do not recognize the TXID, then I try to match it up against transactions I have created in my database that have yet to be confirmed once.
Pages: [1]
  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!