Pages:
Author

Topic: Are we stress testing again? - page 22. (Read 33163 times)

legendary
Activity: 883
Merit: 1005
July 08, 2015, 08:53:51 PM
We need to Ddos the mining pools that are mining empty blocks. Even if they are not behind this attack they are contributing to it.

legendary
Activity: 1988
Merit: 1012
Beyond Imagination
July 08, 2015, 08:53:28 PM
Even the attack have some political implication, I don't think it will convince anybody to fork

Probably not. Bitcoiners are extremely resilient, they don't change their opinions just because of mere facts.  Grin

Fact does not help to make decision, because there are many facts regarding raising the block size and each of them have two sides: transaction capacity, network bandwidth requirement, block orphan rate, mempool size ... their importance are not the same because some of them would cause a fundamental change in the network's property, and each person have different opinion over the potential impact of the same fact

Many banks are still using their hardware/software developed during 90s, financial IT prefer no change over change, any kind of change can cause unpredictable risk. If there is any change, it should be as small as possible, and a very long period of follow up is a must. In this case, raise the block size to 2MB and observe it for at least 6 months is the typical approach in bank's IT strategy department

Quote
More transactions make the attack more expensive.  The average transaction fee now is ~0.01 USD/tx, it seems.  Assuming an attack with twice the traffic numbers above,  the cost would be ~80 USD/h with 1 MB blocks,  ~850 USD/h with 8 MB blocks, and ~2100 USD/h with 20 MB blocks.

Currently spam transactions are those paying no fee and sending 1000 satoshi, at an extreme they could send 1 satoshi without fee, similar to satoshidice did in 2012, the amount of money required is neglictable. If you don't make a spam filter, even if you have 100MB block size, the spam will fill it in no time. But if you have an effective spam filter, you don't need to raise the block size yet

When banks are closed during weekend, no one panic. Similarly, when bitcoin network are being attacked by spammers, bitcoiners won't panic either. They will just wait until a new spam filter is published and apply it

The current problem is on the mempool, if the spam continues to build up, sooner or later all the memory on the nodes will be consumed, so a spam filter update is needed, it should be applied to majority of nodes to make the network resilient
hero member
Activity: 700
Merit: 501
https://bitcointalk.org/index.php?topic=905210.msg
July 08, 2015, 07:56:48 PM
People should stop mining at pools who contribute to issues with the network.
The size will be increased, but I do not think it will impact the amount of spam in any way.

Once miners realize we need to vote with our money many will realize they can make things happen. It is our responsibility to do so.

I say we and our like I have a Peta mine. I have my small little home farm. I live bitcoin though and think it is everything Andreas A. says it is and more. It must mature, and these so called attacks are good for the network. It will cause a reaction. Changes will be made and if other networks are smart they are paying attention to learn without having to go through the same.

I am not a programmer / coder either, but I work with a few everyday. Talk about your block size arguments. We all argue about everything. We also call each other weird names and give each other hell. I've worked with some of these guys 15 yrs +. Programmers and engineer mindsets in general will argue about something for over a year. The product is never finished as an engineer or programmer. With many people I know a product would never be completely ready to sell. If things were allowed to work that way.

They won't be in the case of the spam 'attack'. Consider it a mildly annoying lesson and pay a little higher fee for a while. No one is going to maintain this level, but guess what? Even of they did, we pay 5x more per transaction for 20 years. I'd pay it without blinking an eye...

...and it wont keep the unbanked out of bitcoin. You know what keeps the unbanked out of bitcoin? They do not have money now.
If they had money and didn't live paycheck to paycheck if they are lucky, many / or maybe most in certain states or areas of other countries live on that government check being deposited. They cant buy bitcoin with it, they have to eat and feed kids.
I am with the remittance crowd though. There is a perfect use. If they can afford to send it home, they can do it with bitcoin. Once their local grocery store to where they are sending the money accepts it.

The block size will be increased and there will not be sidechains in the way we have been told about them so far. They cannot take from the main chain, but they can ride it. If it becomes more profitable to mine another coin for a long period of time of course miners would switch (if they can). Check out the hash rental places when a popular pump n dump alt is launched. I do not see a 'sidechain' happening. I think it will all happen off-chain. More like a 7-11 model.

There goes my two spam attacks for the day and btw, I did a couple of transactions between exchanges and they went right through as high priority.  

member
Activity: 97
Merit: 10
July 08, 2015, 07:53:06 PM
With an increase in blocksize and fees decreasing as a result, spam attacks will only get bigger not smaller.
Agreed. In many ways, larger blocksizes increase the damage that can be done to nodes supporting the network. Maybe making blocks 20x larger would deter an attacker, but what if it doesn't? That's 20x more bandwidth and storage space consumed to begin with, plus the extra computational overhead for dealing with the larger blocks. While it might cost the attacker a lot more to perform, it would also cost the network a lot more to handle.

Mitigating the effects of spam needs a more elegant solution than simply increasing blocksize. Larger blocksizes simply enable more transactions; this might be useful for allowing more useful transactions, but is counter-productive to limiting spam, as it simply allows more of anything, spam included, and bills nodes and miners with the associated expenses.
legendary
Activity: 2044
Merit: 1005
July 08, 2015, 07:34:15 PM
With an increase in blocksize and fees decreasing as a result, spam attacks will only get bigger not smaller.

action will be taken sooner rather than later with the limit being increased im disappointed by how many people have tried to spam it though

First need to solve the spam attack then increase size.
newbie
Activity: 1
Merit: 0
July 08, 2015, 07:32:02 PM
With an increase in blocksize and fees decreasing as a result, spam attacks will only get bigger not smaller.

action will be taken sooner rather than later with the limit being increased im disappointed by how many people have tried to spam it though
legendary
Activity: 2044
Merit: 1005
July 08, 2015, 07:30:31 PM
With an increase in blocksize and fees decreasing as a result, spam attacks will only get bigger not smaller.
legendary
Activity: 3724
Merit: 3063
Leave no FUD unchallenged
July 08, 2015, 07:25:25 PM

JorgeStolfi addressed this few a few posts prior.  It's quite an eloquent explanation and I can't fault his reasoning.  See below:


It is what any plumber would try to do when he notices that a rain or sewer pipe is about to become insufficient for the flow it is supposed to carry.

I agree, a very eloquent explanation, however, I can find fault with the above statement.  I know it's an analogy, not a literal comparison, but I am a civil engineer and I deal with pipe capacity all day long.  When we have a pipe that is handling/going to handle more flow than its capacity making the pipe bigger is NOT always the first thing we do, but it is the obvious thing to do.  I'm sure the same thing is going on here, but since I don't understand programming I'm not involved with those technical discussions.  Making the blocks bigger seems like the obvious thing to do, but I'm sure there are other elements to this solution that need to be considered.

What about massive "spam attacks" of no-tx-fee transactions, is that possible?  That wouldn't cost anyone anything.

The post you quoted also makes the assumption that all miners are producing full blocks when that is not the case.  Many miners produce less-than-full blocks, even empty blocks, and so I'm sure that just compounds the issue even further.

I am of the opinion that the answer to the block size debate is not 1 or 8 or 20 or variable, the ultimate solution will be one that address the issue of block size in a manner that hasn't been conceived yet.

I'm inclined to agree that if there is another solution, it's likely to be one that isn't doing the rounds yet.  Or perhaps even a combination of all the existing ideas.

I'm still not overly sold on sidechains despite sounding great in theory.  The fact that they're still a theory is a significant part of the concern because, whatever the solution is, it needs to be implemented before any large surge in adoption.  The other concern is simply how they're implemented and the repercussions of getting that wrong.  For example, if they are implemented, it's of paramount importance that all the chains are merge-mined.  Because if not, then it's only taking fees that could go to incentivising miners on the "main" chain and giving them to miners securing a different chain.  If a significant number of people end up transacting on a subchain and that chain generates more in fees than the one that's supposedly going to be more secure (for larger transactions that need higher security), we could see the bizarre situation where more hash power is securing the smaller but more frequent transactions because it pays better for miners.  Getting the slightest thing like that wrong could end up with very odd and unforeseen consequences.

Lightning Network proposals still appear to be in their infancy as well, so again, would they be ready in time to cope with a larger userbase?  And what, if any, downsides do we have to anticipate before they occur with that setup?  If I'm honest, I still need to read it a few more times to let it sink in and be fully clear on what they're proposing, but I still don't feel as optimistic about it as others clearly do.  Then there's other suggestions like pruning as well.  I'm sure as a community, we could quite literally spend the next decade thrashing out all the options and the pros and cons of each, but I honestly doubt we have that long before the current limitations become an issue.
legendary
Activity: 1274
Merit: 1000
July 08, 2015, 06:34:33 PM

JorgeStolfi addressed this few a few posts prior.  It's quite an eloquent explanation and I can't fault his reasoning.  See below:


It is what any plumber would try to do when he notices that a rain or sewer pipe is about to become insufficient for the flow it is supposed to carry.

I agree, a very eloquent explanation, however, I can find fault with the above statement.  I know it's an analogy, not a literal comparison, but I am a civil engineer and I deal with pipe capacity all day long.  When we have a pipe that is handling/going to handle more flow than its capacity making the pipe bigger is NOT always the first thing we do, but it is the obvious thing to do.  I'm sure the same thing is going on here, but since I don't understand programming I'm not involved with those technical discussions.  Making the blocks bigger seems like the obvious thing to do, but I'm sure there are other elements to this solution that need to be considered.

What about massive "spam attacks" of no-tx-fee transactions, is that possible?  That wouldn't cost anyone anything.

The post you quoted also makes the assumption that all miners are producing full blocks when that is not the case.  Many miners produce less-than-full blocks, even empty blocks, and so I'm sure that just compounds the issue even further.

I am of the opinion that the answer to the block size debate is not 1 or 8 or 20 or variable, the ultimate solution will be one that address the issue of block size in a manner that hasn't been conceived yet.
legendary
Activity: 3724
Merit: 3063
Leave no FUD unchallenged
July 08, 2015, 06:13:09 PM
legendary
Activity: 2296
Merit: 1335
Don't let others control your BTC -> self custody
July 08, 2015, 05:56:36 PM
I am getting tired of waiting for mining income. Enough is really enough.

I'm amazed you made it this far. Home mining stopped being profitable last year.
legendary
Activity: 1274
Merit: 1000
July 08, 2015, 05:43:07 PM
we are at 21000 unconfirmed transactions currently and its getting ridiculous. how much longer do we have to deal with this? i personally cannot withdraw my funds from 1 of the online casinos due to the deposit not confirming. i also have been waiting 18+ hours on other transactions to exchanges. https://blockchain.info/tx/6851c6d83e87c1189b1311aed1f912dab542487888e2d9c1513595c35a601cef

i dont know about the rest of you but enough is enough

Right! Enough is enough! Let's raise the blocksize.

Why, what would that fix?

This is a much bigger issue, this is a fatal flaw with the network itself.  You could have a 20 gigabyte block size and someone could still overflow it with simple, cheap transactions.

What if the "spam" never stops?  How does the network protect itself from this?  Imagine if the spam were being sent at a rate 10x what it is today, 100x, 1000x!  Easily achieveable on a modest budget.  I don't know enough about the inner workings of bitcoin, but to me this "test" is a clear example of one way you can defeat bitcoin.
legendary
Activity: 1386
Merit: 1009
July 08, 2015, 05:39:58 PM
satoshi predicted that mining would become centralized over time. As pools start to gain large percentages of the network hash rate, miners will move their hardware to other pools with lower percentages of the network, even if that means a lower expected yield from their hardware over the short term.

The reason for this is because if one entity controls too much of the network then its value may decline when it is seen to vulnerable to 51% attacks (and similar) which would decrease the long term yield of their miners.
Satoshi is long gone. Even if he predicted that, it doesn't mean we shouldn't try to avoid it.
sr. member
Activity: 244
Merit: 250
July 08, 2015, 05:36:48 PM
I am getting tired of waiting for mining income. Enough is really enough.
member
Activity: 76
Merit: 10
July 08, 2015, 05:16:52 PM
we are at 21000 unconfirmed transactions currently and its getting ridiculous. how much longer do we have to deal with this? i personally cannot withdraw my funds from 1 of the online casinos due to the deposit not confirming. i also have been waiting 18+ hours on other transactions to exchanges. https://blockchain.info/tx/6851c6d83e87c1189b1311aed1f912dab542487888e2d9c1513595c35a601cef

i dont know about the rest of you but enough is enough

Right! Enough is enough! Let's raise the blocksize.
copper member
Activity: 2870
Merit: 2298
July 08, 2015, 05:01:11 PM
Quote
Increasing the block size limit to 8 MB or even 20 MB will not make the risk of a spam attack become negligible, because a determined attacker with deep pockets can afford much more than 2100 USD/hour.  But it would make the attack 10 times more expensive, and clear any backlog almost 10 times faster.
Yes. And it will also increase the load on nodes by the same factor. Even to the point where only powerful dc-hosted nodes would struggle to verify blocks in a meaningful amount of time.

It's not that I oppose increasing the block size - quite the contrary. I just think we should think thrice before we do it.
The nodes are verifying the transactions being relayed at sometimes a rate of 150 tps. If they can verify transactions at that rate without major issue then they should be able to handle a max block size that would accommodate 75 tps.

It should also be noted that hardware has been leased/purchased with the fact in mind that blocks would be no more then 1 MB in size and over time more powerful hardware would be employed for nodes as the block size increases.
That may be true, I didn't do any calculations, but regardless of that, there are fundamental issues with larger blocks, e.g. higher orphan rates, which create financial incentives for further mining centralization. These should be taken into account, that's my point.
satoshi predicted that mining would become centralized over time. As pools start to gain large percentages of the network hash rate, miners will move their hardware to other pools with lower percentages of the network, even if that means a lower expected yield from their hardware over the short term.

The reason for this is because if one entity controls too much of the network then its value may decline when it is seen to vulnerable to 51% attacks (and similar) which would decrease the long term yield of their miners.
legendary
Activity: 3626
Merit: 4440
July 08, 2015, 04:38:56 PM
we are at 21000 unconfirmed transactions currently and its getting ridiculous. how much longer do we have to deal with this? i personally cannot withdraw my funds from 1 of the online casinos due to the deposit not confirming. i also have been waiting 18+ hours on other transactions to exchanges. https://blockchain.info/tx/6851c6d83e87c1189b1311aed1f912dab542487888e2d9c1513595c35a601cef

i dont know about the rest of you but enough is enough
legendary
Activity: 1386
Merit: 1009
July 08, 2015, 04:33:43 PM
Quote
Increasing the block size limit to 8 MB or even 20 MB will not make the risk of a spam attack become negligible, because a determined attacker with deep pockets can afford much more than 2100 USD/hour.  But it would make the attack 10 times more expensive, and clear any backlog almost 10 times faster.
Yes. And it will also increase the load on nodes by the same factor. Even to the point where only powerful dc-hosted nodes would struggle to verify blocks in a meaningful amount of time.

It's not that I oppose increasing the block size - quite the contrary. I just think we should think thrice before we do it.
The nodes are verifying the transactions being relayed at sometimes a rate of 150 tps. If they can verify transactions at that rate without major issue then they should be able to handle a max block size that would accommodate 75 tps.

It should also be noted that hardware has been leased/purchased with the fact in mind that blocks would be no more then 1 MB in size and over time more powerful hardware would be employed for nodes as the block size increases.
That may be true, I didn't do any calculations, but regardless of that, there are fundamental issues with larger blocks, e.g. higher orphan rates, which create financial incentives for further mining centralization. These should be taken into account, that's my point.
copper member
Activity: 2870
Merit: 2298
July 08, 2015, 04:20:09 PM
Quote
Increasing the block size limit to 8 MB or even 20 MB will not make the risk of a spam attack become negligible, because a determined attacker with deep pockets can afford much more than 2100 USD/hour.  But it would make the attack 10 times more expensive, and clear any backlog almost 10 times faster.
Yes. And it will also increase the load on nodes by the same factor. Even to the point where only powerful dc-hosted nodes would struggle to verify blocks in a meaningful amount of time.

It's not that I oppose increasing the block size - quite the contrary. I just think we should think thrice before we do it.
The nodes are verifying the transactions being relayed at sometimes a rate of 150 tps. If they can verify transactions at that rate without major issue then they should be able to handle a max block size that would accommodate 75 tps.

It should also be noted that hardware has been leased/purchased with the fact in mind that blocks would be no more then 1 MB in size and over time more powerful hardware would be employed for nodes as the block size increases.
legendary
Activity: 1386
Merit: 1009
July 08, 2015, 04:15:11 PM
Quote
Increasing the block size limit to 8 MB or even 20 MB will not make the risk of a spam attack become negligible, because a determined attacker with deep pockets can afford much more than 2100 USD/hour.  But it would make the attack 10 times more expensive, and clear any backlog almost 10 times faster.
Yes. And it will also increase the load on nodes by the same factor. Even to the point where only powerful dc-hosted nodes would struggle to verify and propagate blocks in a meaningful amount of time.

It's not that I oppose increasing the block size - quite the contrary. I just think we should think thrice before we do it.
Pages:
Jump to: