Bitcoin Forum
December 08, 2016, 04:25:52 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 [3]  All
  Print  
Author Topic: 0 confirmations after over a month, WTF?  (Read 2938 times)
hugolp
Hero Member
*****
Offline Offline

Activity: 742



View Profile
August 06, 2011, 03:53:14 AM
 #41

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.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481171152
Hero Member
*
Offline Offline

Posts: 1481171152

View Profile Personal Message (Offline)

Ignore
1481171152
Reply with quote  #2

1481171152
Report to moderator
1481171152
Hero Member
*
Offline Offline

Posts: 1481171152

View Profile Personal Message (Offline)

Ignore
1481171152
Reply with quote  #2

1481171152
Report to moderator
Remember remember the 5th of November
Legendary
*
Offline Offline

Activity: 1526

Reverse engineer from time to time


View Profile
August 06, 2011, 08:43:28 AM
 #42

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

BTC:1AiCRMxgf1ptVQwx6hDuKMu4f7F27QmJC2
deepceleron
Legendary
*
Offline Offline

Activity: 1470



View Profile WWW
August 06, 2011, 09:35:03 AM
 #43

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
Hero Member
*****
Offline Offline

Activity: 530


View Profile
August 06, 2011, 09:51:06 AM
 #44

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
Legendary
*
Offline Offline

Activity: 1470



View Profile WWW
August 06, 2011, 10:58:32 AM
 #45

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
Hero Member
*****
Offline Offline

Activity: 530


View Profile
August 06, 2011, 02:43:48 PM
 #46

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
Hero Member
*****
Offline Offline

Activity: 530


View Profile
August 06, 2011, 04:04:03 PM
 #47

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
Jr. Member
*
Offline Offline

Activity: 42


View Profile
August 06, 2011, 04:24:51 PM
 #48

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.


186q9YUW3x8TVHC5aYBEqgZZYMxft8Cw9f
deepceleron
Legendary
*
Offline Offline

Activity: 1470



View Profile WWW
August 06, 2011, 05:52:57 PM
 #49

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
Hero Member
*****
Offline Offline

Activity: 530


View Profile
August 06, 2011, 07:31:20 PM
 #50

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
Legendary
*
Offline Offline

Activity: 1470



View Profile WWW
August 07, 2011, 04:20:38 AM
 #51

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

defxor
Hero Member
*****
Offline Offline

Activity: 530


View Profile
August 07, 2011, 09:16:32 AM
 #52

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

Yeah there's no problem there.
Pages: « 1 2 [3]  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!