Broadcast result [SOLVED]

[bere3kin]

I trying to catch the moment when serialized transaction that is in queue due network problems or any other reason finally broadcasted.
There is no problem to get txid when there is no any delays but in some cases when txid generated not immediately to get broadcast result doesn't seem possible, does it?
So the question is - how to get broadcast result even when itself operation completed with delay.

[HCP]

Just to clarify...

You're wanting to know what the status of a transaction is? IE. Did it get broadcast? Or is it just signed but not sent yet?

Transactions that have been created but have not been broadcast are labelled as 'local' in the transaction history list... So they are definitely identified as such internally within Electrum.

Whether or not you can actually extract that value from the console or via CLI is a different matter. I don't see anything obvious... And gettransaction() with the generated txid only shows "complete = true" and "final = false")...

[pooya87]

first of all you get a transaction ID when you sign a transaction. it has nothing to do with broadcasting and being in a queue.
second, this "queue" that you are talking about is the mempool and if your tx is in it that means you have already broadcast it and it is out there!

basically this is the steps you take:
1. fill in the information to create a tx (amount, receiving address, fee)
2. sign the transaction and get a tx id
3. broadcast the signed tx
4. receive a message telling you what happened. if it was successful it will show you the tx id again and if it failed it will show you a message containing the reason for failure. if the message indicated success then it means your transaction is already in the queue aka mempool.

[bere3kin]

Ok, guys, thanks for your replies, but we misunderstood each other a little.
Let me explain. First of all, I trying to do it on server side using pyton console, so thing looks a little different.
As pooya87 suggested I tried to sign transaction using signtransaction() method. As a result you can see ["complete"]=> bool(true) means it signed, but string is the same hash instead of tx id. So, how to get tx id before broadcast?



And one more question: is it possible to broadcast the same transaction twice, when first transaction stucked and still not in network, and as a result get double spend? And if so how to prevent it?

[bob123]

So, how to get tx id before broadcast?

Take the encoded transaction, and double hash it with sha256.

Note that bitcoin is using little-endian.

And one more question: is it possible to broadcast the same transaction twice, when first transaction stucked and still not in network, and as a result get double spend?

You can broadcast the same transaction (same inputs, outputs.. exact same TX) as often as you want. 'Broadcasting' simply means sharing the signed transaction with everyone 'you know'.

If you want to double spend, there are multiple ways to do. The most easiest is to create a transaction with the RBF flag.
This allows you to 'bump' the fee (while also changing the 'receiving address').

And if so how to prevent it?

Wait for at least 1 confirmation (recommended).
Or don't accept RBF-tx's (not recommended).

You should in fact ALWAYS wait for 1 confirmation before releasing any digital goods etc..

[bere3kin]

So, how to get tx id before broadcast?

Take the encoded transaction, and double hash it with sha256.

Note that bitcoin is using little-endian.

Not really clear. By my question I ment why signtransaction() doesn't do it? Because as far as I know the short tx id is generated as a result of signing, but not as double hashing, correct me if I'm wrong.

And one more question: is it possible to broadcast the same transaction twice, when first transaction stucked and still not in network, and as a result get double spend?

You can broadcast the same transaction (same inputs, outputs.. exact same TX) as often as you want. 'Broadcasting' simply means sharing the signed transaction with everyone 'you know'.

If you want to double spend, there are multiple ways to do. The most easiest is to create a transaction with the RBF flag.
This allows you to 'bump' the fee (while also changing the 'receiving address').

Look. The simple task I faced: I need to send btc from server and get tx id before it broadcasted, because in some reasons electrum broadcast() result return nothing and transaction appear in network with delay 1 or even 2 minutes later. Or even not appear! Client want to know tx id straight away after withdraw. So I don't need double spend (by this I actually mean send same value to the same address 2 times) and trying to figure out, how to prevent this. In case, when something goes wrong broadcast() also return nothing cause of delay. And what should we do? Send tx again? Or wait until it finally appear in network. That's the question.

[bob123]

Not really clear. By my question I ment why signtransaction() doesn't do it? Because as far as I know the short tx id is generated as a result of signing, but not as double hashing, correct me if I'm wrong.

According to the electrum docs, the TX ID is returned after broadcasting the transaction.

But to generate the ID yourself, technically you simply take the signed transaction and double hash it: tx_id = sha256(sha256(signed_tx))

Look. The simple task I faced: I need to send btc from server and get tx id before it broadcasted, because in some reasons electrum broadcast() result return nothing and transaction appear in network with delay 1 or even 2 minutes later. Or even not appear! Client want to know tx id straight away after withdraw. So I don't need double spend (by this I actually mean send same value to the same address 2 times) and trying to figure out, how to prevent this. In case, when something goes wrong broadcast() also return nothing cause of delay. And what should we do? Send tx again? Or wait until it finally appear in network. That's the question.

Usually the transaction should always appear on the network.
IMO, there is no reason to show the txID initally (before the TX has been broadcasted). But that's just a personal opinion.

To prevent paying out twice (that's not a double spend), simply wait for the TX to be accepted by the network. If it does not appear, rebroadcast the same transaction again.
Just don't create another transaction.

If you want to have full control, simply setup an own electrum server. Then you don't need to depend on an unknown electrum server to broadcast your TX to the network.

[bere3kin]

Ok. Thank you for tips, I'll reply soon after some tests.

[bere3kin]

Well, each topic on forum should be helpful for each other, right? So here is our finall resolution.
First of all, as bob123 suggested we get id by double hashing hex with sha256. In php it looks like:

Code:

$hex = 'your hex';
$tx = hex2bin ($hex);

$tx = hash('sha256', $tx, true);
$tx = hash('sha256', $tx, true);

$tx = bin2hex($tx);

After this you should convert it to Little-Endian, it was surprise that php have no special function for it, so you can do it like this:

Code:

    for ($i = 0; $i < strlen($tx) / 2; $i++){
        $fixedTx = substr($tx, 0, 2) . $fixedTx;
        $tx =  substr($tx, 2);
    }

So now knowing id of transaction we can check the broadcast status by simple method gettransation('tx'). It gives possibility to trace your transaction in network by simple response check.