Pages:
Author

Topic: Miners that refuse to include transactions are becoming a problem - page 12. (Read 16972 times)

donator
Activity: 1218
Merit: 1079
Gerald Davis
A rebutal on "botnets"
1) We don't know it IS a botnet.
2) If it is there is absolutely nothing you can do to prevent them.  If botnets could be stopped they would.
3) If this is a botnet and they included tx you wouldn't even know.  The entire rationale can be boiled down to lots of hashpower with no txs = botnet which is dubious at best.
4) There is no need to "rationalize" anything.  Botnets exist and they will be attracted to potential profit.  Mining is profitable and thus botnets will participate. 

Some of us just don't feel like joining in the gnashing of teeth and assorted other nonsense.

Lets say you have 100% support of the Bitcoin community.  All miners, all pools, all users.  How do you stop botnets?
If you can't then I think you can see your entire post was pointless.
sr. member
Activity: 252
Merit: 250
Inactive


I'm quite surprised that all invested, relatively honest miners are not taking issue with botnets.  I've read a number of miner's opinions and many seem to be dangerously cavalier on the subject of botnet participation in Bitcoin's core infrastructure.

IMO.  A few bullets to address some posted opinions.

- "Cheap" botnet operators do not equate to legitimate participants in a free market. 
- Free loading botnets do not equal "Cheap," business operators.
- A botnet is not a business doing "good business."
- An absense of botnets does not equate to block chain insecurity.

Botnets are an unhealthy rationalization of Bitcoin security.  IMO, the discussion on the matter of botnets should not be limited to technical impact on Bitcoin.  Trading for security of one aspect (IMO, an unnecessary contribution to security) while trading away reputation of Bitcoin's core infrastructure as substantially supported by criminal entities.  Consumers, by and large, are particularly sensitive to the perceived honesty of an organization they do business with.  For the fledgling Bitcoin botnets are not something we want newcomers to worry about.  Whether or not the consumer's/user's perception of botnet risk is accurate, they will judge Bitcoin based on the knowledge that Bitcoin's existence partially relies on criminal activities.
Do you think the average consumer, let alone the coffee house, will like using Bitcoin to pay for a latte if they are aware of the above?

Botnets do not equate to business conducting good business as some have mentioned. 
Profit being the single interest of business necessitates law and regulation.  The no TX botnet is a prime example of a business where it's only consideration is profit that, currently, is not required to operate as a legitimate business thus giving advantage above all other parties who have decided to operate within legitimate parameters.  At worst botnet inclusion could recruit further exploitation.
On the flip side if botnets are not considered a threat in any respect, e.g. total network hashing, reputation, and instead are considered a positive contribution to block chain security they are indeed an insult to those who support Bitcoin through legitimate means, have expenses and follow the Bitcoin protocol in an honest manner.

Any entity that profits with all expenses being externalized, i.e. not obligated to pay for expenses, while typically great for the business is systemically unhealthy to the populous and the economy.  This is well understood economic principle.  A monopoly of a market in specific terms of having almost all expenses externalized is not a good example of a good free market.

Botnets, as the 15% total hashrate no TX botnet, is an exploitation of the temporary hashing subsidies of Bitcoin.  It's the truth even though there are multiple ways to rationalize botnet participation in Bitcoin.
hero member
Activity: 728
Merit: 500
165YUuQUWhBz3d27iXKxRiazQnjEtJNG9g
The only hurtful thing that empty blocks do, is increasing the difficulty by their hashrate used.

It increases the time-to-first-confirm - if the "null blocks" rate grows to 90%, the average time to first confirmation will be nearly two hours!

It may also make double spends easier.
legendary
Activity: 2618
Merit: 1007
I don't really see the problem - as mining is planned to be a free market, it took actually longer than I expected until someone found out that the added complexity and electricity used pool-server wise with getworks and whatnot is probably not even matched by the income from these laughable transaction fees.

If you want to battle this, set the default transaction fee to 1 BTC for example - then it would be VERY worthwile to include transactions as well to collect the fees, even for Botnets and not including transactions would hurt a lot.

The only hurtful thing that empty blocks do, is increasing the difficulty by their hashrate used. On the other hand probably one day these coins will be spent and given back to the network - especially the "proof of stake" fans should be happy about someone getting 15% of all new coins.

tl,dr: higher transaction fees = more incentive to include transactions in blocks, as always.
legendary
Activity: 1526
Merit: 1134
It might be worth somebody contacting the ISP providing bandwidth to the errant node and asking them to investigate.
legendary
Activity: 2058
Merit: 1452
As I understand it (and I probably understand poorly), the miners redo the transaction calculations only every few minutes. So, even if a miner is good intentioned and creating blocks with valid transactions, a transaction in the last part of the 10 minutes might be missed and will have to wait untill the next block. Assuming I have all that correct, could we not have a validation system where the node keeps track of the transactions and if a block is announced by a different node, it would check to see if transactions of a certain age are present and if not, reject the block? For instance, time 0 is solve time of last block and time 10 is solve time for current block. I keep track of transactions and if I see a new block at time 10 that doesn't include a transaction from time 5 (or before), I reject it. Is that doable or would we get into timestamp issues with not everybody agreeing on the time?
discussed a short while ago, i think it was shot down because it can easily cause forks.
Nim
member
Activity: 67
Merit: 10
As I understand it (and I probably understand poorly), the miners redo the transaction calculations only every few minutes. So, even if a miner is good intentioned and creating blocks with valid transactions, a transaction in the last part of the 10 minutes might be missed and will have to wait untill the next block. Assuming I have all that correct, could we not have a validation system where the node keeps track of the transactions and if a block is announced by a different node, it would check to see if transactions of a certain age are present and if not, reject the block? For instance, time 0 is solve time of last block and time 10 is solve time for current block. I keep track of transactions and if I see a new block at time 10 that doesn't include a transaction from time 5 (or before), I reject it. Is that doable or would we get into timestamp issues with not everybody agreeing on the time?
legendary
Activity: 1330
Merit: 1000
I bet this company here is testing one of their fpga/asic products: http://www.sevensols.com/

It's located in Granada, Spain. That's where the ip is from.

This could explain why transactions are not included.  If this is a manufacturer doing a burn-in on an fpga cluster, omitting transactions would be a good way to avoid being accused of terrorism or whatever.

Then again the possibility of one manufacturer (and likely gov't contractor) having 15% of the hashing power is not good to think about.
legendary
Activity: 2184
Merit: 1056
Affordable Physical Bitcoins - Denarium.com
Good points by both DeathAndTaxes and Kluge. I agree but still not happy about it. Perhaps the hash power of these no-tx botnets need to become a bit larger for people to really notice this issue. It could be that it doesn't even happen and we're left with this small issue that actually goes away eventually just as Syke said. But the thing is we don't really know.
donator
Activity: 1218
Merit: 1015
I simply find it unacceptable that my transactions and everyone elses transactions with Bitcoin can become slower thanks to a leeching botnet that simply profits from the blocks but doesn't do the one thing mining is actually useful for which is adding transactions to the blockchain.

Do we really want to let this leeching continue without doing anything about it? This is not just about inconvenience, if there is a solution we should put a stop to this. I'm quite confident that I'm not the only one who doesn't like this.

Maybe it isn't such a big threat but it does bother me a lot for many reasons.
If it becomes a big enough hassle, people will stop waiting for confirmations. Once that convenience problem turns into a security problem, the devs will probably start thinking hard about fixes.
donator
Activity: 1218
Merit: 1079
Gerald Davis
Mining isn't just about adding tx to the block chain.  The hashing power still adds to the network security.  The economic value from that hashing power provides the incentive to not be disruptive.  There is no economic incentive to including txs.  People being cheap isn't a flaw.
legendary
Activity: 2184
Merit: 1056
Affordable Physical Bitcoins - Denarium.com
I simply find it unacceptable that my transactions and everyone elses transactions with Bitcoin can become slower thanks to a leeching botnet that simply profits from the blocks but doesn't do the one thing mining is actually useful for which is adding transactions to the blockchain.

Do we really want to let this leeching continue without doing anything about it? This is not just about inconvenience, if there is a solution we should put a stop to this. I'm quite confident that I'm not the only one who doesn't like this.

Maybe it isn't such a big threat but it does bother me a lot for many reasons. It's the kind of thing that would make Bitcoin users leave Bitcoin and start using a competing cryptocurrency. Of course there are no real cryptocurrency competitors yet but in 5 years Bitcoin might not have this luxury. Issues like this do matter.
donator
Activity: 1218
Merit: 1079
Gerald Davis
Design =/= implemented code.
full member
Activity: 196
Merit: 100
I hadn't realized this problem had gotten so bad so quickly.  Clearly including transactions for fees isn't a great enough incentive.  I agree it should be addressed.

It was addressed in the original Bitcoin design. Over time, the block reward will drop to zero, and transaction fees will make up the majority of the value of mining blocks. Nothing more needs to be done.

If it was perfection from the start then why do we need developers at all now?
legendary
Activity: 3878
Merit: 1193
I hadn't realized this problem had gotten so bad so quickly.  Clearly including transactions for fees isn't a great enough incentive.  I agree it should be addressed.

It was addressed in the original Bitcoin design. Over time, the block reward will drop to zero, and transaction fees will make up the majority of the value of mining blocks. Nothing more needs to be done.
administrator
Activity: 5222
Merit: 13032
So how does that work then? If they let an invalid transaction into the block then that block will be rejected by the network and they have wasted their hashing effort.

If these miners are building off of the longest chain without looking at any of the transactions (which may not be the case), then any attacker capable of getting a few blocks in a row can get these dumb miners to work for him. Full clients will reject these invalid chains, of course, but lightweight clients won't.

Now that I think about it more, it's probably more likely that the miners are getting the latest hash from Bitcoin nodes or websites, which might not be quite as bad as using the longest chain. Still weakens the network a lot, though.
sr. member
Activity: 416
Merit: 277
I am a little concerned that they're not actually verifying transactions like they should be. This reduces the percentage of network power that an attacker needs in order to execute a "50%" attack.
So how does that work then? If they let an invalid transaction into the block then that block will be rejected by the network and they have wasted their hashing effort.

ByteCoin
administrator
Activity: 5222
Merit: 13032
I wouldn't consider it a problem for even 75% of miners to exclude all transactions. This would only slow transactions down by 10-20 minutes, and eventually the fee mechanism would sort it out.

I am a little concerned that they're not actually verifying transactions like they should be. This reduces the percentage of network power that an attacker needs in order to execute a "50%" attack. Applying gmaxwell's proposal might be worthwhile.
donator
Activity: 1218
Merit: 1079
Gerald Davis
People will lose confidence if the avg 1-confirmation time is 13 minutes instead of 10?  Really?  Especially given the 90% confidence interval is 3 to 31 minutes anyways.
legendary
Activity: 2184
Merit: 1056
Affordable Physical Bitcoins - Denarium.com
What are the side effects of 15% of "extra" empty blocks?

1)  The difficulty increases.  This is good for the network, but bad for miners
2)  It takes longer for transactions to make it into blocks.

Am I missing something?  Neither one seems like THAT big of a deal.
You are missing something. The problem is that 15% is now, it's not necessarily that low forever. To me it seems like not adding any transactions is advantageous to a botnet miner for some reason (which is unknown) and this needs to be countered. Imagine if in a couple of months this percentage is 30, then our network is basically one third slower than it should be. It's a big deal that will make people lose confidence in Bitcoin's reliability.

We need to find a way to either give those who add transactions more carrot for doing that or give those that don't do that more stick. Whatever the solution is, we definitely need one.
Pages:
Jump to: