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

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

It can add up to quite a lot, and it isn't sustainable. Eventually the spammer will run out of money.

If you just send transactions back and forth to yourself the only money that's burning is the tx fee, and that's minimal.

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

edit : seen by 91 peers now, not confirmed

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

yes very strange , 59 confirmations but transaction not confirmed yet, never see that.

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.

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.

One jerk with a lot of Bitcoin nodes and a lot of money to burn.

One jerk can jam up Bitcoin for the entire world?

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...

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.

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.

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.

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. 

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.

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.

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.

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.

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.