[nullc]

Why add TCP to IP or HTTP to TCP?

It's sound engineering. Like in other systems by composing layers you can achieve the advantages of each component while addressing their costs, without creating insurmountable complexity... "have your cake and eat it too".

Particularly, the central Bitcoin system is a global broadcast medium-- necessarily for its security. Global broadcast is inherently somewhat limited in its scalability (though less than some assume). Other layers effectively add "transaction switching" to Bitcoin, radically improving scalablity and performance with their own costs which are good trade-offs for their applications.

As far as the status quo of traditional finance... If you're happy with the status quo! Use it!

(I'm going to assume you don't mean the status quo of Bitcoin--because 28kb/sec isn't something only large entities can keep up with, it adds up over time-- but even cumulatively its managable)

You could recreate the status quo of centralized finance with Bitcoin, but it wouldn't be obviously better: at least systems like visa and paypal are purpose build to do what they do. Bitcoin takes on a lot of costs and tradeoffs to achieve decenteralization.

Bitcoin was created to be money that existed above and outside of the vulgarities of immediate human politics, just like how strong encryption made it effectively impossible for some sysadmin to just read your files based on some excuse.

I think having that option in the world is extraordinarily valuable.

[lawn]

It's laughably bad engineering to try to solve the scaling issue of the base layer by adding another layer on top. It's like you'd try to solve a throughput problem of IP by layering TCP or HTTP on top.

But this is the logic of one of the main devs who championed the "fee market" idea of Bitcoin[0], that high fees are required for Bitcoin to function. And who in 2017 celebrated when fees were around $50.[1]

[1]: https://medium.com/@johnblocke/the-fee-market-myth-b9d189e45...

[0]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017...

[__s]

2nd layer avoids bloating the ledger. Once limits of 2nd layer are being explored, you can make adjustments to 1st layer with information about how that'll improve 2nd layer throughput. This is like arguing that we shouldn't have in-memory caches, we should just have faster disks

Fees prevent spam

[lawn]

Once limits of 1st layer are explored (the Bitcoin developers have never even bothered to research where the limits are) you can augment it with 2nd layer solutions. Both should of course be done simultaneously, and never focus on one to the exclusion of the other.

Even the Lightning Network whitepaper states it needs much larger blocks, and for it to work well you need to be able to settle quickly and cheaply on-chain, which is not the case with full blocks.

[vegarde]

Let me get this clear: You want to WAIT until it's evident that we can't scale anymore, and then add 2nd layers?

And this, you want to do after significant adoption?

So, you are basically going to tell the Starbuckses and other large corporations that have built a large infrastructure around onchain transactions that they need to stop that, wait a few years until 2nd layers are adopted, and then start using that?

[lawn]

I think you should re-read what I wrote:

> Both should of course be done simultaneously, and never focus on one to the exclusion of the other.

I have no issues with developing 2nd layers, but ignoring on-chain scaling and not even looking at what can be achieved is beyond stupid.

In fact we know that moderate blocksize increases are safe (we can increase it many times before block propagation time becomes an issue for example). Yet we've thrown that out and placed our hope that 2nd layers will magically solve this for us.

> So, you are basically going to tell the Starbuckses and other large corporations that have built a large infrastructure around onchain transactions that they need to stop that, wait a few years until 2nd layers are adopted, and then start using that?

No, that's exactly what has happened to Bitcoin, and what the Bitcoin developers have been saying the last few years. It's what I'm saying is so stupid.

The Lightning Network has been "ready in 18 months" the last 4 years. And it's still not ready.

[DSingularity]

Are knobs for scaling the primary network already well understood? They are limited. Block size and block frequency. So shouldn’t we delay irreversible changes to primary layer until we understand the additional capacity and knobs of second layer solution?

[chris123]

Bitcoin don't need no stinkin" bigger blocks. Second layer FTW.

[nullc]

The article you're linking is an extremely dishonest anonymous hit piece that distorts history to manipulate the audience.

The design of Bitcoin where security is supported by fees to get into blocks is established in the Bitcoin whitepaper and has been in the software since day one.

Contrary to the claims of the article the term "fee market" was introduced and promoted by Jeff Garzik-- rather than people opposing him as the article claims. (Fee market is kind of a bad term, the correct term would be blockspace market, but it actually made sense in the original usage which was about wallets paying 'fees at market rates').

> The answer is lies in the free market. Move transaction fees away from hardcoded limits, and towards something more dynamic, with economic feedback between merchants, users and miners. ... Also introduced is an anti-spam rule that avoids relaying transactions whose value is below that of the transaction fee required to send it. This rule self-adjusts over time, as the "tx fee required to send" changes over time. In a dynamic fee market, it might change a lot.

( https://bitcointalk.org/index.php?topic=196138.msg2044717#ms... )

> 2010-11-19 20:55:42 <jgarzik> eventually we'll all be paying TX fees, sooner or later. and competition to get -some- fee (at lower prices) versus no fee kicks in.

> 2011-02-28 04:13:57 <jgarzik> amiller: it's inevitable that fees will be required. nobody should be assuming bitcoin transactions are / will always be free.

> 2011-03-01 20:32:21 <jgarzik> fees are inevitable

> 2011-03-10 22:14:34 <jgarzik> I think TX fees are a great feedback system; a healthy attribute of bitcoin.

> 2011-11-07 22:43:12 <gavinandresen> Lolcust: yes, but I worry because transaction fees are broken right now-- clients and miners really need more flexibility to let fees go where the market decides, instead of us guessing what the right fees are.

> 2012-10-11 17:01:27 <jgarzik> gmaxwell: I think storage and network will be cheap enough that any non-zero fees will be interesting to miners

> 2013-03-16 00:47:40 <gavinandresen> So: I have no idea what the right answer for fees is. We need to create a market between miners and users, and let the fees go where they belong.

> 2013-03-17 21:12:04 <jgarzik> TD: Satoshi obviously wanted fees to support the system long term. If there is no scarcity, there are no fees.

And people being willing to pay substantive fees to use Bitcoin is absolutely something to celebrate, Bitcoin's long term security is completely dependent on fee income. Getting a non-trivial part of the rewards from fees is a basic validation of the concept.

> 2013-03-17 21:12:44 <jgarzik> TD: The current situation, where block subsidy dominates other incentives, clouds thinking on block size

> 2013-08-12 17:59:33 <jgarzik> auctions make me want replace-by-fee :)

> 2014-05-12 15:13:22 <gavinandresen> hearn: fee cap, meaning what? Fees need to be a market, and rise or fall based on supply and demand for block space

> 2014-08-15 12:37:53 <jgarzik> Merge this useful change, and next will come the call to remove block size limit altogether, which will throw a nuclear bomb onto any nascent fee market.

> 2014-08-15 12:38:37 <jgarzik> All the VCs and execs want an infinite block size limit. It's a sad fixation.

[lawn]

> The article you're linking is an extremely dishonest anonymous hit piece that distorts history to manipulate the audience.

That's rich coming from you. It's easy for anyone reading this to search for what nullc has said and done.

> The design of Bitcoin where security is supported by fees to get into blocks is established in the Bitcoin whitepaper and has been in the software since day one.

Many transactions paying low fees can support security just as well as few transactions paying high fees. I'd say even better as people will stop using Bitcoin or move to other cryptocurrencies when fees grow.

Saying that the "fee market" (or "blockspace market" if you want) is supported by the white paper extremely dishonest. The blocksize limit was only meant as a temporary spam protection, not to enforce higher fees. Zero fee transactions were on the other hand accepted from day one.

[nullc]

> That's rich coming from you. It's easy for anyone reading this to search for what nullc has said and done.

How so? I'm fairly proud of my actions, and I'd be happy to discuss any of them with you.

> The blocksize limit was only meant as a temporary spam protection, not to enforce higher fees.

There is nothing that actually supports that the claim that it was spam protection, thats just blind unsubstantiated assertions.

The system has anti-spam mechanisms in it all along that worked independently of the blocksize.

I think it's fairly likely that Satoshi didn't give these details a lot of thought... It's a champagne problem, and for as many things as he clearly thought through there were many others that were a little rough (e.g. like the broken original longest chain rule).

> Many transactions paying low fees can support security just as well as few transactions paying high fees.

This is being slowly disproved in practice. Bitcoin currently pulls in $3m per month in fees. The most popular fork with no blocksize limit pools in a couple thousand dollar at most, with a substantially lower amount of fees per transaction. Even if their block was 95% full at their current rate, it wouldn't be more than a few percent of its funding from inflation (while bitcoin fees currently are as much as 25% of that altcoin's inflation).

Assuming it isn't inhibited by node resource usage, propagation centralization pressures, or other considerations it could always be increased in the future... going the other day with an ecosystem that depens on effectively zero fees would be much harder. I don't think it's an accident that analysis supporting unlimited block sizes assumes perpetual inflation instead of limited supply.

[trevelyan]

> I don't think it's an accident that analysis supporting unlimited block sizes assumes perpetual inflation instead of limited supply.

Agree, although this assumes that the free market cannot be trusted to regulate the size of the blockchain which seems possible with automatic transaction rebroadcasting. Are you familiar with the technique? Thoughts on it?

https://youtu.be/agppUdX9YvI?t=105

I'd be curious what you think about the approach. The basic idea is that forcing new and old transactions to compete for space on-chain pushes the blockchain into an equilibrium where data-in equals data-out. On either side of the equilibrium point block producers can increase their profits (and reduce costs) by moving towards equilibrium. So no need for a hardcap and no need for perpetual inflation.

[nullc]

That approach allows temporary censorship by miners to be converted into permanent coin loss (thus increasing the value of the attacker's non-censored coins). It also (by itself) doesn't produce an ongoing rate which is necessarily compatible with decenteralized operation of the network.

[shilch]

TCP wasn't build on IP because it wasn't scalable. It was build on it because it was. But that aside, calling Lightning on BTC a second-layer is a bit misleading: Lightning data is not encapsulated in BTC data, more like the other way around; so Lightning is more like layer 0 and BTC layer 1 in that model. (That's also not entirely correct either but much closer)

[im3w1l]

> At the start, TCP handled both datagram transmission and routing, but as the protocol expanded, other researchers started to recommend that these two functions be split into layers.

> One of these researchers, Jonathan Postel of the University of California’s Information Sciences Institute and an editor for the Request of[sic] Comments (RFCs) which is a document series capturing the development of the Internet.

> Postel has stated:

> “We are screwing up in our design of Internet protocols by violating the principle of layering”

> Basically, the monolithic design of TCP would soon become inflexible and unable to scale efficiently. Therefore TCP was split into two protocols, TCP & the Internet Protocol (IP).

https://www.colocationamerica.com/blog/history-of-ip-address...

[shilch]

I'm not all too familiar with the history of IP and TCP but my point still stands. Protocols aren't build because the underlying protocol doesn't scale in term of throughput, it's for the opposite reason that they scale very well. I could also have used HTTP and TCP.

[nullc]

Bitcoin has very strong properties for _security_ which is the inherent property that makes it possible to build other automated trustless systems on top of it.

The comparison with TCP and IP is limit in that TCP data all goes inside IP packets. With second layer transaction systems the relationship is different: the security and stability comes from the underlying blockchain. The higher part adds capacity.

Bitcoin forms a trustworthy robotic court system upon which the wheels of automated commerce can ride.

[phillipsjk]

Scaling with second layers instead of on-chain is NOT "sound engineering"

The Engineering discipline relies on empirical studies. With constantly full blocks, you have no way to measure transaction demand.

Fees are only a weak indicator of transaction demand because of substitute goods.

[marcinjachymiak]

A great empirical study you should pursue is initial blockchain download time with (full) 2000 MB blocks and low-grade consumer hardware.

[freeAgent]

People have already done this and it is quite fast! https://www.reddit.com/r/btc/comments/ek0614/current_node_im...

Flowee the Hub (Bitcoin Cash full node implementation) can sync the equivalent of 4GB blocks using just a cheap quad-core VPS.

[nullc]

Amusingly enough ... The rates there are, in fact, significantly slower than what plain old Bitcoin developers. Bitcoin dev's probably should make the syncing status print the number of inputs per second being processed.

But being able to barely keep up means that if you fall behind for even a moment (say, if your connection drops... or if miners get lucky and mine a bunch of extra blocks) then you will _never_ catch up. Operating anywhere near the limit of your processing rate is non-viable for that reason.

You need to be able to process many times the network's capacity so that you can catch up in a reasonable amount of time.

[freeAgent]

Sure, but OP said 2GB. A node able to process 4GB blocks would be able to sync at 2x realtime. Most people who run nodes will probably bootstrap new ones in the future anyway and most people don't need to run full nodes in the first place (the majority don't do so today and haven't since light wallets became available).

To get back to reality, I don't think any sane person has advocated for anything close to a 2GB blocksize cap at any point in the near future. Bitcoin Core uses a maximum 4MB block weight and Bitcoin Cash uses a 32MB cap currently. This cheap VPS could sync the entire Bitcoin (Core) blockchain from 2009 to present in less than 12 hours. The biggest block size cap (not full blocks, the cap) being tested seriously is 1GB. I'm sure you know all this, though.

[intabli]

It’s not sound engineering whatsoever, it actually is horrible engineering especially when the base layer is congested - Engineers and developers who are far more proficient than you have already chimed in on this, including Vitalik the creator of Ethereum, who also firmly supports the path to scale Bitcoin Cash is taking:

https://vitalik.ca/general/2019/12/26/mvb.html

[kain_niak]

This is hackernews dude, you don't control this one.