Pages:
Author

Topic: Blockchain split of 4 July 2015 - page 3. (Read 45630 times)

full member
Activity: 233
Merit: 100
July 09, 2015, 03:02: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.

If you just send transactions back and forth to yourself the only money that's burning is the tx fee, and that's minimal.
It can add up to quite a lot, and it isn't sustainable. Eventually the spammer will run out of money.
To be concrete - what is the fee of the spam transactions? If it would be 0.0001 BTC, that would cost in 1 hour with 150 transactions per second
3600 * 150 * 0.0001 = 54 BTC = 14400 USD at current USD rate
staff
Activity: 3458
Merit: 6793
Just writing some code
July 09, 2015, 02:17:42 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.

If you just send transactions back and forth to yourself the only money that's burning is the tx fee, and that's minimal.
It can add up to quite a lot, and it isn't sustainable. Eventually the spammer will run out of money.
legendary
Activity: 1274
Merit: 1000
July 09, 2015, 02:13:02 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.

If you just send transactions back and forth to yourself the only money that's burning is the tx fee, and that's minimal.
jr. member
Activity: 65
Merit: 1
July 09, 2015, 12:34:23 PM
yes very strange , 59 confirmations but transaction not confirmed yet, never see that.

Confirmations are "confirmed". What do you mean? As long as one confirmation is there then the transaction is confirmed.


Sorry I mean "seen by 59 peers", not confirmed

edit : seen by 91 peers now, not confirmed
legendary
Activity: 2674
Merit: 1083
Legendary Escrow Service - Tip Jar in Profile
July 09, 2015, 11:58:44 AM
yes very strange , 59 confirmations but transaction not confirmed yet, never see that.

Confirmations are "confirmed". What do you mean? As long as one confirmation is there then the transaction is confirmed.
jr. member
Activity: 65
Merit: 1
July 09, 2015, 11:24:00 AM
yes very strange , 59 confirmations but transaction not confirmed yet, never see that.
hero member
Activity: 714
Merit: 500
July 09, 2015, 09:42:24 AM

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?
it's not like it is easy to execute.
There was someone(it is not know, if it was the same person) trying that some weeks ago and he failed pretty hard. Then he tried it again and failed again and now we have this from maybe the same person or a copycat.
So, there is a lot of preparation to that and you need some servers. The whole thing is also not cheap, when it comes to transaction fees.
Also keep in mind, that some people are already working on counter-measures.
legendary
Activity: 1204
Merit: 1028
July 09, 2015, 09:39:56 AM

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?

What did you expect? and why do you think the blocksize debate is a huge one?
We need to do something about it, 7 tx per second has been a tiny amount for a while. This was meant to happen sooner or later. Better now than later on when more people would be on board. Hopefully this makes people realize we need changes asap.
legendary
Activity: 1708
Merit: 1006
July 09, 2015, 09:39:06 AM

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.
hero member
Activity: 870
Merit: 585
July 09, 2015, 09:30:19 AM

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?
hero member
Activity: 910
Merit: 1003
July 09, 2015, 02: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...
legendary
Activity: 924
Merit: 1132
July 09, 2015, 12: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.

hero member
Activity: 910
Merit: 1003
July 08, 2015, 11:16:02 PM
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.



staff
Activity: 3458
Merit: 6793
Just writing some code
July 08, 2015, 08:31:33 PM
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.
legendary
Activity: 924
Merit: 1132
July 08, 2015, 08:09:04 PM
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. 

staff
Activity: 3458
Merit: 6793
Just writing some code
July 08, 2015, 07:50:18 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.
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.
legendary
Activity: 1274
Merit: 1000
July 08, 2015, 01: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.
full member
Activity: 213
Merit: 100
July 08, 2015, 12: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.
full member
Activity: 213
Merit: 100
July 08, 2015, 12: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.
newbie
Activity: 1
Merit: 0
July 08, 2015, 11:00:05 AM
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.
Pages:
Jump to: