maximal real time to be incorparated into the blockchain

[smtp]

Hi

Sorry to bother you with my (probably very special) problem.
If it is inappropriate in this forum , feel free to shift this topic.

Last time, it was in January 2016, I used my bitcoin-qt client to send some BTC it works as expected.
I send 5 BTC and they were put into the blockchain after a few hours. I don't know exactly how long
I had to wait maybe even less than 1 hour.

But last monday, I sent a new transaction about 11 o'clock and it disappeared. ;-O
It looks like it wasn't relayed -- I got no error from my client. But after lunch I wondered that it was not
visible in the unconfirmed transaction list shown on www.blockchain.info.
I guess by an improbable reason it was deleted/not relayed and send the same transaction once again -- from a
back-up of my wallet made before the lost transaction.
I hope that I don't triggered a unknown bug by this action. ;-/

But luckily this transaction was listed as unconfirmed transaction on blockchain.info.

See URL   https://blockchain.info/address/13yTZGFmnbvb9YMKK7nNuHdYZPPAo4gHUv

But it is there listed since more than 46 hours :-(( [to be precise since 2016-04-18 12:58:55 UTC]

Yesterday I got nervous -- I have send dozends of transactions over the years, but NEVER had to wait more than 12 hours (probably even less than 6 hours at the most). I googled a bit a round in the internet and got the impression, that miners now-a-days dismiss the rule to incorporate transactions which higher age which higher priority. And also there was no large backlog (only about 3000 - 9000 transactions during the last 24 h waiting according to blockchain.info).
Even more I got suspicious that there are much less bitcoin-miners (resp. miner-pools) than in earlier days which now tend to force people to use fees, even for standard 0-fee transactions, by delaying 0-fee-transaction for days (or even years!!) :-(. [I got the impression all blocks mined in the last month came from only a dozend mining-pools].

Well, thus the very first time I send a new transaction from my wallet to another address with 4.9999 value + 0.0001 fee BTC.
This TA now is waiting in the unconfirmed TA-pool since more than 24 hours. :-(
But as I understand it can only be put into the blockchain if the first 0-fee TA is incorporated which it uses.

And if no miner will ever do this, my wallet with all its BTC is absolutely worthless because it is blocked. There is no way I can deleted a TA from the pool of all unconfirmed TAs. And as long as the BTC-network will not be completedly reset / die, this TA will be always sent forever between the bitcoin-nodes and never be disgarded from the network.

I 'm hopefully wrong with my last scenario, am I? What can I do to activate my wallet effectively -- get the hanging TA lost or better incorporated it into the blockchain in say (to stay realisticly) 1 or 2 days, finally? Hopefully not be forced to denote a mining pool an extra money for doing this? :-(

BTW: I have the bad feeling millions of "normal" customers are effectively depend on the grace/will of the say, biggest 10, mining pools. :-/

Thanks for any constructive help,
Achim

BTW: Forgive my spelling errors.

[longbob72]

you'll just have to wait until some miners includes the transactions in a block. the second transaction spends an input from the first transaction so it won't get any confirmation before the first one gets confirmed.

alternatively you can sort of cancel those transactions by running bitcoin qt with ^{-zapwallettxes} command and waiting for at least 48 hours before sending them again with higher fee.

[DannyHamilton]

Each wallet behaves differently depending on how the creators of the wallet decided they wanted it to work.

Therefore, suggestions such as "wait until some miners includes the transactions in a block" or "cancel those transactions by running bitcoin qt with -zapwallettxes command" might be useless and invalid advice.

The first thing you'll need to share with us to receive good advice is what wallet software (and what version of that software) you are using.

In your post you state that you used Bitcoin-QT in January, but I assume you either used a different wallet this time, or you changed some settings on your Bitcoin-Qt wallet because Bitcoin-Qt doesn't re-use the same bitcoin address when you have the default settings.

If you used an old version of Bitcoin-Qt with modified settings, then you probably should upgrade to the latest version (now called Bitcoin Core).  As longbob72 has implied, recent versions of Bitcoin Core include a command line option "-zapwallettxes" that will remove unconfirmed transactions from your wallet.

If you have upgraded to a recent enough version of Bitcoin Core, then after using the -zapwallettxes option, you can wait a day or two and the network will forget about your two unconfirmed transactions.  Once that has happened, you can create and broadcast a new transaction with your wallet.

[smtp]

Thanks for your thoughts, Danny.

The first thing you'll need to share with us to receive good advice is what wallet software (and what version of that software) you are using.

In your post you state that you used Bitcoin-QT in January, but I assume you either used a different wallet this time, or you changed some settings on your Bitcoin-Qt wallet because Bitcoin-Qt doesn't re-use the same bitcoin address when you have the default settings.

0) I don't need to delete the TAs from wallet(-history), but from unconfirmed-TA-bitcoin-network-(nodes-)pool ! (I have older usable back-up wallets).

1) Always I use bitcoin-qt 0.8.6.0 since the last years.

2) You are wrong. Bitcoin-Qt 0.8.6.0 (and also older version I used)  reuse the same bitcoin address often -- as I can simply state from own expierience.
    It is a pity that you can not see the set of in-use-addresses and moreover control from which addresses coins should be used/sent for a new TA. :-/

3) Meanwhile both Tas are deleted from the unconfirmed TA-Pool listed at blockchain.info. It happens during I wrote my first message about 3,5 hours ago (which sadly got lost due to user-error on handling this web-posting-software while reviewing). Thus I know it was more than 48 hours listed but less than 49 hours. The second seems to be deleted in the same short time interval. Thus I assume someone (at blockchain.info?) removed both Tas manually after reading my post here.

Thank you.

Regards
achim

[shorena]

Thanks for your thoughts, Danny.

The first thing you'll need to share with us to receive good advice is what wallet software (and what version of that software) you are using.

In your post you state that you used Bitcoin-QT in January, but I assume you either used a different wallet this time, or you changed some settings on your Bitcoin-Qt wallet because Bitcoin-Qt doesn't re-use the same bitcoin address when you have the default settings.

0) I don't need to delete the TAs from wallet(-history), but from unconfirmed-TA-bitcoin-network-(nodes-)pool ! (I have older usable back-up wallets).

1) Always I use bitcoin-qt 0.8.6.0 since the last years.

2) You are wrong. Bitcoin-Qt 0.8.6.0 (and also older version I used)  reuse the same bitcoin address often -- as I can simply state from own expierience.
    It is a pity that you can not see the set of in-use-addresses and moreover control from which addresses coins should be used/sent for a new TA. :-/

3) Meanwhile both Tas are deleted from the unconfirmed TA-Pool listed at blockchain.info. It happens during I wrote my first message about 3,5 hours ago (which sadly got lost due to user-error on handling this web-posting-software while reviewing). Thus I know it was more than 48 hours listed but less than 49 hours. The second seems to be deleted in the same short time interval. Thus I assume someone (at blockchain.info?) removed both Tas manually after reading my post here.

Thank you.

Regards
achim

I dont think that someone from bc.i is reading along here and removing your transactions from their mempool. I suspect that your client is set to pay a too small fee, which causes bc.i to remove it from mempool automatically. Later versions of qt/core have a fee estimate to avoid this. Can you post the raw transaction so we can take a look at it? You get it by entering

Code:

getrawtransaction txid

in the console. "txid" beeing a placeholder for your transaction id.

[smtp]

I dont think that someone from bc.i is reading along here and removing your transactions from their mempool. I suspect that your client is set to pay a too small fee, which causes bc.i to remove it from mempool automatically. Later versions of qt/core have a fee estimate to avoid this. Can you post the raw transaction so we can take a look at it? You get it by entering

Code:

getrawtransaction txid

in the console. "txid" beeing a placeholder for your transaction id.

Sorry, too late. I have no copy of the raw transaction anymore -- I remember the default 1 txin, 2 txout script and about 257 bytes from my memory/brain when looking at the above mentioned URL. There I also clicked the button for show/hide-script ). Immediately after I recognized the deletion of the two TAs in the unconfirmed TA-pool listed on blockchain.info (see the above URL), I deleted my current wallet and the last backup wallet and restarted my bitcoin-qt client with a backup wallet from January 2016. From this I send a new transaction which surprisingly was put into the next new block. From my last experiment of yesterday,  I have set my default fee to 0.0001 BTC and will reuse this now as my private standard because miners seems no longer to put standard 0-fee transactions (preciser only with very low probability -- I checked for the number of the incorporated 0-fee transactions in the last 24 hours in the blockchain -- even blockchain.info now calculates the median expectation time ONLY for TAs with non-zero fee in their public chart!).

My bitcoin-qt client (version 0.8.6.0 -- unpatched -- the original, has a standard of 0-fee which you may/can change in the configuration menu/popup)

Regards,
achim

[smtp]

Still an appendix to your last please/question: Look at the
URL  https://blockchain.info/tx/b92e377073088d714d0850d49116835f1ae8cdb9acb4be229faaeecde8fea5cc

Of course this is the finally accepted new TA which is now in the blockchain. The TA which was hanging for 48 hours (listed in blockchain.info's pool as unconfirmed transaction), had exactly the same structure. Only one txout-address was different and its value was not 9.9999 BTC, but exactly 5 BTC (and 130 BTC were reused and not 125 BTC by the same txin-address).

I hope this helps a bit.

[shorena]

Still an appendix to your last please/question: Look at the
URL  https://blockchain.info/tx/b92e377073088d714d0850d49116835f1ae8cdb9acb4be229faaeecde8fea5cc

Of course this is the finally accepted new TA which is now in the blockchain. The TA which was hanging for 48 hours (listed in blockchain.info's pool as unconfirmed transaction), had exactly the same structure. Only one txout-address was different and its value was not 9.9999 BTC, but exactly 5 BTC (and 130 BTC were reused and not 125 BTC by the same txin-address).

I hope this helps a bit.

The thing is that there is no longer a "standard fee" you can set or remember and always get a quick confirmation. Thats the reason newer versions of bitcoin core come with an algorithm to estimate a good fee for the current[1] state of the network. If you do not want to update for some reason at least check with pages like https://bitcoinfees.21.co/

[1] obviously this isnt entirely true, as the data will always be slightly outdated

[smtp]

The thing is that there is no longer a "standard fee" you can set or remember and always get a quick confirmation. Thats the reason newer versions of bitcoin core come with an algorithm to estimate a good fee for the current[1] state of the network. If you do not want to update for some reason at least check with pages like https://bitcoinfees.21.co/

[1] obviously this isnt entirely true, as the data will always be slightly outdated

I stumpled already over this URL https://bitcoinfees.21.co/ when I googled for infos on tuesday in the internet (and still wonder what its heading "since 1759" means).
Do you know a URL where I can watch the current size (say in MB) of total unconfirmed transactions waiting  for inclusion into the blockchain (and perhaps their number)?

Regards
achim

[shorena]

The thing is that there is no longer a "standard fee" you can set or remember and always get a quick confirmation. Thats the reason newer versions of bitcoin core come with an algorithm to estimate a good fee for the current[1] state of the network. If you do not want to update for some reason at least check with pages like https://bitcoinfees.21.co/

[1] obviously this isnt entirely true, as the data will always be slightly outdated

I stumpled already over this URL https://bitcoinfees.21.co/ when I googled for infos on tuesday in the internet (and still wonder what its heading "since 1759" means).

No idea, beer reference? -> https://en.wikipedia.org/wiki/Category:Companies_established_in_1759

Do you know a URL where I can watch the current size (say in MB) of total unconfirmed transactions waiting  for inclusion into the blockchain (and perhaps their number)?

Regards
achim

This is node specific, e.g. blockchain.info[1], my new[2] and my old[3] node disagree on the number of unconfirmed transactions. It depends on the configuration of the node and the amount of memory you allow transactions to take. Another factor is uptime. Keep in mind that "usage" is not the sum of all TX sizes, is the amount of memory used. I dont track bytes separately though.

Code:

{
  "size": 17469,
  "bytes": 224345760,
  "usage": 481174672,
  "maxmempool": 1000000000,
  "mempoolminfee": 0.00000000
}

[1] https://blockchain.info/en/unconfirmed-transactions
[2] http://188.68.53.44/
[3] http://213.165.91.169/

[smtp]

This is node specific, e.g. blockchain.info[1], my new[2] and my old[3] node disagree on the number of unconfirmed transactions. It depends on the configuration of the node and the amount of memory you allow transactions to take. Another factor is uptime. Keep in mind that "usage" is not the sum of all TX sizes, is the amount of memory used. I dont track bytes separately though.

Code:

{
  "size": 17469,
  "bytes": 224345760,
  "usage": 481174672,
  "maxmempool": 1000000000,
  "mempoolminfee": 0.00000000
}

[1] https://blockchain.info/en/unconfirmed-transactions
[2] http://188.68.53.44/
[3] http://213.165.91.169/

Yes, of course it is node specific. But from the pragmatic point of view it is most important to know which unconfirmed TA
  W I L L   be included into the blockchain. I'm afraid this is undefined. :-/ There are still dozends of 0-fee TAs included a day, but e.g. my
two TAs were deleted/forgotten. I'm even not sure whether also non-0-fee TAs were/are forgotten which were/are totally valid.
At least it would be very helpful to have a probability whether a given TA will be included into the blockchain. http://bitcoinfees.21.co/ seems to be of no help to this last question, isn't it?

Regards
achim

[Lauda]

I'm even not sure whether also non-0-fee TAs were/are forgotten which were/are totally valid.
At least it would be very helpful to have a probability whether a given TA will be included into the blockchain. http://bitcoinfees.21.co/ seems to be of no help to this last question, isn't it?

As far as I know there are no websites that show probability calculation, and you can't calculate this based on a single node (i.e. your node). Different nodes have different rules. When it comes to zero confirmation transactions you can see that the delay is estimated between 15-Inf amount of blocks. It is like that for a reason.

[shorena]

I'm even not sure whether also non-0-fee TAs were/are forgotten which were/are totally valid.
At least it would be very helpful to have a probability whether a given TA will be included into the blockchain. http://bitcoinfees.21.co/ seems to be of no help to this last question, isn't it?

As far as I know there are no websites that show probability calculation, and you can't calculate this based on a single node (i.e. your node). Different nodes have different rules. When it comes to zero confirmation transactions you can see that the delay is estimated between 15-Inf amount of blocks. It is like that for a reason.

If your node has a very large amount of the available TX you can use it to make a good guess though. E.g. you can use estimatepriority[1] and estimatefee[2] to see how your TX is faring among the others you know about. If you are on the top20 in terms of priority among >50k TX its likely that your TX will get a confirmation without fee. It might not be in the next block though. 21.co does not take the priority into consideration. I guess because most dont even know to calculate (or query) the priority of their TX.

[1] https://bitcoin.org/en/developer-reference#estimatepriority
[2] https://bitcoin.org/en/developer-reference#estimatefee