0 confirmations after over a month, WTF?

[hugolp]

A while back I seem to remember somebody saying something about problems with the bitcoin client running from an encrypted home directory on OS X.  I do notice that it runs much more responsively from a non-encrypted account.  On my encrypted account sending bitcoins can take up to 10 minutes, and usually during that time the CPU is being used a lot and Activity Monitor reports bitcoin as "not responding".

Edit:  Oh, and my latest transaction shows 1 confirmation now, so it looks like it worked...after over 2 hours.  Is this how this whole thing scales?  In another year I can imagine it being no faster than the present banking system for international transactions.

2 hours for the first confirmation is not normal. It has never taken so long for me.

[1714983253]

1714983253

[1714983253]

1714983253

[1714983253]

1714983253

[1714983253]

1714983253

[Remember remember the 5th of November]

Maybe this problem will motivate you to send fees. Like i always do.

[deepceleron]

Are you sending with miner fees?  I'm seeing more and more fees are required (beyond what the client is asking for) to get transfers though in any reasonable timeframe.

No, I haven't sent with any fees.  So, what, since I didn't add any fees it's going to take months to get the transactions through?  Without paying the fee might they never get processed?

Fees are required in most cases, it is part of the design of Bitcoin to compensate miners for the work they do making it cryptographically difficult to attack the blockchain. If you sent without fees, then you would have used an altered client that doesn't comply with the fee rules, and you get to eat your humble pie.

Older bitcoin clients (in bitcoind at least) have this option to remove unconfirmable cruft, but this does not seem to be present in .23 onwards:
deletetransaction <txid>
Normally used when a transaction cannot be confirmed due to a double spend.
Restart the program after executing this call.

[defxor]

Maybe this problem will motivate you to send fees. Like i always do.

If you sent without fees, then you would have used an altered client that doesn't comply with the fee rules

Wait, what? None of the two replies above have anything to do with the issues discussed in this thread.

(TX not getting sent at all is not due to fees and fee-less .24 is a configuration option and not something "altered")

In my case I have two identical clients where one cannot send while the other can. I've even copied the blockchain between them so I know it's not corrupt.

[deepceleron]

Maybe this problem will motivate you to send fees. Like i always do.

If you sent without fees, then you would have used an altered client that doesn't comply with the fee rules

Wait, what? None of the two replies above have anything to do with the issues discussed in this thread.

(TX not getting sent at all is not due to fees and fee-less .24 is a configuration option and not something "altered")

In my case I have two identical clients where one cannot send while the other can. I've even copied the blockchain between them so I know it's not corrupt.

I am referring to the case of the original poster, not your followup posts which may or may not be the same issue. At this time I have not reviewed what you have posted closely, but it is important to note how the Bitcoin transaction fee policies come about:

-0.01 BTC fee per kilobyte of transaction, but:
  -If the blocksize (size of all transactions currently waiting to be included in a block) is less than 27 kB, transactions are free.
  -If the blocksize is more than 250 kB, transactions get increasingly more expensive as the blocksize approaches the limit of 500 kB. Sending a transaction when the blocksize is 400 kB will cost 5 times the normal amount; sending when it's 499 kB will cost 500x, etc.

-If the blocksize is over 4kB, free transactions in the above rules are only allowed if the transaction's priority is above a certain level.

-Transactions within each fee tier are prioritized based on several factors. Most importantly, a transaction has more priority if the coins it is using have a lot of confirmations. Someone spamming the network will almost certainly be re-using the same coins, which will lower the priority of their transactions. Priority is also increased for transactions with more BTC, and reduced for transactions with more data.

You can see the more factors in play, the lower the priority. Version 0.3.23 requires a minimum of .0005 BTC for low priority transactions.

This means there are several factors involved whether the bitcoind that p2p network members and miners are using relays a transaction or includes it in a block, and the newer version of bitcoind have different rules.

I can deduce from the screenshot that the original poster's bitcoin address is 1NUd7YZYkVYoue7BgY6URsfKCLDRnu7CgL. Here are the transactions that were picked up:

http://blockexplorer.com/tx/fc7f3b9b37ebd99a5c4479938f017425457aa392478dae4deed20382cf7a0778#i621162
fee paid: 0

http://blockexplorer.com/tx/4b66d56b8b9fed33f94c21082b6f0756c407c6f41e967dcf94b304c67210b3cb#i727079
fee paid: 0

http://blockexplorer.com/tx/400f321bf6d058d5ed59acc18a25cbf16976fc96bf13f7009c435f307c637209#i872806
fee: 0

http://blockexplorer.com/tx/e995efbd5e993293e393f4b92e3d082f6be4bfa3f05bb7bfc0681dcdd2fd8d4f#i888845
fee: 0

(un-relayed transaction here)

http://blockexplorer.com/tx/cdce1cf30ab041015ae5150eaa8702bf1d37ab1d27c50030bcbc8f6cc4184951#o0
fee: .1

As we can see, there's a lot of no-fee paying. If you read the rules above, you see that several factors affect whether a free transaction gets forwarded or included in the block chain - how many other transactions are already waiting to be included in a block, how recent the coins are that are being used (note the original poster just received a payment the day before, new coins could have been used in the transaction), the size of the transaction, etc. The current bitcoin client will evaluate these rules and indicate the fee to be paid on the transaction, and the other clients know these rules and can decide to toss it in the bit bucket if it doesn't qualify to be free. Note that the client version of other clients on the network gets updated, so previously lenient rules may be more enforced.

While you can set the TXFEE=0 in the newest client's config file, it will not allow you to send transaction that would require a minimum fee (at least not without some hacking or using a non-official version). If the newest mainline client doesn't prompt for a fee, that's because you are in the rare position of using old coins, there are low transactions waiting on the network, and the size of the transfer in KB is small (mainly because you are spending just coins from a single input.)

[defxor]

I am referring to the case of the original poster, not your followup posts which may or may not be the same issue.

I'm indeed talking about "0/unconfirmed" (even "0/offline?") and never announced, with an 8 peer connected client fully up to date (and getting updates) block chain.

The thread starter had a month old transaction. Even with zero fees that would've gone through. It's likely it, like in my case, was never announced.

[defxor]

In my case I have two identical clients where one cannot send while the other can. I've even copied the blockchain between them so I know it's not corrupt.

So, just for fun, I redid the exact same transaction I couldn't do with one client with the other one instead. Again, the only real difference is that one is port mapped and has >100 connections, the other is behind NAT with 8. They use the same block chain files, they're up to date and all that.

Both clients seem to write 1MB/s constantly to disk (can someone else on Mac please check this? edit: And are you using Filevault) but the well-connected one runs off an SSD which means I've never noticed it before.

NAT client: "0/unconfirmed", "0/offline?" - sends are never announced. Tried multiple times to send 2 BTC (old coins), no fee.

Mapped client: Sent 1 BTC (old coins), no fee. The announce was instantly visible on bitcoincharts/bitcoin and after a few minutes it could be seen in blockexplorer and had 1 confirm.


I guess one explanation lies in how many peers they have, but the NATed client is never even able to make the announce to the network even though it gets block updates just fine. If that's the general state for NAT clients then that needs to be rethought. Else I'm leaning towards an OS X specific problem in .24 that might or might not be related to the weird disk writes.

[Xephan]

I guess one explanation lies in how many peers they have, but the NATed client is never even able to make the announce to the network even though it gets block updates just fine. If that's the general state for NAT clients then that needs to be rethought. Else I'm leaning towards an OS X specific problem in .24 that might or might not be related to the weird disk writes.

I think it might be an OS specific issue. My Win7 client runs behind the firewall only ever has 8 connections but so far all my transactions, with or without fees have gotten their first confirmations in less than 1 hour.

[deepceleron]

Have you done any port-forwarding in the router, or do you have multiple IP addresses from your ISP? It is my understanding that if you port forward 8333 to one computer, you will completely kill bitcoin for other computers on your local network.

[defxor]

Have you done any port-forwarding in the router, or do you have multiple IP addresses from your ISP? It is my understanding that if you port forward 8333 to one computer, you will completely kill bitcoin for other computers on your local network.

Well, port 8333 is indeed mapped to the other client, but the NATed client that can't announce sends has 8 peers and receives blocks just fine. If the send code needs incoming ports (which I seriously doubt) then that's a huge bug.

[deepceleron]

You can read what Satoshi wrote about it: http://bitcointalk.org/?topic=54.0

[defxor]

You can read what Satoshi wrote about it: http://bitcointalk.org/?topic=54.0

Yeah there's no problem there.