Topic: Over an hour and still waiting for confirmation? (Read 4248 times)

No. There's nothing you can do.

Ah ha, thanks. The sender said he attached a transaction fee, but perhaps he forgot to. Would sending BTC to myself with 0.01 transaction fee speed things up any?

It's queued, but low priority. There is no fee. See:
http://bitcoincharts.com/bitcoin/

The hash is:
CTransaction(hash=91d1df25b4, ver=1, vin.size=5, vout.size=1, nLockTime=0)

There actually are inputs ("CTxIn"). I'm not sure why they're not listed separately under "Inputs". Maybe inputs are only listed there when you're sending a transaction.

Thanks for your time.

Post the tx dump.

I don't know if it's proper for me to be (sort of) grave-digging or if I should have started a new thread, but I have exactly the same concerns... except in our case it's been about 4 hours (and many, many blocks) and still no confirmations.

I had the sender attach a transaction fee for the exact reason of avoiding a huge delay waiting for confirmations, and it's still sitting there unconfirmed. I've got the client running in debug mode, and when I double click it there's no inputs... is there something either I or the sender did wrong?

My guess is that the transaction has no inputs because the transactions that funded it are unconfirmed too? If that's the case what's the proper procedure for getting the chain of transactions confirmed? Would sending another payment to myself with a bigger transaction fee help speed things up? What's the cost/payoff ratio in that case, for future reference.

Just trying to figure this whole thing out and would really appreciate some advice - given that blocks are being generated at a good whip, and that some of the blocks were empty of transactions I didn't figure we'd have to wait so long for confirmations.

There could be a number of motivations, not the least of which is geek vandalism.  Comparable to a graffettii artist.  Basicly just because one could.  Secretly strike back at the new "Man" in a Bitcoin future.

Why would somebody do that?  What is the advantage for them?

Spam = transactions made for the purpose of disrupting the network.

Up to this point I thought of spam as unsolicited, commercial, bulk email.

By 'spam', do you mean like a DOS attack on someone's node?

In that case, it all makes sense.

Tying up funds makes it more difficult for an attacker to spam. Spamming 1000 BTC transactions is more difficult than spamming 0.01 BTC transactions.

Is that good or bad? I don't understand this answer, and why miners would care what value the transactions are.

Yes it's optional. My understanding is that if you opt to pay say 0.01 per kb for your transactions, then that'll help them to get process priority.

What I don't understand is how large amounts automatically get process priority, even when the fee is set to 0.00... what's the incentive for the miner to choose these over small amounts?

It was given lower priority because of its low value. A transaction moving, say, 1000 BTC would probably have gotten included ASAP. Same for a transaction with a fee. The priority system is meant to make real transactions faster than spam transactions. Sending 0.03 BTC looks more like spam, especially when you use inputs with relatively few confirmations.


There's no obvious incentive for processing free transactions at all, but miners still do it currently. Higher-value transactions are given priority because it ties up more funds.

Ok, it just came through at roughly an hour and a half.
Is that about what I can expect?

Here's the dump:

Status: 0/unconfirmed
Date: 4/17/2011 21:08
To: 1Nc9CNRSbgydVWvD7MeSmpfVRSxfrcxHE4
Debit: -0.03
Net amount: -0.03

debug print
Debit: -0.01
Debit: -0.02
Transaction:
CTransaction(hash=f35f5852c8, ver=1, vin.size=2, vout.size=1, nLockTime=0)
   CTxIn(COutPoint(6af6bc1d2b, 1), scriptSig=3046022100c848339b1e6cfd)
   CTxIn(COutPoint(7899c14c8f, 0), scriptSig=3045022010927d40c68191fa)
   CTxOut(nValue=0.03000000, scriptPubKey=OP_DUP OP_HASH160 ed000ab48bd6)
Inputs:
CTransaction(hash=6af6bc1d2b, ver=1, vin.size=1, vout.size=2, nLockTime=0)
   CTxIn(COutPoint(6a1605fb0d, 0), scriptSig=3044022041513cc92b854c07)
   CTxOut(nValue=1.37000000, scriptPubKey=OP_DUP OP_HASH160 57dea564b9bf)
   CTxOut(nValue=0.01000000, scriptPubKey=OP_DUP OP_HASH160 944c5cc07a22)
   105 confirmations, IsMine=true
CTransaction(hash=7899c14c8f, ver=1, vin.size=1, vout.size=1, nLockTime=0)
   CTxIn(COutPoint(9a80be4e5c, 0), scriptSig=304502207ce5e0a4093ab648)
   CTxOut(nValue=0.02000000, scriptPubKey=OP_DUP OP_HASH160 cbe868214131)
   36 confirmations, IsMine=true

Before running with debug it said something about having broadcast through 9 nodes.

dood,
I'm clearly new at this so I can't answer your question.
From my reading the transaction fee is optional at least until some indeterminate time in the future?
If everything requires a transaction fee to be processed at all than I guess I've misunderstood what bitcoin was.
Are you saying that unless I pay a transaction fee its up in the air whether the transaction will be processed?

If the transaction fee is set to 0.00 anyway, then what's the incentive for a miner to process higher value transactions?

Sometimes it takes a while, especially if the transaction is low-value.

Run Bitcoin with the -debug switch, double-click the transaction, and post the transaction dump.

Thanks to some friendly people on this site I got a few bitcents to play with and tried a few transactions this weekend.
While the first couple I made seemed to get confirmed in about a half hour I'm waiting on one right now for over an hour.
I've seen 5 or 6 blocks get generated since the transaction was submitted but still nothing.
Is this normal? Are there transactions that just never get confirmed?