Topic: Soft block size limit reached, action required by YOU - page 4. (Read 64244 times)
While I highly favor increasing the block size I also like the idea of full nodes being compensated somehow. Miners get rewarded, those who don't run full nodes get rewarded, but full nodes currently bear the cost out of almost pure altruism. That can't last.
If a means isn't found for the average Joe to be compensated for running a full node, they are going to start dropping out as they perceive abusive services like Satoshi Dice costing them money.
Finnaly someone who understands the difference between using and abusing
Bottleneck is not hardware, but bandwidth. Average joe's internet connection has to be able to handle a full node. ( 1Mbit/s w/ 10Mbit/s peak)
Everybody isn't cut from the same mold. Different folks have different limits.I was running a full node on a vendor's VPS service (roughtly equivalent to an Amazon Micro Instance). [Very good connectivity, no bandwidth limit, good data rate.] As of a week or two ago, it can no longer handle the volume of transactions. Virtual memory is being exhausted. I'm not willing to pay the higher fees for the next level of service. That node is now gone.
If a means isn't found for the average Joe to be compensated for running a full node, they are going to start dropping out as they perceive abusive services like Satoshi Dice costing them money.
@psy: Thank you. I saw Luke-jr's (more sophisitcated) patch, but I haven't had the time to analyze it.
Blowfeld, Luke-jr has a patch for miners and pools to do the same, this one is for full-nodes frpm non-mining users. https://bitcointalksearch.org/topic/m.1595233
Ofcourse your client will take a little longer to verify the tx signatures that get included in a block because it didn't verified them in advance, but your also not verifying all the double-spends people try with satoshidice, and only veryfying their transactions when they effectively get included in a block.
Works good enough for me. YMMV
Ofcourse your client will take a little longer to verify the tx signatures that get included in a block because it didn't verified them in advance, but your also not verifying all the double-spends people try with satoshidice, and only veryfying their transactions when they effectively get included in a block.
Works good enough for me. YMMV
Code:
diff --git a/src/main.cpp b/src/main.cpp
index 9a06dbf..d3fba73 100644
--- a/src/main.cpp
+++ b/src/main.cpp
@@ -384,8 +384,16 @@ bool CTransaction::IsStandard() const
BOOST_FOREACH(const CTxOut& txout, vout) {
if (!::IsStandard(txout.scriptPubKey))
return false;
+ if (txout.scriptPubKey.size() > 6
+ && txout.scriptPubKey[0] == OP_DUP
+ && txout.scriptPubKey[3] == 0x06
+ && txout.scriptPubKey[4] == 0xf1
+ && txout.scriptPubKey[5] == 0xb6)
+ return error("CTransaction::IsStandard : ignoring transaction with 1dice output");
if (txout.nValue == 0)
- return false;
+ return error("CTransaction::IsStandard : ignoring transaction with 0 value output");
+ if (txout.nValue <= 10000)
+ return error("CTransaction::IsStandard : ignoring transaction with dust output");
}
return true;
}
You may not be interested in the if (txout.nValue <= 10000) test, though it also gets the dice you-lost transactions and other UXTO set bloating flood.
This will make the node not relay or mine these transactions. It will, of course, still accept them in blocks.
Is that what I asked?
If so, can I send the 1 BTC to the address on your sig or do you prefer to PM me a new address?
That rule you mentioned, it drops all tx's which are less than 10k satoshis, right?
My test setup is:
Full client "bitnode1" is well-connected to the internet, with something like 70 connections to other nodes. The patch was applied to this node.
Full client "bitnode2" is behind a firewall and is connected *only* to "bitnode1". This client was unpatched.
Good results:
bitnode1 drops a ton of tx packets. The poolsz doesn't build up like it was doing before the patch.
bitnode2 never receives an SD tx packet. The poolsz remains small.
Not great results:
There are a lot of orphan transactions, because the simplistic logic can't reject all of the response transaction packets from SD.
Unintended result:
When a block comes in from a miner that has included SD transactions, it appears to take my nodes longer to process the block.
Bitnode1 takes several seconds longer to perform its validation, so bitnode2 gets the validated block several seconds later.
Then bitnode2 takes several seconds longer to perform its validation.
This *could* be my imagination, because the content of blocks are so widely varied. And I haven't examined the code carefully. My hunch is that by throwing away the SD tx packets, bitnode1 denies itself the opportunity to validate those tx packets in advance. Bitnode1 also denies bitnode2 the opportunity to validate those tx packets in advance. This patch *does* reduce main memory requirements for the nodes that toss out SD transactions. And it does reduce the node's outgoing bandwidth. However, as long as *any* miner is including the SD packets, the validation still has to get done by every full node in the world. And the SD transactions still have to be stored in the blockchain on every full node in the world.
If a mining pool were to use this simple patch, it may cost themselves and their contributors more stale shares.
1) If block size is increased anywhere up to 10 MB, I will still run a full node on my home computer. Beyond that, I may not be able to. At least with today's technology, anyway.
2) Mining pools would not be affected by such a change. They would (appropriately so) balance the size of a block with the transaction fees that make up said block. They would likely not accept any free transactions, but fees even lower than the default might be ok in some cases. It'll come down to the balance of the potential cost of an orphaned block vs the transaction fees that make up said block. Most blocks would likely be far below a 10 MB limit for quite some time.
3) People who cannot handle 10 MB blocks (around 520GB/year at the MAX, but in reality and for now, much smaller than that) should not run full nodes. This is not a problem - as long as at least SOME people run full nodes, the rest of us are protected. Those who really believe that additional decentralization is necessary should be willing to pay for it. I am. It's only $25/year to buy a new 2TB drive every four years, and it'll only keep getting cheaper (unless another freak flood shows up).
4) I would encourage an increase in the block size because it is beneficial to miners and beneficial to those who wish to make transactions. It is only not beneficial to those who wish to run full nodes, but certainly, it would not put it entirely out of the reach of them.
2) Mining pools would not be affected by such a change. They would (appropriately so) balance the size of a block with the transaction fees that make up said block. They would likely not accept any free transactions, but fees even lower than the default might be ok in some cases. It'll come down to the balance of the potential cost of an orphaned block vs the transaction fees that make up said block. Most blocks would likely be far below a 10 MB limit for quite some time.
3) People who cannot handle 10 MB blocks (around 520GB/year at the MAX, but in reality and for now, much smaller than that) should not run full nodes. This is not a problem - as long as at least SOME people run full nodes, the rest of us are protected. Those who really believe that additional decentralization is necessary should be willing to pay for it. I am. It's only $25/year to buy a new 2TB drive every four years, and it'll only keep getting cheaper (unless another freak flood shows up).
4) I would encourage an increase in the block size because it is beneficial to miners and beneficial to those who wish to make transactions. It is only not beneficial to those who wish to run full nodes, but certainly, it would not put it entirely out of the reach of them.
Not many countries have that kind of bandwidth available for cheap enough.
What you suggest would limit mining to a few countries + an elite in the rest of the world.
I think upping the hard limit any time soon would be overkill.
Just let the fees roll.
1) If block size is increased anywhere up to 10 MB, I will still run a full node on my home computer. Beyond that, I may not be able to. At least with today's technology, anyway.
2) Mining pools would not be affected by such a change. They would (appropriately so) balance the size of a block with the transaction fees that make up said block. They would likely not accept any free transactions, but fees even lower than the default might be ok in some cases. It'll come down to the balance of the potential cost of an orphaned block vs the transaction fees that make up said block. Most blocks would likely be far below a 10 MB limit for quite some time.
3) People who cannot handle 10 MB blocks (around 520GB/year at the MAX, but in reality and for now, much smaller than that) should not run full nodes. This is not a problem - as long as at least SOME people run full nodes, the rest of us are protected. Those who really believe that additional decentralization is necessary should be willing to pay for it. I am. It's only $25/year to buy a new 2TB drive every four years, and it'll only keep getting cheaper (unless another freak flood shows up).
4) I would encourage an increase in the block size because it is beneficial to miners and beneficial to those who wish to make transactions. It is only not beneficial to those who wish to run full nodes, but certainly, it would not put it entirely out of the reach of them.
2) Mining pools would not be affected by such a change. They would (appropriately so) balance the size of a block with the transaction fees that make up said block. They would likely not accept any free transactions, but fees even lower than the default might be ok in some cases. It'll come down to the balance of the potential cost of an orphaned block vs the transaction fees that make up said block. Most blocks would likely be far below a 10 MB limit for quite some time.
3) People who cannot handle 10 MB blocks (around 520GB/year at the MAX, but in reality and for now, much smaller than that) should not run full nodes. This is not a problem - as long as at least SOME people run full nodes, the rest of us are protected. Those who really believe that additional decentralization is necessary should be willing to pay for it. I am. It's only $25/year to buy a new 2TB drive every four years, and it'll only keep getting cheaper (unless another freak flood shows up).
4) I would encourage an increase in the block size because it is beneficial to miners and beneficial to those who wish to make transactions. It is only not beneficial to those who wish to run full nodes, but certainly, it would not put it entirely out of the reach of them.
Not many countries have that kind of bandwidth available for cheap enough.
What you suggest would limit mining to a few countries + an elite in the rest of the world.
I think upping the hard limit any time soon would be overkill.
Just let the fees roll.
What if SD buys some ASICs, patch the src so that they do not broadcast their own transactions and then mine their own blocks? Would that be possible?
1) If block size is increased anywhere up to 10 MB, I will still run a full node on my home computer. Beyond that, I may not be able to. At least with today's technology, anyway.
2) Mining pools would not be affected by such a change. They would (appropriately so) balance the size of a block with the transaction fees that make up said block. They would likely not accept any free transactions, but fees even lower than the default might be ok in some cases. It'll come down to the balance of the potential cost of an orphaned block vs the transaction fees that make up said block. Most blocks would likely be far below a 10 MB limit for quite some time.
3) People who cannot handle 10 MB blocks (around 520GB/year at the MAX, but in reality and for now, much smaller than that) should not run full nodes. This is not a problem - as long as at least SOME people run full nodes, the rest of us are protected. Those who really believe that additional decentralization is necessary should be willing to pay for it. I am. It's only $25/year to buy a new 2TB drive every four years, and it'll only keep getting cheaper (unless another freak flood shows up).
4) I would encourage an increase in the block size because it is beneficial to miners and beneficial to those who wish to make transactions. It is only not beneficial to those who wish to run full nodes, but certainly, it would not put it entirely out of the reach of them.
2) Mining pools would not be affected by such a change. They would (appropriately so) balance the size of a block with the transaction fees that make up said block. They would likely not accept any free transactions, but fees even lower than the default might be ok in some cases. It'll come down to the balance of the potential cost of an orphaned block vs the transaction fees that make up said block. Most blocks would likely be far below a 10 MB limit for quite some time.
3) People who cannot handle 10 MB blocks (around 520GB/year at the MAX, but in reality and for now, much smaller than that) should not run full nodes. This is not a problem - as long as at least SOME people run full nodes, the rest of us are protected. Those who really believe that additional decentralization is necessary should be willing to pay for it. I am. It's only $25/year to buy a new 2TB drive every four years, and it'll only keep getting cheaper (unless another freak flood shows up).
4) I would encourage an increase in the block size because it is beneficial to miners and beneficial to those who wish to make transactions. It is only not beneficial to those who wish to run full nodes, but certainly, it would not put it entirely out of the reach of them.
Not many countries have that kind of bandwidth available for cheap enough.
What you suggest would limit mining to a few countries + an elite in the rest of the world.
I think upping the hard limit any time soon would be overkill.
Just let the fees roll.
Repeat... Let's keep the soft block size limit at 250KB and see what will happen 
I don't think people are so stupid that without that added transaction capacity they will leave bitcoin
I don't think people are so stupid that without that added transaction capacity they will leave bitcoin
1) If block size is increased anywhere up to 10 MB, I will still run a full node on my home computer. Beyond that, I may not be able to. At least with today's technology, anyway.
2) Mining pools would not be affected by such a change. They would (appropriately so) balance the size of a block with the transaction fees that make up said block. They would likely not accept any free transactions, but fees even lower than the default might be ok in some cases. It'll come down to the balance of the potential cost of an orphaned block vs the transaction fees that make up said block. Most blocks would likely be far below a 10 MB limit for quite some time.
3) People who cannot handle 10 MB blocks (around 520GB/year at the MAX, but in reality and for now, much smaller than that) should not run full nodes. This is not a problem - as long as at least SOME people run full nodes, the rest of us are protected. Those who really believe that additional decentralization is necessary should be willing to pay for it. I am. It's only $25/year to buy a new 2TB drive every four years, and it'll only keep getting cheaper (unless another freak flood shows up).
4) I would encourage an increase in the block size because it is beneficial to miners and beneficial to those who wish to make transactions. It is only not beneficial to those who wish to run full nodes, but certainly, it would not put it entirely out of the reach of them.
2) Mining pools would not be affected by such a change. They would (appropriately so) balance the size of a block with the transaction fees that make up said block. They would likely not accept any free transactions, but fees even lower than the default might be ok in some cases. It'll come down to the balance of the potential cost of an orphaned block vs the transaction fees that make up said block. Most blocks would likely be far below a 10 MB limit for quite some time.
3) People who cannot handle 10 MB blocks (around 520GB/year at the MAX, but in reality and for now, much smaller than that) should not run full nodes. This is not a problem - as long as at least SOME people run full nodes, the rest of us are protected. Those who really believe that additional decentralization is necessary should be willing to pay for it. I am. It's only $25/year to buy a new 2TB drive every four years, and it'll only keep getting cheaper (unless another freak flood shows up).
4) I would encourage an increase in the block size because it is beneficial to miners and beneficial to those who wish to make transactions. It is only not beneficial to those who wish to run full nodes, but certainly, it would not put it entirely out of the reach of them.
Not many countries have that kind of bandwidth available for cheap enough.
What you suggest would limit mining to a few countries + an elite in the rest of the world.
I think upping the hard limit any time soon would be overkill.
Just let the fees roll.
You seem to have problems with the idea that mining might get paid for by any mechanism other than transaction fees. The world is full of things that are "free" but get paid for via other means.
Yeah exactly, like getting paid by losing the decentralization and no central authority feature. I don't need that kind of Bitcoin even though it might very well be exactly what you want.
1) If block size is increased anywhere up to 10 MB, I will still run a full node on my home computer. Beyond that, I may not be able to. At least with today's technology, anyway.
2) Mining pools would not be affected by such a change. They would (appropriately so) balance the size of a block with the transaction fees that make up said block. They would likely not accept any free transactions, but fees even lower than the default might be ok in some cases. It'll come down to the balance of the potential cost of an orphaned block vs the transaction fees that make up said block. Most blocks would likely be far below a 10 MB limit for quite some time.
3) People who cannot handle 10 MB blocks (around 520GB/year at the MAX, but in reality and for now, much smaller than that) should not run full nodes. This is not a problem - as long as at least SOME people run full nodes, the rest of us are protected. Those who really believe that additional decentralization is necessary should be willing to pay for it. I am. It's only $25/year to buy a new 2TB drive every four years, and it'll only keep getting cheaper (unless another freak flood shows up).
4) I would encourage an increase in the block size because it is beneficial to miners and beneficial to those who wish to make transactions. It is only not beneficial to those who wish to run full nodes, but certainly, it would not put it entirely out of the reach of them.
2) Mining pools would not be affected by such a change. They would (appropriately so) balance the size of a block with the transaction fees that make up said block. They would likely not accept any free transactions, but fees even lower than the default might be ok in some cases. It'll come down to the balance of the potential cost of an orphaned block vs the transaction fees that make up said block. Most blocks would likely be far below a 10 MB limit for quite some time.
3) People who cannot handle 10 MB blocks (around 520GB/year at the MAX, but in reality and for now, much smaller than that) should not run full nodes. This is not a problem - as long as at least SOME people run full nodes, the rest of us are protected. Those who really believe that additional decentralization is necessary should be willing to pay for it. I am. It's only $25/year to buy a new 2TB drive every four years, and it'll only keep getting cheaper (unless another freak flood shows up).
4) I would encourage an increase in the block size because it is beneficial to miners and beneficial to those who wish to make transactions. It is only not beneficial to those who wish to run full nodes, but certainly, it would not put it entirely out of the reach of them.
Why can't we remove the hard limit and let the miners/pools choose their limit for how large blocks they would accept into the blockchain? (If they are 3 blocks behind, they should accept the first rejected block regardless of size.)
They would have to agree on a size that makes sense, or they will loose money when their blocks get orphaned.
They would have to agree on a size that makes sense, or they will loose money when their blocks get orphaned.
Which is exactly what im trying to explain. This is ultimately capitalism at work.
Products/services don't go to where it's needed, they go where there is the greatest profit to be made.
Products/services don't go to where it's needed, they go where there is the greatest profit to be made.
Well, this is getting pretty off topic, but as I already said the issue is actually political. Unfortunately, whenever we try to give free food to starving people, political problems appear, typically corruption or warlords that use control of food to build their power bases.
http://www.thenational.ae/news/world/africa/corruption-eats-into-somalias-food-aid
The food is free, even, so ability to pay doesn't matter in those cases.
Yes, I do support unemployment benefits. People who lost their job and die on the streets are annoying if you trip over them. A bit of tax is a reasonable price to pay for not having to jump over bodies all the time.
You seem to have problems with the idea that mining might get paid for by any mechanism other than transaction fees. The world is full of things that are "free" but get paid for via other means. I don't know that mining will end up like that, but it wouldn't surprise me if it did. And if it doesn't, OK, we have alternative plans too.
It may seem OT but it does relate to the block size issue.
Lets assume these poor people had money in their hand like people in developed countries do, do you think they would be starving?
Id say they wont starve because capitalism and the free market will find ways around any political barricades the government imposes. This phenomenon is known as the black market.
I hold the view that money is power and government/banks derive their power from control of money. You may believe it to be the inverse and therefore believe that politics is the root issue.
Regardless of our different views, i agree that Bitcoin has the potential to remove this power from them and give it to the people.
Which is why the issue of decentralisation should not be taken lightly, else it will result in the same power concentration again, only to different parties.
I was hoping for the soft limit to drive up txn fees and see what the wallet processors/exchanges/community would come up with, but you kind of ruined that with this post.
A payment processor like Bitpay/Walletbit could have offered prepaid accounts(deposit coins to account) to users which allowed instant processing and 0 txn fee for any txns made to merchants/users with accounts on their systems, something which Bitcoin could never offer.
If you start blocking any particular service bitcoin is as good as dead. The bad pr alone will kill it.
very true
Which is exactly what im trying to explain. This is ultimately capitalism at work.
Products/services don't go to where it's needed, they go where there is the greatest profit to be made.
Products/services don't go to where it's needed, they go where there is the greatest profit to be made.
Well, this is getting pretty off topic, but as I already said the issue is actually political. Unfortunately, whenever we try to give free food to starving people, political problems appear, typically corruption or warlords that use control of food to build their power bases.
http://www.thenational.ae/news/world/africa/corruption-eats-into-somalias-food-aid
The food is free, even, so ability to pay doesn't matter in those cases.
Yes, I do support unemployment benefits. People who lost their job and die on the streets are annoying if you trip over them. A bit of tax is a reasonable price to pay for not having to jump over bodies all the time.
You seem to have problems with the idea that mining might get paid for by any mechanism other than transaction fees. The world is full of things that are "free" but get paid for via other means. I don't know that mining will end up like that, but it wouldn't surprise me if it did. And if it doesn't, OK, we have alternative plans too.
If you start blocking any particular service bitcoin is as good as dead. The bad pr alone will kill it.
You have to distinguish between a) filtering transactions which are included in a valid block (and thus potentially discarding them, causing forks) and b) filtering transactions as you mine. The discussion is about b), i.e. bullying particular transaction types at the stage of propagation for the sake of some greater good.
As long as a) doesn't happen, it really depends on the mining landscape and the policy of individual miners which transaction types have an easier time to get through. And that's good - that's democracy. Miners should be allowed to do whatever they want, as long as it satisfies the minimal rules.
By default Bitcoin will not created blocks larger than 250kb even though it could do so without a hard fork. We have now reached this limit. Transactions are stacking up in the memory pool and not getting cleared fast enough.
What this means is, you need to take a decision and do one of these things:
If everyone does nothing, then people will start having to attach higher and higher fees to get into blocks until Bitcoin fees end up being uncompetitive with competing services like PayPal.
If you mine on a pool, ask your pool operator what their policy will be on this, and if you don't like it, switch to a different pool.
What this means is, you need to take a decision and do one of these things:
- Start your node with the -blockmaxsize flag set to something higher than 250kb, for example -blockmaxsize=1023000. This will mean you create larger blocks that confirm more transactions. You can also adjust the size of the area in your blocks that is reserved for free transactions with the -blockprioritysize flag.
- Change your nodes code to de-prioritize or ignore transactions you don't care about, for example, Luke-Jr excludes SatoshiDice transactions which makes way for other users.
- Do nothing.
If everyone does nothing, then people will start having to attach higher and higher fees to get into blocks until Bitcoin fees end up being uncompetitive with competing services like PayPal.
If you mine on a pool, ask your pool operator what their policy will be on this, and if you don't like it, switch to a different pool.
I suggest that all the pools and miners take this chance and DO NOTHING, and we will see if bitcoin really end up being driven out by PayPal
I think they are totally two different network and surve different purpose. I use paypal mainly because I want to spend inflative fiat money as quick as possible, and it can guarantee a charge back and give me invoice. But bitcoin just can't do that no matter how low the fee is. Bitcoin protect merchant but not consumer, so it will not be used by mass scale of consumers, maybe mostly gamblers
Paypal invoices you for things merchants sell? Kind of hard to believe
Merchants are the ones who must invoice you, not the payment processors. Even if you pay with bitcoin the merchant must give you the invoice with the value in whatever is legal tender in his country.
It has actually. The world produces a surplus of food (see the notorious EU "cheese mountains and wine lakes").
People still starve, but that's usually due to political problems (food can't get to where it's needed), not because we don't know how to feed everyone.
People still starve, but that's usually due to political problems (food can't get to where it's needed), not because we don't know how to feed everyone.
Which is exactly what im trying to explain. This is ultimately capitalism at work.
Products/services don't go to where it's needed, they go where there is the greatest profit to be made.
Capitalism, for all it's advantages, is brutal to the weak and unfortunate.
That is the law of the jungle and nature and its the system that has brought the greatest benefit to all of mankind.
It does not matter how much surplus is produced, if you can't pay, you don't get it.
The problem is not that there is surplus food that is not given away free or below cost,
the problem is that there are too many people who are not able to earn a living, often because of political corruption/stupidity,partly because of overpopulation and partly because technology/automation has made most manual labour obsolete.
I assume you support unemployment benefits, foodstamps and minimum wage laws.
Since they benefit the less fortunate and are getting funded somehow.
Perhaps you don't realise that the "funding" is coming from higher inflation/taxes.
This whole idea of somebody will pay for it is not sustainable. Im not saying that charity does not occur, it does, but it does not scale and is not reliable.
Why should anyone work for nothing in return? Because it's noble? Cool, ill do the receiving and the noble people can do the work.
Jump to: