Pages:
Author

Topic: unconfirmed transactions (Read 2879 times)

hero member
Activity: 868
Merit: 1000
October 27, 2014, 03:36:04 AM
#55
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.
newbie
Activity: 28
Merit: 0
October 26, 2014, 12:12:55 PM
#54
you have just wait, its sometimes happens when you don t use without fee
hero member
Activity: 935
Merit: 1002
October 25, 2014, 01:14:22 PM
#53
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.
hero member
Activity: 499
Merit: 500
October 25, 2014, 07:17:18 AM
#52
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.
hero member
Activity: 935
Merit: 1002
October 25, 2014, 07:00:26 AM
#51
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.
hero member
Activity: 499
Merit: 500
October 25, 2014, 04:52:48 AM
#50
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.
sr. member
Activity: 266
Merit: 250
October 25, 2014, 04:46:21 AM
#49
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.
hero member
Activity: 935
Merit: 1002
October 25, 2014, 03:37:58 AM
#48
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.
legendary
Activity: 2954
Merit: 4158
October 24, 2014, 03:09:34 AM
#47
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.
member
Activity: 110
Merit: 10
October 24, 2014, 02:49:06 AM
#46

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. Smiley

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. Roll Eyes

   ~~MZ~~
I've Used without fee. some confirmed fast, some slow.
newbie
Activity: 55
Merit: 0
October 23, 2014, 07:03:54 PM
#45
it usually happens when you send a small amount fraction below .1 etc.
member
Activity: 89
Merit: 10
October 23, 2014, 06:31:09 PM
#44
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 ...  Roll Eyes
hero member
Activity: 935
Merit: 1002
October 22, 2014, 02:15:22 PM
#43
Your transaction got dropped again quickly resend the transaction with a fee!
full member
Activity: 154
Merit: 100
October 22, 2014, 10:29:39 AM
#42
I think that you have wait! it's already happening to a friend
hero member
Activity: 935
Merit: 1002
October 22, 2014, 09:55:46 AM
#41
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.
hero member
Activity: 560
Merit: 506
I prefer Zakir over Muhammed when mentioning me!
October 22, 2014, 06:56:43 AM
#40

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. Smiley

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. Roll Eyes

   ~~MZ~~
hero member
Activity: 603
Merit: 500
October 21, 2014, 09:08:38 AM
#38
AFAIK, the min tx fee is unchanged for the upgrade from 0.8.x to 0.9.x and remain as 0.0001 btc per KB.
The one lowered to 0.00001 btc per KB is the relay fee.

For the meaning of relay fee, you may refer to https://bitcointalksearch.org/topic/whats-relay-fee-579460
legendary
Activity: 2954
Merit: 4158
October 21, 2014, 09:04:52 AM
#37
Consider to send your transactions with a fee of 0.00000001 (one satoshi) instead of none fee.

Sorry, that's nonsense. Either leave out the fee (and risk that the transaction won't be processed) or add the standard fee of 0.0001 BTC to ensure that everything works as it should.
Miners that refuse to process no-fee transactions would most likely refuse one-satoshi transations as well.

Onkel Paul
currently is ok to use 1 satoshi
No it isn't. 9999 satoshi or anything less than that is considered non standard fee. 1 satoshi won't even increase your priority by a bit and most nodes would consider it as a dust transaction and refuse to relay it. Most mining pool also wouldn't include it in their blocks unless your coin age is high and outputs are more than 0.01 BTC.
That is not absolutely right. First of all there is no such thing as non standard fee(unless it has negative value) every transaction fee included(or not) is considered standard.Secondly you should know that there are 0.9.x miners who mines transaction which put 0.00001(1000 sat) per 1000 bytes so 9999 satoshi fee is 9.999 times higher than they require.
This is what bitcoin wiki tells me
Quote
Note that a typical transaction is 500 bytes, so the typical transaction fee for low-priority transactions is 0.1 mBTC (0.0001 BTC), regardless of the number of bitcoins sent.
By standard transaction fee, I meant the fee for the transaction to be accepted ASAP. Obviously, you don't have to put one if your coin is old enough and have outputs of more than 0.01BTC.
That don't happen with majority of the pools/miners. Most of them require a 0.0001BTC fee at least. Obviously, that depends on the kind of software client they are running, different ones have different behaviour.

hero member
Activity: 935
Merit: 1002
October 21, 2014, 08:41:26 AM
#36
Consider to send your transactions with a fee of 0.00000001 (one satoshi) instead of none fee.

Sorry, that's nonsense. Either leave out the fee (and risk that the transaction won't be processed) or add the standard fee of 0.0001 BTC to ensure that everything works as it should.
Miners that refuse to process no-fee transactions would most likely refuse one-satoshi transations as well.

Onkel Paul
currently is ok to use 1 satoshi
No it isn't. 9999 satoshi or anything less than that is considered non standard fee. 1 satoshi won't even increase your priority by a bit and most nodes would consider it as a dust transaction and refuse to relay it. Most mining pool also wouldn't include it in their blocks unless your coin age is high and outputs are more than 0.01 BTC.
That is not absolutely right. First of all there is no such thing as non standard fee(unless it has negative value) every transaction fee included(or not) is considered standard.Secondly you should know that there are 0.9.x miners who mines transaction which put 0.00001(1000 sat) per 1000 bytes so 9999 satoshi fee is 9.999 times higher than they require.
Pages:
Jump to: