Quickseller
Copper Member
Legendary
Offline
Activity: 2996
Merit: 2374
|
|
July 08, 2015, 08:20:09 PM |
|
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.
|
|
|
|
RoadTrain
Legendary
Offline
Activity: 1386
Merit: 1009
|
|
July 08, 2015, 08:33:43 PM |
|
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.
|
|
|
|
yahoo62278
Legendary
Offline
Activity: 3794
Merit: 4588
Contact @yahoo62278 on telegram for marketing
|
|
July 08, 2015, 08: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/6851c6d83e87c1189b1311aed1f912dab542487888e2d9c1513595c35a601cefi dont know about the rest of you but enough is enough
|
..Stake.com.. | | | ▄████████████████████████████████████▄ ██ ▄▄▄▄▄▄▄▄▄▄ ▄▄▄▄▄▄▄▄▄▄ ██ ▄████▄ ██ ▀▀▀▀▀▀▀▀▀▀ ██████████ ▀▀▀▀▀▀▀▀▀▀ ██ ██████ ██ ██████████ ██ ██ ██████████ ██ ▀██▀ ██ ██ ██ ██████ ██ ██ ██ ██ ██ ██ ██████ ██ █████ ███ ██████ ██ ████▄ ██ ██ █████ ███ ████ ████ █████ ███ ████████ ██ ████ ████ ██████████ ████ ████ ████▀ ██ ██████████ ▄▄▄▄▄▄▄▄▄▄ ██████████ ██ ██ ▀▀▀▀▀▀▀▀▀▀ ██ ▀█████████▀ ▄████████████▄ ▀█████████▀ ▄▄▄▄▄▄▄▄▄▄▄▄███ ██ ██ ███▄▄▄▄▄▄▄▄▄▄▄▄ ██████████████████████████████████████████ | | | | | | ▄▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▄ █ ▄▀▄ █▀▀█▀▄▄ █ █▀█ █ ▐ ▐▌ █ ▄██▄ █ ▌ █ █ ▄██████▄ █ ▌ ▐▌ █ ██████████ █ ▐ █ █ ▐██████████▌ █ ▐ ▐▌ █ ▀▀██████▀▀ █ ▌ █ █ ▄▄▄██▄▄▄ █ ▌▐▌ █ █▐ █ █ █▐▐▌ █ █▐█ ▀▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▀█ | | | | | | ▄▄█████████▄▄ ▄██▀▀▀▀█████▀▀▀▀██▄ ▄█▀ ▐█▌ ▀█▄ ██ ▐█▌ ██ ████▄ ▄█████▄ ▄████ ████████▄███████████▄████████ ███▀ █████████████ ▀███ ██ ███████████ ██ ▀█▄ █████████ ▄█▀ ▀█▄ ▄██▀▀▀▀▀▀▀██▄ ▄▄▄█▀ ▀███████ ███████▀ ▀█████▄ ▄█████▀ ▀▀▀███▄▄▄███▀▀▀ | | | ..PLAY NOW.. |
|
|
|
Quickseller
Copper Member
Legendary
Offline
Activity: 2996
Merit: 2374
|
|
July 08, 2015, 09:01:11 PM |
|
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.
|
|
|
|
Sammot
|
|
July 08, 2015, 09:16:52 PM |
|
Right! Enough is enough! Let's raise the blocksize.
|
|
|
|
Pathi (OP)
|
|
July 08, 2015, 09:36:48 PM |
|
I am getting tired of waiting for mining income. Enough is really enough.
|
|
|
|
RoadTrain
Legendary
Offline
Activity: 1386
Merit: 1009
|
|
July 08, 2015, 09: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.
|
|
|
|
Mikestang
Legendary
Offline
Activity: 1274
Merit: 1000
|
|
July 08, 2015, 09:43:07 PM |
|
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.
|
|
|
|
darkangel11
Legendary
Offline
Activity: 2478
Merit: 1360
Don't let others control your BTC -> self custody
|
|
July 08, 2015, 09: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.
|
|
|
|
DooMAD
Legendary
Offline
Activity: 3948
Merit: 3191
Leave no FUD unchallenged
|
|
July 08, 2015, 10:13:09 PM |
|
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. JorgeStolfi addressed this few a few posts prior. It's quite an eloquent explanation and I can't fault his reasoning. See below: [ With larger blocks ] Spammers can send millions of 0.0001 bitcoins without any fee to flood the mempool regardless of the blocksize. With a 20MB block, they will quickly raise the average block size to 20MB and heavily slowdown the network. On the contrary, it is safer to stay at current 1MB blocksize, so that spam can be analyzed thoroughly and dealt with
The larger the block size limit, the more expensive a spam attack would be. To be effective, a spam attack must generate more transactions per second than the network can confirm (in addition to its normal traffic). With 1 MB blocks, that would be more than 1.8 transactions per second. With 8 MB blocks, it would be ~21 tx/s, With 20 MB blocks, it would be ~53 tx/s. Only the excess spam above those numbers would accumulate in the queues, creating and feeding the backlog. 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. Also, the larger the block size limit, the faster a backlog will clear out. The goal of the current spam test was to reach 250 MB of unconfirmed transactions (but they got about 70 MB maximum, so far). The backlog will clear at the rate equal to the capacity of the network, minus the current traffic (which is about 30% of the capacity). So, with 1 MB blocks, minus 300 kB per block, it would take ~360 blocks (~2.5 days) to clear 250 MB of backlog. With 8MB blocks, it would take ~33 blocks (~5.5 hours). With 20 MB blocks, it would take ~13 blocks (~2 hours). 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. But the main reason to increase the limit is not to ward of spam attacks (which, as said above, are impossible to avoid). It is only to prevent the network from becoming saturated due to a possible increase in normal traffic. If the average normal daily traffic gets to about 300'000 tx/day (only 3 times the current value), there will be recurrent "traffic jams" that take several hours to clear. The delays due to traffic jams will drive more users away from bitcoin, until the traffic stops growing. Only users who really need bitcoin (like drug users and ransomware victims) will put up with the jams. Increasing the block size should have been a no-brainer non-event, a trivial and routine maintenance action to get one possible problem out of the way. 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. Unfortunately, the business plan of Blockstream requires forcing all individuals who now use bitcoin to use their "overlay network" (Sidechains, Lightning Network, whatever) instead. To do that, they must keep the block size limited to 1 MB until the network saturates, in order to force all clients to pay much more in return for much longer confirmation times. All in name of freedom, of course... Further to his explanation, I feel the need to repeat comments I've made in other threads that a 1MB block is simply not sustainable if Bitcoin is to survive in future. As the block reward diminishes over time, the incentive to secure the network will become more reliant on fees. This increase in fees can either be a larger amount paid by each individual user, or better yet (in my view) a greater number of users paying fees. If we arbitrarily limit the number of transactions per block to something that could fit neatly into a floppy disk (and still have a bit of space left over), we are also arbitrarily limiting the amount of fees that can be collected per block. Would you rather each users pays around $9 or $10 in fees for each transaction? Or have 10 times more users and pay $1 or $0.90? Or better still, 100 times more users paying $1 and more revenue to incentivise more miners and cover any increased bandwidth costs they might incur as the network grows? The system will scale naturally if you don't artificially cripple it. It's been said about a billion times before, but a permanent 1MB limit was never part of the original design and (as this current wave of threads proves beyond all doubt) it does absolutely nothing to deter spam anyway. Give Bitcoin room to grow and I promise it won't disappoint. Raise the blocksize and ensure the network's longevity.
|
|
|
|
Mikestang
Legendary
Offline
Activity: 1274
Merit: 1000
|
|
July 08, 2015, 10: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: <snip> 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.
|
|
|
|
DooMAD
Legendary
Offline
Activity: 3948
Merit: 3191
Leave no FUD unchallenged
|
|
July 08, 2015, 11: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: <snip> 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.
|
|
|
|
sidhujag
Legendary
Offline
Activity: 2044
Merit: 1005
|
|
July 08, 2015, 11:30:31 PM |
|
With an increase in blocksize and fees decreasing as a result, spam attacks will only get bigger not smaller.
|
|
|
|
bullpen
Newbie
Offline
Activity: 1
Merit: 0
|
|
July 08, 2015, 11: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
|
|
|
|
sidhujag
Legendary
Offline
Activity: 2044
Merit: 1005
|
|
July 08, 2015, 11: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.
|
|
|
|
MeteoImpact
Member
Offline
Activity: 97
Merit: 10
|
|
July 08, 2015, 11: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.
|
|
|
|
sloopy
|
|
July 08, 2015, 11: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.
|
Transaction fees go to the pools and the pools decide to pay them to the miners. Anything else, including off-chain solutions are stealing and not the way Bitcoin was intended to function. Make the block size set by the pool. Pool = miners and they get the choice.
|
|
|
johnyj
Legendary
Offline
Activity: 1988
Merit: 1012
Beyond Imagination
|
|
July 09, 2015, 12:53:28 AM |
|
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. 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 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
|
|
|
|
Quantus
Legendary
Offline
Activity: 883
Merit: 1005
|
|
July 09, 2015, 12:53:51 AM Last edit: July 09, 2015, 01:10:00 AM by Quantus |
|
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.
|
(I am a 1MB block supporter who thinks all users should be using Full-Node clients) Avoid the XT shills, they only want to destroy bitcoin, their hubris and greed will destroy us. Know your adversary https://www.youtube.com/watch?v=BKorP55Aqvg
|
|
|
melody82
|
|
July 09, 2015, 01:01:49 AM |
|
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.
Wait, I don't understand. If they are mining empty blocks, then they are not processing ANY transactions, but just taking the generated btc? This sounds like another flaw in the system.
|
|
|
|
|