Corruption with latest version. about bsvup HOT 9 CLOSED

OK, I think it may be the unreliable of P2P network.

from bsvup.

I'm not sure how's that happened.
But it seem that at least one map tx is broadcasted but lost.
And you must be uploading more than 500 files, so there will be more that 1 map tx.

from bsvup.

Are you uploading more than 10000 files?

from bsvup.

1. if you have more than 25k tasks, the there will be more than 25 maptx, enough to cause 'too-long-mempool-txn'
2. unbroadcast txs will be updated when every txs tried to broadcast, so if you interupt, unbroadcast will not update.
3. As map txs are chained(therefor change output is spent), so, when the previous map tx is broadcasted again, it will cause 'transaction already in block chain' error. (bitcoin-sv/src/rpc/rawtransaction.cpp : 1136)
4. But there are still map txs unbroadcast, so txs depend on the unbroadcast map txs will cause error 'Missing inputs'

That's what I guess.
I think some retries(broadcast the unbroadcast) can solve this, just keep it running.
Once all map txs broadcast, there will be no more Missing inputs.
Then you can ignore transaction already in block chain

from bsvup.

However, the broadcast policy I adopted is dumb, since it still trying to broadcast all transactions when it see 'too-long-mempool-txn'.
bsvup should wait and retry, or update unbroadcast, when too-long-mempool-txn happens.

from bsvup.

I’ve seen the 25 tx issue in earlier versions and it does resolve, but this isn’t resolving. It might be relevent that bsvup terminated without finishing retrying.

Do you think if I pay to restart the upload the terminal output prior to termination would be enough to find the issue?

EDIT: I misread what you said. I don’t have more than 10k files; I don’t see a reason for 25k tasks that seems very excessive.

from bsvup.

That does help.
However, I think you can resume broadcast, and let it retry.

By the way, the transaction itself does not cost a lot, it's just about 200 satoshis per transaction.
If your uploading is not successful, the utxo is still there, and can be reused.
If your uploading is successful, you can take some time and let it check onchain data, it won't be uploaded again.

So, retrying is not quite expensive, as it will not spend for uploading twice.

from bsvup.

Resuming was in an infinite loop of 'Missing Input', which is abnormal for me, and I unfortunately deleted the data. I'm still looking at this. It's probably because one of the new files is 37M, bringing the cost per try to over 0.3 BSV. I'll likely try to shrink this file before trying again.

from bsvup.

this worked fine after shrinking the file. i'll make sure to keep my output in the case of crashes in the future. i didn't find an easy way to restart the transaction once the unbroadcasted tx file was gone.

from bsvup.