Topic: Ok, so how do properly send out payments from a program with no Malleability (Read 609 times)

Correct. Or you can re-issue the exact same transaction. As long as you keep reusing the exact same transaction outputs only one of those identical transactions will ever make it into the blockchain.

Wouldn't it be wise to just check your sending address against their payment address? If you always use a new sending address for sending, wouldn't that give you 100% reliability?


Kosta

Yes, it's much better to use raw transactions. It seems more difficult at first, but it's not. It's just a bit of a learning curve.

Start from here, and send a few things to yourself (make sure you understand how change works, otherwise you're going to pay large transaction fees).
https://people.xiph.org/~greg/signdemo.txt

I've started doing everything using raw transactions now (even in the client when I'm just paying for my own stuff - debug window, createrawtransaction). The first one was a head scratcher. The second one was a bit easier. Third one dead simple. Now, it's like - why doesn't everybody just do this, it makes things so much more obvious?

Once you only deal in raw transactions, the way to solve the malleability problem is trivial:

Look for the TxId/vout that you're spending from to show up in the vin of any new (raw) transaction on the blockchain - that's your transaction. If it wasn't molested, it will happen to match your originating TxId. You won't rely on that anywhere though, so that would just be a nice coincidence. And if someone complains the funds didn't show up - just point them at the transaction that finally got accepted in the BlockChain.


HOWEVER, just another attack vector to consider (even if it doesn't exist today). Even if you don't see your original Transaction, AND you don't see the TxId/vout spending pair in another transaction on the network, STILL don't just go and directly refund the money to whoever complains that their transaction never showed up.

Maybe an attacker managed to really get your transaction excluded from the blockchain and is holding it back until after your refund. Maybe there is a new attack vector that nobody discovered yet. To be sure, instead re-spend the original Transaction(s) to your own account, wait for a whole bunch of confirmations, and then only re-initiate a new spending out. That way you're using the miners to go and validate on your behalf that everything is still fine with the world.

So in that case if an attacker DID manage to hold back or somehow mutate the transaction, he would now just be holding a double spend that will get rejected.

sendtoaddress is fine - just don't rely on the txid actually making it onto the blockchain being the same.

Using raw transactions won't change anything - you will still get a txid which may be replaced when the transaction is included in a block.

Ok,

Now with all the talk about malleability. What is the proper way to make payments from a program with bitcoin-qt ?

If one wants to make automated payments and be able later to track down the transaction what is now the current best practices to do that?

Should one still just do:
sendtoaddress      Returns the transaction ID if successful.

txid is usable with bitcoin-qt or totally unreliable? The value you got from sendtoaddress can change to something else in bitcoin-qt?
Some say that you should keep the timestamp. How do you get that? And will the value be exactly the same on blockchain.info, or
do you have to look around and find a transaction that has roughly the same value?
Some say you should keep input addresses. How to get that?

Better to use raw transactions? But it seems more difficult and requires a lot of manual work.

And what to do if a transaction does not go through. -Just wait more?
sendtoaddress will keep the transaction active in the net until it eventually goes through?