added option -forceresendtx #421

pull phantomcircuit wants to merge 4 commits into bitcoin:master from phantomcircuit:forceresendtx changing 5 files +20 −7

phantomcircuit commented at 11:07 PM on July 20, 2011: none

adds an option to force resending wallet transactions immediately upon startup
added option -forceresendtx 4167579832
added resendtxs rpc call 13a5f75b5e
sipa commented at 8:57 AM on July 25, 2011: member

This will retransmit everything upon startup, and never afterwards?
phantomcircuit commented at 9:27 AM on July 25, 2011: none

This retransmits immediately after starting up or receiving the rpc call. And then proceeds as normal resending every 0 to 30 minutes.
Merge branch 'master' of git://github.com/bitcoin/bitcoin into forceresendtx 155cfbbb8a
gavinandresen commented at 4:16 PM on August 9, 2011: contributor

One nit to pick: Can you add -forceresendtx to the -? help output? Otherwise, looks good to me.
Merge branch 'master' of git://github.com/bitcoin/bitcoin into forceresendtx 06c55f8d7d
alexwaters commented at 8:05 AM on September 30, 2011: contributor

The pull has become unmergeable (without conflicts), and will be closed in 15 days from this message if action is not taken.

To prevent closure, kindly rebase the pull to merge cleanly with the current codebase. If a time extension is needed, please respond to this comment or contact QA@BitcoinTesting.org.

EDIT: Awaiting phantomcircuit's clean rebased pull
luke-jr commented at 6:13 PM on October 12, 2011: member

I suggest using a JSON-RPC call instead.
phantomcircuit commented at 6:41 PM on October 12, 2011: none

This patch includes a JSON-RPC call resendtxs which does the same thing as the cli option.

I believe that I messed up this patch and included another patch I'll resubmit a clean rebased pull request... later.
luke-jr commented at 7:41 PM on December 2, 2011: member

Any update/rebase on this?
luke-jr commented at 3:20 PM on December 23, 2011: member

I have rebased this in my own 'forceresendtx' branch.
gavinandresen commented at 4:06 PM on December 23, 2011: contributor
Looking closer at this... I think it needs some reworking.
- bool arg should be fForceResend according to coding conventions
- I think the resendtxs RPC call should return the number of transactions re-sent
- Default function arguments are no-ops if they're put in .cpp files instead of headers, remove them.
I think either the RPC call or the command-line argument is wrong; if -forceresendtx is specified, then SendMessages() will repeatedly call ResendWalletTransactions(true).

If that CONSTANTLY resends, then it is a bug. If that does not constantly resend, then the RPC call will do nothing.
mikehearn commented at 4:57 PM on March 10, 2012: contributor

Why not just make this the default? Is there any downside to announcing all pending transactions on startup?
TheBlueMatt commented at 4:42 PM on March 12, 2012: member

It makes it clear which txes belong to the local node, if they are getting announced all at once at startup.
in src/wallet.cpp:None in 06c55f8d7d
```
 696 | @@ -697,7 +697,7 @@ void CWallet::ResendWalletTransactions()
 697 |              CWalletTx& wtx = item.second;
 698 |              // Don't rebroadcast until it's had plenty of time that
 699 |              // it should have gotten in already by now.
 700 | -            if (nTimeBestReceived - (int64)wtx.nTimeReceived > 5 * 60)
 701 | +            if (nTimeBestReceived - (int64)wtx.nTimeReceived > 5 * 60 || forceResend)
```
rebroad commented at 4:59 PM on March 20, 2012:

So this is for people who don't want to wait 5 hours, and instead they can quit bitcoin-qt and run it again with this flag? First question that comes to my mind is: how frequent to resend txs is deemed too frequent?

sipa commented at 5:21 PM on March 20, 2012:

Rebroadcasts already happen every (at most) 30 minutes, on average faster.

rebroad commented at 5:25 PM on March 20, 2012:

Can't see much use in this change if that's the case then - why not introduce a menu option instead to resend? Is this fixing a problem that actually exists? If it does exist, is it fixing it in the right place?
gavinandresen closed this on Apr 2, 2012
dexX7 referenced this in commit e6a236c99d on Nov 3, 2016
sipa referenced this in commit 7b49f22bdb on Dec 12, 2016
MarcoFalke referenced this in commit 64dfdde0aa on Dec 13, 2016
deadalnix referenced this in commit 40c8d7e8bf on Jan 19, 2017
classesjack referenced this in commit 43f25a37fd on Jan 2, 2018
rajarshimaitra referenced this in commit f6fd688018 on Aug 5, 2021
DrahtBot locked this on Sep 8, 2021

Contributors

Labels