Unconfirmed transactions from 0.8.1 w/ low txn fee: what are my options?

[HanSolo]

I've issued some small-size transactions with ~0.00001 to 0.00003 txfees that haven't been confirmed after a few hours... the later ones depend on the earlier ones.

Other than waiting and hoping my client rebroadcasts to a willing miner...

(1) Will the pywallet forget-txid approach described by...

https://bitcointalk.org/index.php?topic=85689.msg944529#msg944529

...still work in the 0.8.1 refactoring? If yes, I'd locally-forget all the unconfirmed transactions, then reissue with higher tx fees (a double-spend-for-good).

(2) Is it worth adding another dependent transaction at the end, with an extra-large tx fee, in hope some miner does a value-of-all-together calc and pulls the earlier txns in with the last? (Any miners doing that, including dependent chains of txns 5+ long?)

Anything else to try? I'm flailing here!

[grue]

if you want to do a double spend, you will have to wait until the transaction drops out of most miners' memory pool. wait a few days, do the forget tx with pywallet, and resend the transaction.

[HanSolo]

if you want to do a double spend, you will have to wait until the transaction drops out of most miners' memory pool. wait a few days, do the forget tx with pywallet, and resend the transaction.

Do you think mining pools are holding the transaction for days -- and thus rejecting conflicts -- even though they're not willing to include it in blocks?

That would seem to be a waste, if there's zero chance of including it (as opposed to just waiting for block space, which because of many recent undersized blocks doesn't seem to be the issue).

[Remember remember the 5th of November]

There is a proposal that will allow you to "update" your transaction unless it was included in a block, like say upping the fee, the old one will NOT be overwritten, but it will likely just get rejected.

I believe this will allow people to fix their transaction with higher fees.

[deepceleron]

As the too-low fees cannot be set in normal bitcoin and would require using the stupid "0 fee fork", I don't have much sympathy. However, very few relays will have these transactions in their memory pool as they also do not meet the minimum relay fees, and a new transaction spending these coins with an appropriate fee would likely go through quickly. You can delete all the unconfirmed transactions with pywallet, and then send your entire balance to a new address in your wallet.

[evilpete]

Do you think mining pools are holding the transaction for days -- and thus rejecting conflicts -- even though they're not willing to include it in blocks?

The backlog has been fairly light lately.  I suspect it is more likely the transactions were outright rejected by the p2p network and they never even made it to the miners.

Do they show up on blockchain.info and blockexplorer?  How about some txid's?   Folks might be able to give you some definitive answers with some details.