cesmak
Legendary
 Offline
Activity: 1057
Merit: 1009
|
 |
July 08, 2015, 09:50:09 AM |
|
It also happens to some people, so I think there is a problem with te Blockchain. But I hope it'll be fixed ASAP Could both of these issues have something to do with the unusually large number of transactions per blocks in the last few days? https://blockchain.info/charts/n-transactions-per-blockOk a big jump in number of transactions, but, my transaction, now, is stuck with no confirmation by 18 hours, i think it's a huge ammount of time.... too much.... |
|
|
|
|
cesmak
Legendary
Offline
Activity: 1057
Merit: 1009
|
|
July 08, 2015, 10:21:14 AM |
|
It also happens to some people, so I think there is a problem with te Blockchain. But I hope it'll be fixed ASAP Could both of these issues have something to do with the unusually large number of transactions per blocks in the last few days? https://blockchain.info/charts/n-transactions-per-blockOk a big jump in number of transactions, but, my transaction, now, is stuck with no confirmation by 18 hours, i think it's a huge ammount of time.... too much.... Just found in the configuration of my wallet that it wasn't active the function to use "the reccomended ammount of fees" but the minimal ammount, so could be that the transaction is low on priority and need more time to be considered in the blockchain.... i will see what happens in the next hours.... Someone know if there is a timeout in the time a transaction is acquired or not ? And in the eventualy case of a timeout if it turn back to my wallet ? I know that bitcoin transaction are irreversible, but if the transaction will never be acquired by the blockchain what happens ? |
|
|
|
|
|
turvarya
|
|
July 08, 2015, 10:32:36 AM |
|
It also happens to some people, so I think there is a problem with te Blockchain. But I hope it'll be fixed ASAP Could both of these issues have something to do with the unusually large number of transactions per blocks in the last few days? https://blockchain.info/charts/n-transactions-per-blockOk a big jump in number of transactions, but, my transaction, now, is stuck with no confirmation by 18 hours, i think it's a huge ammount of time.... too much.... Just found in the configuration of my wallet that it wasn't active the function to use "the reccomended ammount of fees" but the minimal ammount, so could be that the transaction is low on priority and need more time to be considered in the blockchain.... i will see what happens in the next hours.... Someone know if there is a timeout in the time a transaction is acquired or not ? And in the eventualy case of a timeout if it turn back to my wallet ? I know that bitcoin transaction are irreversible, but if the transaction will never be acquired by the blockchain what happens ? Yes, the transaction gets deleted from the mempool after some time and therefore it "goes back to your wallet". But I am not sure, how much time it needs before a unconfirmed transaction gets deleted. |
|
|
|
|
RealBitcoin
|
|
July 08, 2015, 10:54:58 AM |
|
It also happens to some people, so I think there is a problem with te Blockchain. But I hope it'll be fixed ASAP Could both of these issues have something to do with the unusually large number of transactions per blocks in the last few days? https://blockchain.info/charts/n-transactions-per-blockOk a big jump in number of transactions, but, my transaction, now, is stuck with no confirmation by 18 hours, i think it's a huge ammount of time.... too much.... Just found in the configuration of my wallet that it wasn't active the function to use "the reccomended ammount of fees" but the minimal ammount, so could be that the transaction is low on priority and need more time to be considered in the blockchain.... i will see what happens in the next hours.... Someone know if there is a timeout in the time a transaction is acquired or not ? And in the eventualy case of a timeout if it turn back to my wallet ? I know that bitcoin transaction are irreversible, but if the transaction will never be acquired by the blockchain what happens ? Yes, the transaction gets deleted from the mempool after some time and therefore it "goes back to your wallet". But I am not sure, how much time it needs before a unconfirmed transaction gets deleted. 1 or worst case 2 days. So tell me is it safe to use blockchain.info at the moment? I am just wanting to send a transaction, so please tell me if it is safe |
|
|
|
|
Borisz
|
|
July 08, 2015, 11:09:16 AM |
|
It also happens to some people, so I think there is a problem with te Blockchain. But I hope it'll be fixed ASAP Could both of these issues have something to do with the unusually large number of transactions per blocks in the last few days? https://blockchain.info/charts/n-transactions-per-blockOk a big jump in number of transactions, but, my transaction, now, is stuck with no confirmation by 18 hours, i think it's a huge ammount of time.... too much.... The last time I purchased something a few months ago with BTC I did pay a tx fee, however it still took almost 24 hours for the transaction. It was only a few $ in total. |
|
|
|
|
cesmak
Legendary
Offline
Activity: 1057
Merit: 1009
|
|
July 08, 2015, 12:00:34 PM |
|
It also happens to some people, so I think there is a problem with te Blockchain. But I hope it'll be fixed ASAP Could both of these issues have something to do with the unusually large number of transactions per blocks in the last few days? https://blockchain.info/charts/n-transactions-per-blockOk a big jump in number of transactions, but, my transaction, now, is stuck with no confirmation by 18 hours, i think it's a huge ammount of time.... too much.... The last time I purchased something a few months ago with BTC I did pay a tx fee, however it still took almost 24 hours for the transaction. It was only a few $ in total. for me it's the first time a transaction, is in this situation i ever used bitcoin core, from the begin of my adventure in bitcoin, more than two years ago, always paid tx fees, and this is the first time i wait so much time. @realbitcoin (post above...) I can't help you because i had never used blockchain.info wallet service, so i don't know how is the situation for this service... the recomendation written here at the top of this thread is, to wait almost 30 cofirmation if you don't know what wallet orignates a transactions you will receive, for transaction you send, the problem ( to veify that your tx is ok) is to be done by the receiver of the transaction. I can't say any more... |
|
|
|
|
Amitabh S
Legendary
Offline
Activity: 1001
Merit: 1005
|
|
July 08, 2015, 12:26:47 PM |
|
This thread ("blockchain split") has nothing to do with tx confirmation delays. Why is everyone posting it here? There is another thread about tx delays. Use that.
|
|
|
|
cesmak
Legendary
Offline
Activity: 1057
Merit: 1009
|
|
July 08, 2015, 12:44:54 PM |
|
This thread ("blockchain split") has nothing to do with tx confirmation delays. Why is everyone posting it here? There is another thread about tx delays. Use that.
I started to post here for the tx realy asking if could be related to the fork happened in this days, sorry to perpetuate answering with others posts..... |
|
|
|
|
ZappaLlamaGamma
Newbie
Offline
Activity: 1
Merit: 0
|
|
July 08, 2015, 04:00:05 PM |
|
Being relatively new, but very technically proficient, I've learned all that I can. I was mining with AntPool since I bought my first miner, the U3. After knowing about the last fork from reading Digital Gold and knowing now about the three Chinese guys' pools, including the 80s group Wang Chung, I've since moved to a much more reputable pool. The Chinese business model of screw everyone else is not congruent with what Bitcoin is about. Sigh.
|
|
|
|
|
|
luthermarcus
|
|
July 08, 2015, 05:19:36 PM |
|
Being relatively new, but very technically proficient, I've learned all that I can. I was mining with AntPool since I bought my first miner, the U3. After knowing about the last fork from reading Digital Gold and knowing now about the three Chinese guys' pools, including the 80s group Wang Chung, I've since moved to a much more reputable pool. The Chinese business model of screw everyone else is not congruent with what Bitcoin is about. Sigh.
There should be more people like you antpool (Bitmain) screws it's customers over and has the worst customer service because it doesn't stand by it's word nor it's products 100%. They said they were going to help p2pool, set up a node and implement there miners to be more compatible but it was all hype to get the good graces of some buyers. |
Donate Bitcoin
1Mz7ZHxPhoH1ZK2yQvo62NdHvvsS2quhzc
Donate TRX
TB3WiLEj6iuSBU5tGUKyZkjB4vqrBDvoYM
|
|
|
|
luthermarcus
|
|
July 08, 2015, 05:23:34 PM |
|
This thread ("blockchain split") has nothing to do with tx confirmation delays. Why is everyone posting it here? There is another thread about tx delays. Use that.
You should explain why when you make a statement. Above guy means because the current delays are not due 100% to the fork there is a so called "stress test" which is happening which is slowing down transactions. |
Donate Bitcoin
1Mz7ZHxPhoH1ZK2yQvo62NdHvvsS2quhzc
Donate TRX
TB3WiLEj6iuSBU5tGUKyZkjB4vqrBDvoYM
|
|
|
Mikestang
Legendary
Offline
Activity: 1274
Merit: 1000
|
|
July 08, 2015, 06:10:45 PM |
|
This thread ("blockchain split") has nothing to do with tx confirmation delays. Why is everyone posting it here? There is another thread about tx delays. Use that.
You should explain why when you make a statement. Above guy means because the current delays are not due 100% to the fork there is a so called "stress test" which is happening which is slowing down transactions. None of the delays were due to the fork, people posting here about tx fees and delays are posting in the wrong place. Fork is done and over, don't know why this thread still persists. There have been forks in the past, there will be more in the future. Carry on. |
|
|
|
|
achow101
Staff
Legendary
Offline
Activity: 3570
Merit: 6927
Just writing some code
|
|
July 09, 2015, 12:50:18 AM |
|
This thread ("blockchain split") has nothing to do with tx confirmation delays. Why is everyone posting it here? There is another thread about tx delays. Use that.
You should explain why when you make a statement. Above guy means because the current delays are not due 100% to the fork there is a so called "stress test" which is happening which is slowing down transactions. None of the delays were due to the fork, people posting here about tx fees and delays are posting in the wrong place. Fork is done and over, don't know why this thread still persists. There have been forks in the past, there will be more in the future. Carry on. The fork is over, but the situation persists because miners have yet to update their software. There is still a small percentage of miners that could cause this type of fork to occur again. There was another fork late July 5th and there is still the possibility for another fork. I don't think the SPV Miners have confirmed whether they have patched their software to do full validation so the alert remains and the situation persists. The delays aren't due to the fork, but since they happened so close together, people are thinking they are the related, when they are actually not related at all. |
|
|
|
Cryddit
Legendary
Offline
Activity: 924
Merit: 1132
|
|
July 09, 2015, 01:09:04 AM |
|
I hesitate to bring this up because people are mistaken about how, but the forks do in fact contribute to delays.
When you've got 50% of the hashing power working on a bad fork, you've only got 50% of the hashing power working on a good fork. While this situation is in effect, you can only form about 50% of the "nominal" number of blocks in the good fork.
That leaves only room for 50% of the normal number of transactions and the remainder do in fact start to pile up when they come in faster than the reduced-capacity good block chain can handle.
|
|
|
|
|
achow101
Staff
Legendary
Offline
Activity: 3570
Merit: 6927
Just writing some code
|
|
July 09, 2015, 01:31:33 AM |
|
I hesitate to bring this up because people are mistaken about how, but the forks do in fact contribute to delays.
When you've got 50% of the hashing power working on a bad fork, you've only got 50% of the hashing power working on a good fork. While this situation is in effect, you can only form about 50% of the "nominal" number of blocks in the good fork.
That leaves only room for 50% of the normal number of transactions and the remainder do in fact start to pile up when they come in faster than the reduced-capacity good block chain can handle.
They do, but right now there is no active fork. There was also no active fork when the delays began, so the fork and the delays are unrelated. |
|
|
|
|
JorgeStolfi
|
|
July 09, 2015, 04:16:02 AM |
|
I don't think the SPV Miners have confirmed whether they have patched their software to do full validation so the alert remains and the situation persists.
I saw a quote by F2Pool - perhaps on this same thread - confirming that they will not do full validation of the parent before mining on top of it. They will however re-enable validation of the parent in parallel, if and when they receive the full block from the relay nodes. What the pools do (probably all of them, because they will be at a clear disadvantage if they didn't) is more radical than "SPV mining". They subscribe incognito as members of other open pools. When some other member of some other pool X mines a block B(N), it will usually tell all its members to start mining B(N+1) on top of B(N), even before sending B(N) out to the relay nodes. To do that, it has to send to all its members the header template of block B(N+1), that includes the hash of block B(N). The pool Y that is spying on X will then take that hash and start mining its own block B'(N+1) on top of B(N). This shortcut is usually quite safe, because pool X must validate the contents of block B(N), and cannot afford to send a false hash to its members, even though it knows that some of them must be spies for the competition. But this trick failed in the "fork of july" because pool X (BTCNuggets) was still running the v2 version of the software, so the block B(N) was invalid under v3 rules. The hash of B(N) was stolen from BTCNuggets by BTC-China, that was running v3 but did not realize that BTCNuggets was v2. Then F2Pool stole the hash of B(N) from BTC-China, and won the race to B(N+1); and the mistake continued for another 4 blocks more. A similar incident happened again on the 5th of July. The pools obviously will not give up on this shortcut, unless some way is found to make it unprofitable. Moreover, whenever pool Y starts mining on top of the stolen hash of a block B(N), it must start mining an empty block B(N+1). Pool Y cannot include any transaction from the queue in B(N+1), because it cannot check whether that transaction was already included in B(N), or tries to spend some UTXO that was spent by another transaction in B(N). Pool Y must wait until it gets the whole of B(N) from the relay nodes, before it can safely add more transactions to B(N+1). But often pool Y solves B(N+1) before that time. That may be the cause of the empty blocks that are often seen after a short interblock interval. |
Academic interest in bitcoin only. Not owner, not trader, very skeptical of its longterm success.
|
|
|
Cryddit
Legendary
Offline
Activity: 924
Merit: 1132
|
|
July 09, 2015, 05:50:30 AM |
|
The behavior of a normal client when confronted with an invalid block, is to ignore it. It will not relay that block.
Therefore, when BTCNuggets comes up with its version=2 block at a moment when the rest of the network is ready to reject version=2 blocks, the 'incognito' node that steals the hash by pretending to be a member of BTCNuggets will hear about it - but the block itself WON'T be relayed through the network to BTC-China, because other network nodes will notice it's invalid and drop it on the floor rather than relaying it.
So here's the situation. They want to check "in parallel when the block arrives" but the block won't arrive at all unless the same check, as performed by the relaying node, succeeded! Every second you don't get that block, it becomes more likely that the reason you haven't is because it's invalid.
So mining on a hash while waiting for a block is not a plan to maximize profits if it goes on for more than about ten seconds. If you haven't seen the block by about ten seconds after getting the hash, then it's most likely because that block was the Pravda, not the Truth. Nodes that would otherwise have relayed it to you (and everybody else) had a look at it and laughed at the funny joke instead of finding news worth passing along. And what that means is that if you treat the hash as True rather than Pravda, you're going to get taken in along with the other optimists who believed in it - and like them, you will believe you are wealthier than you'll actually be.
|
|
|
|
|
|
JorgeStolfi
|
|
July 09, 2015, 07:16:11 AM |
|
So here's the situation. They want to check "in parallel when the block arrives" but the block won't arrive at all unless the same check, as performed by the relaying node, succeeded! Every second you don't get that block, it becomes more likely that the reason you haven't is because it's invalid.
So mining on a hash while waiting for a block is not a plan to maximize profits if it goes on for more than about ten seconds. If you haven't seen the block by about ten seconds after getting the hash, then it's most likely because that block was the Pravda, not the Truth.
Makes sense, and hopefully the miners will improve their strategy as you suggest. Consider telling that to your favorite miner... However, until now that the chance of the parent block being invalid was very small, like 0.01% or less. That must be the reason why they did not bother to check the parent at all... Also, are you sure that the delay is only "seconds"? even when the nodes are struggling with 150'000 transactions in the queue, or 4 x the maximum transaction rate... |
Academic interest in bitcoin only. Not owner, not trader, very skeptical of its longterm success.
|
|
|
|
birr
|
|
July 09, 2015, 02:30:19 PM |
|
The current delay in the transactions is due to a spammer (attack) on the Bitcoin network, who sends peaks of 150 transactions per seconds on a network that can handle about 7 only.
One jerk can jam up Bitcoin for the entire world? |
|
|
|
|
lemipawa
Legendary
Offline
Activity: 1708
Merit: 1006
|
|
July 09, 2015, 02:39:06 PM |
|
The current delay in the transactions is due to a spammer (attack) on the Bitcoin network, who sends peaks of 150 transactions per seconds on a network that can handle about 7 only.
One jerk can jam up Bitcoin for the entire world? One jerk with a lot of Bitcoin nodes and a lot of money to burn. |
|
|
|
|
|
