unconfirmed transactions

[yakuza699]

Has anyone ever tried to send a transaction with .00000001 fee?
I did various;

• 83 minutes: 5457c17730a26da278ddf205246d05fc37f1219a790d929345752d3aeb867ce6
• 22 minutes: 6b24f6dd17f144fd90b1fc198c83a61b9f8f9ea04b0b3341e9cc0b9ade4a8446
• 3 minutes: 60ed62cc99fbccda0414f703b5833d5d43fc19000de4576e7eb412b3e373c270
• 39 minutes: 4a37a422c88bc18097cd0525b8c8e14132f5ce7bdde912d2904df9d396b298d2
• 137 minutes: 38c14c2390344611d85750fd58183fda9e8e6cb5b8d4202bb6442e6888a5ed19
• 8 minutes: 7427640b18d909dcb6974b8d83ef0ced4fd18519a3a16d1c2db284416dc397f1
• 11 minutes: 1b1cc2964d4fa94320de0df1db04883cffd18af3e98843b427b743e9bf0eead2
• 56 minutes: a9ff214c644d43409726fae423e24a36492ca315745428928260761d3434e20f
• continue...

It took an average of 20 minutes to confirm.

All the transactions above were 0.9 btc and more so it requires only one day for the inputs to be old enough(remember 1BTC one day(144confirms) 0.1BTC 10days(1440confirms)), thus meaning you could have set even the 0 fee and it still would have confirmed quit quickly. If you would have experimented with lower amounts(and not old) confirmation would have taken way way more time.

[mullerdan]

I think that you have wait! it's already happening to a friend

[yakuza699]

Your transaction got dropped again quickly resend the transaction with a fee!

[aronnov]

all you have to do is just to wait for the confirmation is completed, if not completed the necessary confirmation of the bitcoin sent to us will never get to address our wallet ... 

[Galio]

it usually happens when you send a small amount fraction below .1 etc.

[Centaurus]

Has anyone ever tried to send a transaction with .00000001 fee?
I did various;

• 83 minutes: 5457c17730a26da278ddf205246d05fc37f1219a790d929345752d3aeb867ce6
• 22 minutes: 6b24f6dd17f144fd90b1fc198c83a61b9f8f9ea04b0b3341e9cc0b9ade4a8446
• 3 minutes: 60ed62cc99fbccda0414f703b5833d5d43fc19000de4576e7eb412b3e373c270
• 39 minutes: 4a37a422c88bc18097cd0525b8c8e14132f5ce7bdde912d2904df9d396b298d2
• 137 minutes: 38c14c2390344611d85750fd58183fda9e8e6cb5b8d4202bb6442e6888a5ed19
• 8 minutes: 7427640b18d909dcb6974b8d83ef0ced4fd18519a3a16d1c2db284416dc397f1
• 11 minutes: 1b1cc2964d4fa94320de0df1db04883cffd18af3e98843b427b743e9bf0eead2
• 56 minutes: a9ff214c644d43409726fae423e24a36492ca315745428928260761d3434e20f
• continue...

It took an average of 20 minutes to confirm.

The lowest amount I use is 1 uBTC. We can save our BTC, but because of miners, TXs are confirming, so it is better to send atleast 1 uBTC and if you can 0.1 mBTC.

P.S. When I looked the TX, all the tx were above 0.01BTC, so it has more chance to get confirmed even if you didn't send any fees. I think that is why, it confirmed in a short period.

   ~~MZ~~

I've Used without fee. some confirmed fast, some slow.

[ranochigo]

it usually happens when you send a small amount fraction below .1 etc.

Wrong, transactions above 0.01 will confirm relatively fast if the coin age is high. Transaction above 0.01 can confirm slowly without a fee if the coin age is low. I haven't heard of cases which the transaction gets stuck when transacting 0.01BTC and above without fee.

[yakuza699]

It has been 3 days since the transaction got dropped I hope you resent it with a fee good luck and next time don't forget to put a fee.

[bitnanigans]

Accidentally sent a low transaction without a fee and I've been waiting for over 12 hours now for it to get confirmed. At this rate, I highly doubt it would. I know transactions are not reversible, but a nice feature to have would be the ability to cancel transactions that have 0 confirmations after a certain period of time has elapsed.

[PangPang]

I know transactions are not reversible, but a nice feature to have would be the ability to cancel transactions that have 0 confirmations after a certain period of time has elapsed.

The bitcoin nodes will soon drop those 0-confirmation transactions (after a day or a few days), and then you could create another transaction to double spend the original unconfirmed one.

[yakuza699]

I know transactions are not reversible, but a nice feature to have would be the ability to cancel transactions that have 0 confirmations after a certain period of time has elapsed.

The bitcoin nodes will soon drop those 0-confirmation transactions (after a day or a few days), and then you could create another transaction to double spend the original unconfirmed one.

I would not say that this is actually double-spending, spending the inputs that has never been spent before is not double-spending.

[PangPang]

I know transactions are not reversible, but a nice feature to have would be the ability to cancel transactions that have 0 confirmations after a certain period of time has elapsed.

The bitcoin nodes will soon drop those 0-confirmation transactions (after a day or a few days), and then you could create another transaction to double spend the original unconfirmed one.

I would not say that this is actually double-spending, spending the inputs that has never been spent before is not double-spending.

You are kind of right there.
In fact, I see people using the term "double spend" in two different ways, and to be honest I don't know which is the more accepted one.

1. There are two unconfirmed transactions spending the same inputs.
2. A transaction is confirmed in a block, the block is then orphaned, and another transaction spending the same inputs is included in a longer main chain.

[yakuza699]

I know transactions are not reversible, but a nice feature to have would be the ability to cancel transactions that have 0 confirmations after a certain period of time has elapsed.

The bitcoin nodes will soon drop those 0-confirmation transactions (after a day or a few days), and then you could create another transaction to double spend the original unconfirmed one.

I would not say that this is actually double-spending, spending the inputs that has never been spent before is not double-spending.

You are kind of right there.
In fact, I see people using the term "double spend" in two different ways, and to be honest I don't know which is the more accepted one.

1. There are two unconfirmed transactions spending the same inputs.
2. A transaction is confirmed in a block, the block is then orphaned, and another transaction spending the same inputs is included in a longer main chain.

There is the third one where an attacker gains 51% of the network hashing speed and then he could send two transactions which spends at least one same input and include them both in the block, and the block would not be orphaned. But I use the first one where two transactions spends same inputs but only one gets confirmed and one gets dropped.

[keackh]

you have just wait, its sometimes happens when you don t use without fee

[Sonny]

It seems the problem is solved completely now.
OP has created another transaction with standard fee to replace the original one, and it is confirmed already.