I don't run things, so my opinion is irrelevant.

If you want my proposal / solution, then that is not in line with core, classic, etc.

It would be something like:

-bump fees to at least 0.08$ per 250b tx.

-bump block size to 2 mb (or implement segwit with a 2mb effective capacity - but also ensuring that all bytes used by segwit get charged the same fees, irregardless of the data structure they are in). 4mb could also be implemented if safe.

-watch with pride the catharsis that ensues as dust/spam get evicted, and block use drops to 400-600kb/block with 3x-5x potential to grow

What you are attacking are the irrationalities of those who attack core devs, not the official position of core devs.

Core has a scaling roadmap to make bitcoin scale far beyond what is capable with block increases. Who told you that they consider scaling a bad thing or that a fee market is their first priority?

With fees at 0.00$ to 0.05$, being ~1% of the block reward, there is no meaningful fee market to discuss about. There is definitely a mechanism where you can bypass the queue by a higher fee, and in this sense it is a market, but the volume of this market is so tiny that it doesn't even register compared to what subsidy does. Miners could be mining empty blocks and it wouldn't affect their pocket negatively. That's how insignificant it is.

If devs push for highers fees => "ohhh those fuckers want to exclude the poor guy"
If devs allow for more space/tx abundance at near-zero fees => "ohhh they are idiots, this attracts attacks, it can't work for the long-term sustainability of bitcoin and bitcoin mining" etc etc.
If devs don't interefere => "oh they are sitting on their ass doing nothing and their incompetence has created these problems"

Whatever they do, either way, or whatever they don't do, you can find a reason to attack them. This type of thinking can be evidenced by writings such as BillyJoe's who, a few months ago, was saying "ohhh I don't want to pay higher fees, I bought my right to transact when I bought my coins" and then, when commenting on the Lightning network, he was spreading FUD about how will the miners get paid if the LN can do so many transactions at low fees, and that miners should get more fees, otherwise bitcoin will be in problem etc etc.

Whatever the situation => you can use it to attack the devs. And this is happening all day.

Low fees? Fuck the devs.
High fees? Fuck the devs.
The devs are staying out of the argument? Fuck the devs again.

Fuck the devs, Fuck the devs, Fuck the devs, Fuck the devs, Fuck the devs, Fuck the devs, Fuck the devs, Fuck the devs, Fuck the devs, Fuck the devs, Fuck the devs, Fuck the devs, Fuck the devs, Fuck the devs, Fuck the devs, Fuck the devs, Fuck the devs, Fuck the devs, Fuck the devs, Fuck the devs, Fuck the devs, Fuck the devs, Fuck the devs, Fuck the devs

...all day long...

Why?

Because the issues here are not technical. They have the facade of technical disagreements but at their root, they are a way to undermine confidence and promote a governance coup.

I'm just pointing out the obvious problem of blocksize increase limitations.


A baby drinks the milk in order to grow (100% efficiency). The players over here are wasting the 3tx/s limit with spamming. There is no equivalent analogy over there.

I'm trying to understand who exactly is a "smallblocker"?

Core's short-term plan is 1.7mb (segwit) and Classic is 2mb. The difference being ~300kb.

There is no official or alternative development that stays at 1mb.

It's up to them.

As for Segwit, Segwit solves the old issue of tx mal. *and* also gives a capacity upg to those who want it.

Satoshi didn't get the memo that he is retarded for contemplating the flood/spam/dust attack vectors. We should give him the "retard of the century" award.

To replace subsidy you'd need 100MB blocks, assuming that there is 100x demand, and that the quality of this demand is on par with our current top-tier urgent txs that are paying 0.06$ per tx.

The problem is that 100MB blocks don't work. And it's not "Core's fault". And it's not like Gavin Andersen or Classic can make them work either. This type of size will eventually work as software and hardware technology evolves.

It's all relative depending the actual use.
If they are too little, how come the demand for these 3tx/s be so low as to pay only 1-2 cents and/or have issues like wasting these transactions in spamming, moving dust, having gambling micro-txs etc....

Actual demand is lower than these 3tx/s, and the rest (up to the limit) is filled with near-zero-paying crap. That's why there is no serious impact on the fee market. That's why dust continues to move. That's why spammers continue to spam and move coins from here to there to here to there, in a loop, just because they can spam the network and do so at a near zero cost.

Criticism varies.

"Ohhh my tx didn't go in with 1c", "bitcoin is unreliable because fees fluctuate", "I don't want a fee market because it excludes the poor", "3tx/s are too little", "fuck the 1mb central planners" etc etc.

I'm not worried. Just pointing out the obvious pattern:

"Oh I can't tolerate BTC that has a fee market, it's unacceptable if fees go up, the solution to spam can't be to make txs more expensive" => "let's buy some altcoin which does exactly that and claim we are diversifying from the 'dangers' of BTC"... lol?

Why is it unacceptable for BTC to have high fees and for altcoins to have high fees to combat spam?
Why is it more acceptable if altcoins do that by "central planning" while bitcoin's fees are actually determined by the market itself - depending the load on any given moment?
How can "adaptive blocksize" be considered a better solution when it can't work without central planning on fees? It failed monero, so why is it touted as a better solution?

We can be throwing shit all day to BTC, but to change the negatives and spin them to positives and vice versa is just propaganda.

The adaptive blocksize in itself is a security weakness without substantial fees. A spammer can easily make the system "adapt" to his ever increasing demands to spam it for near-zero cost and destroy it. Plus network propagation and block validation has a certain time required, you cannot go to infinity just because someone is spamming it.

So, when the time came for such a spam scenario, "central intervention" by the devs happened and they raised the fees quite higher to make every tx much more expensive.

So the solution for Monero, wasn't the adaptive blocksize (it was broken unto itself, if you expected the "market" or the "miners" to determine the fees) => but the centrally imposed fees.

Likewise Bitcoin could have 4mb blocks tomorrow morning, if, say, every tx was bumped to something like 10 cents minimum. This, by itself, would probably have us at <500kb block use right away by eliminating dust & spam, with an 8x expansion space up to 4mb.

What it shows is that any system that has a low cost to be abused, can get abused.

Near-zero cost txs = near-zero cost abuse.

If the fees were higher, the cost of attacking the system would have been higher and the risk of attacks much lower.

It could also be a pretentious conflict by third parties (banks, government agencies etc) who prefer division in the btc world.

Classic nodes don't play any meaningful role in order to get attacked. What counts for activating a 2mb HF are the miners, not the nodes. And since the miners are smart enough to understand the destructive consequences of contentious hard forks and splitting the currency in two, which would forever destroy the trust in bitcoin as a currency, they chose not to go down that destructive split. In other words classic is dead. And you know what they say about beating the dead horse. That's what DDOSing an "xt" or "classic" node is.

I was expecting something less professional in terms of look, packaging, manuals etc. Interesting.

No, but we actually had disk quotas on our unix shells and everyone understood the reason for it because we were more technically minded. A mass mailbombing on the list of users stored at the /etc/passwd file would not only fill all our mailboxes, it could actually fill the entire server and crash it.


It depends on what you mean "production". We are talking about services here. The closest thing that comes to mind, in terms of central planned services and quotas, is national infrastructure.

In my country, for example, the main roads and train lines that connect the various cities are singular. There aren't 5 roads or 5 train lines that overlap the same distance and "compete" between themselves. There aren't 3 power line networks that compete. It is well understood that a centrally planned infrastructure in things like roads, train lines, water pipes, gas pipes, power lines, etc etc, cannot be subject to competition. It is highly redundant, increases costs, decreases efficiency, etc etc. Whatever competition might exist, is in layers beyond the infrastructure itself.


Initially it might have started uncapped - I actually remember having one that was uncapped, although I didn't use that one - until they had to impose the few kbytes limits due to practical considerations.


...as technology allowed it.

The quota is a given due to hardware and software limitations. It's not like right now you can remove the 1mb limit and you'll be successfully mining 20-100-1000mb blocks. It can't happen. That's the reality of it. So you make the best use of what you have. That's how all technologies evolve.

In the 90's, when email started getting traction, as soon as people had a few kb / a few mb mailboxes, mailbombing begun as an attack vector. You could literally clog one's email address, making it unable to receive any email because you simply carbon copied the same email 100 or 1000 times, or put a small attachment and sent it 10 times. If people were as "bitchy" back then, they would be saying "oh what's this crap with this email thing, this can never work, it's DOA, it can't scale" etc etc.

Well, here we are 20+ years later having gigabytes for email storage and email working fine. But, in the meantime, technology evolved to allow it to happen.

What seems incompressible can generally be compressed more if one shifts the order of characters around a file. For example: https://en.wikipedia.org/wiki/Burrows%E2%80%93Wheeler_transform (that's what bzip does btw). In theory a compression system could use multiple such "tables" and try various configurations to find new redundancies, folding and re-folding the data again and again, but obviously I'm not going to ask you to invent such a system

In any case, whatever degree of compression is achieved => is good. If a compressed block, for example, can be reduced from 1mb to 600kb, it's a huge improvement for someone with a slow connection.

Bitcoin's strength right now is in moving any amount of money, even ridiculously high amounts, in a few minutes with a pretty low fee. That's what it does best, under the current parameters - not micropayments.

Micropayments can exhaust the 250.000 txs/day limit (even 500.000 txs or 1mn txs with 4mb blocks) and if you waste them to move around 1 dollar, you'll be doing 250k / 1mn USD per day in volume.

OR, you can use these same transactions for higher value transfers (~1000$ on avg), hitting 250mn - 1bn USD per day in volume.

It's a no-brainer.

Never is a big word.

Right now bitcoin is transacting (outputs minus change) 220mn per day in 250k txs.

https://blockchain.info/charts/estimated-transaction-volume-usd?showDataPoints=true&timespan=1year&show_header=true&daysAverageString=1&scale=0&address=

This is ~880$ per average tx and it means ~80bn* USD per year.

If you implement segwit + 2mb blocks (2.7txs x 1.65 x 2) you get 8.9tx/s.

With a steady volume (I'm not even following the upward trend in value transacted), you get 880$ x 8.9 x 60 x 1440 = 677mn USD per day and 247bn USD per year.

Paypal does 228bn USD. At that point we've already "scaled" financially past Paypal with our "pitiful" 9 tx/s, and with fees being at ridiculous costs like 0.02-0.05$.

Don't underestimate the scaling of value transacted. It's a very important side of scaling.


* Western union at 85bn USD in the consumer market: http://ir.westernunion.com/News/Press-Releases/Press-Release-Details/2016/Western-Union-Cross-Border-Platform-Connects-Consumers-to-over-One-Billion-Bank-Accounts/default.aspx  => "The Western Union Company completed 255 million consumer-to-consumer transactions worldwide, moving $85 billion of principal between consumers, and 484 million business payments."

Bandwidth limited = I/O and cpu limited then?

We had a similar discussion in another thread, but anyway I want to write it more concisely here: I really believe scaling can be achieved through tradeoffs of what a user has and what he hasn't. Every machine will hit a bottleneck somewhere, the issue from that point onward is how to juggle the tradeoffs to bypass your bottleneck.

Examples:

-A user has a slow internet connection but plenty of CPU => He should have the option of downloading (and uploading - if he is running a node) very compressed blocks with other cooperating nodes that are willing to use compressed blocks.
-If the same user has slow CPU as well => He should be able to tap into GPU resources for parallel compression/decompression (it's feasible - I've seen pdf's with research on the subject of parallel compression on GPU).
-If a user has slow I/O but fast CPU => Compress the blockchain for more local throughput
-If a user has low RAM but fast CPU => Compress the RAM (for things like compressed cache)
-If a user has slow I/O or low RAM but will bottleneck on CPU if he goes to a compressed scheme => tap into GPU
-If a user wants to increase cache size to increase performance, but lacks ram => Use compressed RAM, tap into more CPU, to reduce I/O.

Essentially you try to trade what you have with what you want to achieve. One size fits all solutions won't work particularly well because one user has 1gbps connection, another has 4mbps. One is running on a xeon, the other is running on a laptop. One has 16gb memory, another has 2. One can tap into a GPU for parallel processes, another can't because he doesn't have one.

IMO the best scaling solutions will be adjustable so that bottlenecks can be identified in a particular system and make the necessary tradeoffs to compensate for deficiencies. Compression is definitely one of the tools that can balance these needs, whether one lacks RAM, disk space on their SSD, bandwidth on their network etc. And GPUs can definitely help in the processing task - whether the load is directly related to btc operations or compression/decompression.