Bitcoin Forum

Anyone from Antminer here? You guys are mining on the testnet. Very noble. Unfortunately most of the time you do not include any transactions. It takes forever for a transaction to get into a block because you guys are pushing the difficulty up by mining 1 tx blocks like crazy. Could you please stop all miners which do not include transactions?

Thanks for any feedback

Levin

To check on the latest blocks in the Testnet: https://test-insight.bitpay.com/blocks

Current situation:

http://s23.postimg.org/6m9rx7akb/Bildschirmfoto_vom_2015_06_03_12_29_29.png

4286 tx waiting in mempool, let's see if antminer includes some tx this time.. ;)

http://s4.postimg.org/m44dwfhbh/Screenshot_from_2015_06_03_14_54_09.png

source: https://chain.so/testnet/btc

That's rather strange!

It's probably just one machine if it's reporting 1Th on chain.so. I wish their pie chart and %'s were accurate..

I'm the guy flooding the mempool btw - I'm trying out NicholasDoriers experiment, on testnet. I had to shut it off since it's not filling up as quickly as I'd like. It was being made easier by AntMiner or whoever not filling blocks - I didn't think my laptop could keep it up.

Anyway, I guess if you posted this topic because you were waiting for a transaction to confirm, it's a sign of what'll happen when mainnets blocks are full.

Good. Continue. Start doing it on mainnet if possible. There should be some kind of fund. An address where people can send bitcoins to that will be used to spam the network. Make them all suffer.

To give a little context on why we are unhappy:

All API services for testnet are breaking because of this. Chain.com, Blockcypher, Block.io. Blocktrail seems to be the only one to be keeping up but they dont have a proper API to make curl calls. The APIs show the following errors:

• No notification on new transaction
• Incorrect balance (up to negative balances) for addresses
• Denial of tx broadcast because "referenced transaction not known"

These issues obviously come from the Bitcoind instances dropping transactions and the databases that the APIs are using miss entries. I would say an API should be better than this, but whatever.

This test is exactly what we needed. It shows how crucial a fast decision on the blocksize issue is.

Excellent. Yeah I've been watching the explorers intently. Anything from outright weirdness, to silly UI breaks like "we never wondered what our transaction table looked like with 0 tx's". It only matters when a block takes a while to actually load :)

I am going to switch this on again later. I also have a miner (not the one being used today though) so I can fund this very easily. I'll script something to do this more effectively and let you all know when it's going back on if you don't notice yourselves ;)

Can you share the script?

BTW: We talked to Antminer and they fixed their rogue pool so it now includes transactions.

For reference: https://bitcointalk.org/index.php?topic=1075590.20

Mycelium Wallet and Bitcoin Wallet (both Android) show issues with the Testnet. Bitcoin Wallet doesn't see new blocks / confirmations, Mycelium does not even send transactions to the network.

Testnet reorgs and most of those services not handling reorgs correctly.  Why would you assume otherwise?

Sorry, I did not want to blame bitcoind :)

Whatever. I think that this kind of issues need to be anticipated and the services should not be disturbed by them.

There's a known bug (https://bitcointalk.org/index.php?topic=789369.msg11436540#msg11436540) in eloipool(that antpool uses) which causes it to very often mine empty blocks. This could be related.

I'm afraid kano is continuing his usual campaign of FUD rather than being informative there.  Since generating and transmitting a new block template after a block takes some hundreds of milliseconds, Eloipool lowers the stale rate by a sizable fraction of a percent by issuing work for empty blocks until that's done. From time to time this will result in a random empty block, where otherwise there wouldn't have been a block at all. It's not a bug, and it doesn't fit the behaviour you're describing.

This Testnet is screwed  :o

Hi levino, I'm sorry to hear you've been having issues with our (BlockCypher's) services on testnet. gmaxwell's suspicion is correct, we have experienced uncharacteristically long branches (100's of blocks) on testnet due in part to massive block throughput changes and spikes, which we are not as good at handling as we'd like (yet). The transient nature of many testnet peers exacerbates this problem, causing poor relay and a higher chance of miners working on branches and not the main chain.

On the one hand, this is giving us a great test bed for our own code base, and as a result we're steadily improving our performance in these corner cases, but as you've noticed they make our services fall behind for periods of time. Testnet is a protocol test bed, after all, and that means that all of us service providers are in the same boat as everyone else in experiencing new, bizarre, and extreme cases. Testnet is good for exercising issues in a realistic environment; it is not great for providing reliable, high availability services.

For trying out our services, we also provide our own testnet, which adheres to most of Bitcoin's parameters but better reflects its stability.

Is this still a problem, if it is let me know (PM would be best) and I'll give them a poke. All the blocks coming in seem to be pretty small though.

Mike Hearn has convinced me in his last interview on Epicenter Bitcoin on removing the 750kB/1MB limit. 

Sending to myself seems to be optimized out of visibility in terms of balance and available coins, and I guess that is a good idea generally speaking.  What is the anticipated traffic for October of this year?

sdp