Hey, Core development guys; listen up; C.O.M.P.R.O.M.I.S.E. already. Would 1.1MB really kill ya? You are getting a bad reputation out here. If 1.1MB is a waste of time in your eyes then, ok, 2MB; whatever, it is more about appearances than anything. You don't think you can ride 1MB forever, right? Give us a clue; when do you think a blocksize increase will be appropriate?
Sorry to break it to ya but the core devs would hardly be having a look at this site, let alone in one of the specific thread where one random individual has made a suggestion. Github, the place for Bitcoin geeks is the only place  Oh; thanks. Um, shoot; how does one post to Github effectively? |
|
|
|
|
Hey, Core development guys; listen up; C.O.M.P.R.O.M.I.S.E. already. Would 1.1MB really kill ya? You are getting a bad reputation out here. If 1.1MB is a waste of time in your eyes then, ok, 2MB; whatever, it is more about appearances than anything. You don't think you can ride 1MB forever, right? Give us a clue; when do you think a blocksize increase will be appropriate?
|
|
|
|
I see both sides. Compromise. Increase the blocksize to 1.1MB just to see how it goes; nothing like a little practice; who ever said doubling it was the only way forward? Get SegWit out the door as soon as it is really ready.
If I were king (you could make a worse choice) then I would set the blocksize to 32MB (or whatever maximum value is workable right now) and then get to work on overcoming that maximum via block segmentation, etc. Despite that I would do what I could to facilitate legit users paying reasonable fees. The free lunch of zero-cost transactions is over.
So, maybe I wasted my time deinstalling Classic and installing Core. *sigh* Do I really have to break open the code and make my own version?
I would encourage anyone creating their own versions.  Good to keep in mind that two megabytes is already a compromise. The first proposal was twenty megabytes, second proposal was eight megabytes. Classic represents the third proposal at two megabytes. If anything I think it is time for the other side to compromise. So far they have not moved an inch. I would even welcome a hard fork to 1.1 megabytes just to prove a point, that it can be done and to decrease all of the unnecessary fear mongering that surrounds such a change, at least then we would have a precedent. Ok, fine. What do I do? Offer to pay a bounty for my version? How much is this going to cost me? Literally dust off my coding skills? Geesh, I did download the Git software a while ago and goofed around with it. I am an old VMS cli kind of guy so this is out of my comfort zone. |
|
|
|
|
There are two ways to "pay"; 1) fees to miners, 2) send Bitcoins to an inaccessible address. Paying miners is great and well worth it. Sending Bitcoins to an inaccessible address "pays" all holders. Perhaps we can make truly burdensome transactions costly by requiring they pay the latter. Yeah, yeah, which transactions are so burdensome?
|
|
|
|
I read through all of it; thank you. What I see is a need to make burdensome things cost more. Things like transactions that deliberately make pruning less effective. |
|
|
|
|
I see both sides. Compromise. Increase the blocksize to 1.1MB just to see how it goes; nothing like a little practice; who ever said doubling it was the only way forward? Get SegWit out the door as soon as it is really ready.
If I were king (you could make a worse choice) then I would set the blocksize to 32MB (or whatever maximum value is workable right now) and then get to work on overcoming that maximum via block segmentation, etc. Despite that I would do what I could to facilitate legit users paying reasonable fees. The free lunch of zero-cost transactions is over.
So, maybe I wasted my time deinstalling Classic and installing Core. *sigh* Do I really have to break open the code and make my own version?
|
|
|
|
I think you are mistaken, the problem is that there is not enough network capacity. Increasing the networks capacity solves the problem of congestion now. You need to think about this more long term, now is not the time to restrict the throughput of the network. If we have twice the network throughput it will be twice as expensive with the same fees to attack the network. This property increases as we increase the blocksize. Bitcoin will not be able to compete with the alternative cryptocurrencies when they can just increase the blocksize, this was always the intention with the original design of Bitcoin as well. In the long term we might have more expensive fees but I think that should be up to the free market to decide, not enforced through an economic policy tool like the blocksize limit. With an increased blocksize over the long term it will be much more expensive to attack the network in this way. Making Bitcoin more unreliable and expensive will simply just lead to its obsoletion, we can already see how Ethereum is rising in response to this crisis. Most altcoins already have a TPS in the hundreds, the 3-7 TPS of Bitcoin is just a bad joke there is no chance that Bitcoin will remain the dominant cryptocurrency if that remains the case.
Unfortunately even a 32MB blocksize (or even larger) can't be the answer. Spammers could just load 'em up with crap low/zero fee transactions. How much legit traffic is there right now? In that case miners could put the spam into blocks making them pay for it, zero fee transactions will just get dropped. While also avoiding any confirmation dellays in the proccess. In the example that you mention, with a standard low transaction fee of 0.0001. It would cost approximately 6.4 Bitcoins per block to attack the network. At the current Bitcoin price it would cost approximately four hundred thousand dollars per day to attack the Bitcoin network with a thirty megabyte blocksize limit. I would argue that this is a much better defense against a spam attack compared to restricting the blocksize, while very importantly not sacrificing the utility of Bitcoin. Bitcoin is a permisionless network, I do not think there even is such a thing as spam unless you can prove the malicious intentions of the spammers, which is sometimes the case. I do think that what we are seeing now is the network simply reaching capacity, which is why its capacity must be increased or Bitcoin risks being out competed and obsolesced by alternative cryptocurrencies and fiat. Miners have a stake in the health of Bitcoin; it makes no sense for them to undermine it. Hmm, I too thought about how large blocks let the spammers go broke faster *but* the larger blocksize also encourages lower fees. Has anyone done the math (or simulation) to see how the two forces play out? |
|
|
|
I hope you realize what it means in terms of governance to run Core. I am strongly opposed to their conception of Bitcoin governance regardless of the blocksize issue.
I too am terribly uneasy about such a small number of people holding the keys; they are vulnerable to coercion and/or simple misguidance. I would be ok with the Classic guys taking the keys but they are vulnerable to the same things. I don't have an answer. Polarizing on the blocksize is not healthy. Depolarizing is going to be the way forward for sure. Would someone please point me at a site that reveals the current and historic legit traffic? |
|
|
|
I think you are mistaken, the problem is that there is not enough network capacity. Increasing the networks capacity solves the problem of congestion now. You need to think about this more long term, now is not the time to restrict the throughput of the network. If we have twice the network throughput it will be twice as expensive with the same fees to attack the network. This property increases as we increase the blocksize. Bitcoin will not be able to compete with the alternative cryptocurrencies when they can just increase the blocksize, this was always the intention with the original design of Bitcoin as well. In the long term we might have more expensive fees but I think that should be up to the free market to decide, not enforced through an economic policy tool like the blocksize limit. With an increased blocksize over the long term it will be much more expensive to attack the network in this way. Making Bitcoin more unreliable and expensive will simply just lead to its obsoletion, we can already see how Ethereum is rising in response to this crisis. Most altcoins already have a TPS in the hundreds, the 3-7 TPS of Bitcoin is just a bad joke there is no chance that Bitcoin will remain the dominant cryptocurrency if that remains the case.
Unfortunately even a 32MB blocksize (or even larger) can't be the answer. Spammers could just load 'em up with crap low/zero fee transactions. How much legit traffic is there right now? |
|
|
|
|
Spammers; bring it until you are broke; you are literally helping improve Bitcoin.
Legit users; quit your whining; pay reasonable fees during these spam attacks.
Developers; continue to help legit users pay reasonable fees. Be on the lookout for the time when a bigger block size is needed to move legit traffic at reasonable fees.
Governance; i.e. the community at-large, this debate had to take as long as it did due to a variety of reasons (and I sincerely doubt we've heard the last of it). Do not lose heart. Bitcoin is a keeper technology. Embrace reasonable fees; the early days of low/zero fees are behind us now; remember them like we remember floppy diskettes, etc.
|
|
|
|
Can I configure my full node to combat spamming? For example, configure my firewall to prohibit known bad IPs? Configure my Bitcoin application to not forward known bad Bitcoin addresses?
You can do whatever you want. As a non-mining full node operator, pay me and I will forward your transactions. Don't pay me and I won't.
No. How many no-fee transactions are waiting typically?
You should assume that the number of TX's at a fee of 0 are infinite. Would a 1MB block clear them pretty well?
No. Cool; you've convinced me; I might be thick but I am not infinitely so. I am switching from Classic to Core. Thank you for your patience. The easiest/best/only? way to fight spam is by making it expensive for them. So far the only answer appears to be increasing fees. Attempting to increase adoption with unrealistic low/zero fees is misleading. One day we will need to increase the block size in order to accommodate non-spam traffic; we just aren't there yet. How much non-spam traffic is flowing through these days? |
|
|
|
|
Suppose a half-difficulty, no-reward block were allowed if it only included no-fee transactions once a day? I think I might be willing to contribute toward that sort of cause. How many no-fee transactions are waiting typically? Would a 1MB block clear them pretty well?
How to keep crap transactions out?; that's the question.
Spammers: behave! If you ruin Bitcoin then how is this good news?
|
|
|
|
Big blocks would let the spammers burn through their resources faster.
Not necessarily. Hmm, training the unwashed masses to include enough fees to make spamming costly *is* a good idea. I hadn't thought of it that way. Thank you. Can I configure my full node to combat spamming? For example, configure my firewall to prohibit known bad IPs? Configure my Bitcoin application to not forward known bad Bitcoin addresses? How about the other way; can I configure my Bitcoin application to forward known good Bitcoin addresses before all others? As a non-mining full node operator, pay me and I will forward your transactions. Don't pay me and I won't. Just brainstorming. |
|
|
|
|
Big blocks would let the spammers burn through their resources faster.
|
|
|
|
|
Fees are good ... eventually. I'd much rather sacrifice some fees for now until adoption is more widespread.
I will continue to run a full node (despite the lack of any payment at all); often with 100+ connections and 100's of GB/month.
Which is better for Bitcoin in the long run? More fees now or more adoption now? Hmm?
|
|
|
|
I am glad you installed Bitcoin Classic David Rabahy, that is the solution to this existential crisis after all. It's good to know someone around here has a sense of humor. I was almost inspired to run both Classis and Core at the same time. Almost. I'd like a version which alternates between them.  |
|
|
|
|
Whatever; I've installed classic -- whee.
|
|
|
|
|
As confirmation times and fees rise adoption stalls or worse declines leading to less workload; self-regulation. The appearance will be that we're ok and in a sense we are but is this our vision?
Hurry up and get SegWit out *but* that fundamentally cannot be the end of the story, right?
Perhaps we should practice hard forking, e.g. 1.1MB, just to get use to it. Hmm, or are we saying we never want a hard fork ever again?
|
|
|
|
|
Show Posts
