it's -zapwallettxes. not -zapwallettex.
if that still doesn't work run it from the win+r or task manager.

btw make sure that the path is correct.

I would like a simple theme very similar to this one. don't want it too dark as some other stuff posted on the forum will seem too bright, and people can hurt their eyes with dark themes if they switch tab (to other light themed sites.) too much. ofc having more options is good too.

actually I think shorena successfully helped OP double spend the tx (using his node).

I imagine you have the same problem as everyone else. the tx fees is not high enough to get your tx through the currently flooding mempool. (btw I think you're kind of hijacking someone's thread.)

just found out that that thing I posted above is kind of outdated.
now it's
10 + {I*148} + {O*34} plus or minus 'I' = size. give or take few bytes.

source of that here. it's actually not that hard to understand.

it's calculated from the number of input and output.
10 + {I*180} + {O*24} = tx size in byte. give or take few bytes.

edit:
there's a more technical explanation here.

don't know about spam attack but there's an unusually high number of unconfirmed transaction right now. lots of them sends 1-10 satoshi per byte as fee. and the number of txes paying high fee are also a bit higher than usual.

maybe just a busy day.

do this. or if you're using windows just create a shortcut, click properties, and add the command after the target directory (e.g "C:\Bitcoin\bitcoin-qt.exe" -zapwallettxes)

it is likely to get confirmed because of the high priority and a bit of fee.


the heck does that mean?

where did the part about OGnasty comes from?

edit:

---

ah. so that's what happened.

@OP
if this is true then you should double spend it and do it quick because the tx won't need to wait very long to get confirmed.

stop re-broadcasting it and it'll be dropped by the network and returned to your wallet after all node stopped re-broadcasting it (should take one to three days.). core automatically re-broadcast your unconfirmed transactions so you'll need to get rid of them first by running core with -zapwallettxes command (or just enter it from the console.).

who moved this to off-topic? is this real (proof?) or is it an early april fool's joke?

bitcoin core/qt and electrum allows you to set the fee per KB (other wallet may have this feature too.). so if you set them to 0.0002 per kb and send a 512 byte tx the wallet will automatically set the fee to 0.0001.

and it looks like you're using a wallet that does this. only with .0001 per kb fee. not good enough when the mempool is flooding.

yes.
edit:

---

wait. no about the earlier ones (1st and 2nd.). they can go through, sure. but they have a higher chance of not going through at all and returns to the sender's wallet (that is if all node stops re-broadcasting them.).

---

I'd recommend to use this site to determine how many fee you should use. the numbers on the left [x-xx] is the fee per byte, and the meters are the number of current tx waiting in the mempool that used [x-xx] fee and the total tx since 24 hours (confirmed and unconfirmed.). and the delay and time is an estimation of how long a tx with [x-xx] fee will take to confirm.
in short, choose the one with 0-10 delay and 0-240 time. the lower the better (if you can afford it.)

1st tx have very low transaction fee compared to its size.
2nd tx same as 1st.
3rd tx have high priority but spends an input from 2nd tx. you'll have to wait for the 2nd to get confirmed first.
4th tx have high priority but spends an input from this unconfirmed tx. that tx spends an input from the 2nd tx.
5th tx have high priority spends an input from 4th tx.

in short, the source of your problem is the 1st and 2nd txes. and the rest of those transaction need to wait for the other unconfirmed txes starting from the 2nd to confirm.

congrats, cyrus. now we have a Global Ninja Mod in our midst. not sure what's with the ninja thing but congrats all the same.  

you can only wait. that method you posted only works if blockchain.info or whatever service node you're pushing the tx to have dropped your tx.

or you can make the mempool drop that tx by stopping your core from re-broadcasting it and hope that the rest of the network will do the same. bitcoin core automatically re-broadcast your unconfirmed transaction after a while so you'll need to enter -zapwallettxes command from the console (back up your wallet.dat first!). doing that will remove every unconfirmed transaction that you have.
be aware that the btc will return to the sender's wallet if the mempool dropped the tx.

I don't see any reason why this would happen. confirmation time shouldn't be affected by the halving and so is the tx fee.

by ages you mean a while, right? that transaction is likely to get confirmed in a day or two because of the high priority.