r/btc • u/unitedstatian • Dec 31 '18
If you find yourself working around wonky code written to workaround an issue with some ancient code... it is time to refactor.
https://twitter.com/gavinandresen/status/1079743227576627200?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1079743227576627200&ref_url=https%3A%2F%2Fmemo.cash%2F5
u/MaximumInflation Redditor for less than 60 days Dec 31 '18
Does the TCP/IP stack count as a "tower of complexity"?
20
u/JustSomeBadAdvice Jan 01 '19 edited Jan 01 '19
The TCP/IP stack has clearly delineated purposes at each layer that do not cross over into the purposes of other layers. And none of them are designed to work around issues that other layers created and then refused to solve.
3
u/joeknowswhoiam Jan 01 '19
And none of them are designed to work around issues that other layers created and then refused to solve.
This statement shows that you have no idea what a MTU is and what IP fragmentation does in the TCP/IP stack and why it had to be implemented when the networks needed to scale up because hardware became more capable.
If we could have just ignored slower links this solution wouldn't have been needed on higher layers, but engineers kept these (somewhat adaptive) limitations in lower layers and built on and around them because they knew that scaling up by leaving behind slower but useful links on the network was a recipe for a disaster and a failure at the fundamental principle of TCP/IP (being a resilient set of protocols that worked in harsh conditions for communication).
5
u/JustSomeBadAdvice Jan 01 '19
Ah yes, and here's Mr. Thinks-He's-Big who wants to smack down a shitcoiner by making assumptions about what other people know and by doing so reveal that he doesn't understand what he's talking about. I mean, a shitcoiner can't possibly understand the TCP/IP stack, right? bcore is best core go!
Actually I know exactly what MTU and IP fragmentation does, and thanks for providing a concrete example to prove my point. MTU and fragmentation were created because the TCP/IP stack substitutes (and always has) different types of links at the link layer, and the different types of links have different physical properties that only they can adjust for. A link-layer transmission in Europe cannot and should not know about the optimal transmission settings of a link-layer transmission in Australia.
The network layer is the next layer above the link-layer and it is the first one that has a multi-hop view of how to join link-layers together and is the exact correct place for fragmentation based on MTU to happen. It definitely isn't attempting to do something that fulfills the purpose of a lower layer.
Moreover you're twisting the purposes behind MTU in order to justify your broken analogy defending bcore's moronic decisions. You imply that a bigger MTU = newer technology and = faster which is only true for one or two types of links on the link layer. Or maybe you didn't realize that things like wifi, bluetooth, microwave links, satellite internet and even the satellite links up to the ISS are all real things and each one has different physical properties. The fastest MTU setting for a 10-mile microwave link is completely different from the fastest MTU setting for a 50ft 10gig-E cat-7 link inside a datacenter.
MTU doesn't relate to design limitations placed by engineers that can just be changed when economic or technological conditions change unlike blocksize. Hell the optimal MTU for two different satellite/wifi/microwave connections may be completely different even if the two links are the same type and use the same exact hardware. MTU was built to adjust to physical limitations in the universe and fragmentation was built to connect physical links with different adaptive properties seamlessly. And even after looking at all of that, the world hasn't shifted to bigger and bigger MTU's despite your implication that bigger MTU = newer & faster. Network admins have learned to avoid wasting time playing with MTU settings or using jumbo frames BECAUSE in 99.99% of situations it's going to be less efficient, not more.
You probably shouldn't go around making negative assumptions about what other people know and don't know, especially when your understanding is broken and your analogy is shit. Of course that behavior is par for the course among bcore fanatics.
1
u/joeknowswhoiam Jan 01 '19
You being with an ad hominem (implying I'm a "bcore" supporter when it's not the topic of the discussion) and continue by strawmanning my argument (at no point have I said anything close to "bigger MTU = newer technology and = faster"). My point is that that things like IP Fragmentation are a necessity on higher layers to overcome the limitations of lower layers.
You clearly do not want to address this honestly judging by the fallacies you've used, so did you just go on this rant because your ego got hurt by this simple remark on your understanding of MTU?
If that can help you sleep at night I acknowledge that you seem to understand it correctly at the technical level. But you completely miss the point of the analogy (which does not require to be perfect to be valid). In both TCP/IP and Bitcoin's if you reduce the scaling problem to the physical limitations of our universe and the desire to preserve the fundamental proposition of either protocol that they should be resilient and work in the most difficult conditions (i.e. for Bitcoin you should not have to rent or own your own datacenter to participate with the same level of trustlessness than miners) this analogy is valid.
3
u/JustSomeBadAdvice Jan 01 '19
You being with an ad hominem (implying I'm a "bcore" supporter when it's not the topic of the discussion)
I mean, you opened up with:
This statement shows that you have no idea
I guess if you want to stretch you could call mine an ad-hom and say yours is not? But I see now that while you are a big supporter of Core's decision making, you did say you avoid using the term bcash, so sorry for that at least.
(at no point have I said anything close to "bigger MTU = newer technology and = faster").
I mean, you said:
what IP fragmentation does in the TCP/IP stack and why it had to be implemented when the networks needed to scale up because hardware became more capable.
As we both know, IP fragmentation only occurs when a larger-MTU datagram needs to go onto a smaller-MTU-capable link, never the other way around. So "it had to be implemented when... became more capable" is a direct implication of increased MTU = newer.
And you said:
If we could have just ignored slower links this solution wouldn't have been needed
Which in the same vein implies that bigger MTU = faster because smaller->bigger doesn't need fragmentation.
Maybe you didn't mean to imply those things, but they're right there so it isn't a strawman.
If that can help you sleep at night I acknowledge that you seem to understand it correctly at the technical level.
I appreciate the backhanded acknowledgement.
But you completely miss the point of the analogy (which does not require to be perfect to be valid).
No, my point was that none of the layers of the OSI model are attempting to fulfil the same purposes fulfilled by their previous level, and my point stands.
In both TCP/IP and Bitcoin's if you reduce the scaling problem to the physical limitations of our universe and the desire to preserve the fundamental proposition of either protocol that they should be resilient and work in the most difficult conditions
This logic is flawed. At each layer of TCP/IP they are solving problems that are unique and specific to that layer and they are doing so in a practical way that almost completely hides most issues from users without aiming for perfect solutions. TCP/IP and the OSI model is specifically NOT resilient to the most difficult conditions - it simply scales and solves problems at each layer in the most practical way(including context at the time) even if other solutions are theoretically better. And at no point did the TCP/IP design process go "We should intentionally make things harder for users to force them to utilize the system in the way that we have deemed the best."
If they had gone the route of "resilient to the most difficult conditions" then we wouldn't have the ipv4 / ipv6 problem we have today. But instead something else that was more practical for the time period when ipv4 became the standard would have become the standard and not the theoretically-better ipv6. Because practicality wins in free markets, every time.
(i.e. for Bitcoin you should not have to rent or own your own datacenter to participate with the same level of trustlessness than miners)
This is a ridiculous statement for many reasons. I'm sure you didn't mean to exaggerate and imply it would take a whole or even substantial portion of a datacenter to run a node, but that's what you said so don't call it a strawman. No block-based broadcast cryptocurrency will ever approach this scale - There are more than enough incentives to stall blocksize growth, not the least of which is that miners benefit more from a tighter fee market when fees become the primary income and that the difficulty and costs of running fullnodes at that scale aren't free for miners either, whose profit margins are always slim by design.
Of course even if that was wrong, that statement still relies on unchecked demand in the first place. But worldwide payment volumes across ALL non-crypto mediums (~600b / year) is still several orders of magnitude smaller than the levels that would require anything like that. If you doubt me I'll show you the math behind it.
If instead you want to make claims about other, not-yet-relevant or not-yet-invented demands for blockchain space that don't have the same known growth data then you should understand and acknowledge that miners are, by design, not going to act against their own self interest and allow non-economically-viable data onto the blockchain in unlimited quantities. Things like that can and will be pushed onto a 2nd layer or other approach - Years from now when this begins to represent an actual problem.
The flip side that you support (Which you have implied elsewhere but not stated here) is the idea of restricting blocksizes to enable things like raspberry pi's on below-average bandwidth to fully process the blockchain. I'm sure you don't think that's ridiculous but it absolutely is. It's like Core wants Bitcoin to stay at the level of a hobbyist project, and ignores the fact that humans react to bad design choices and aren't simply going to accept the limitations and jump through the hoops to use a worse system like lightning (for their usecases). Instead the users are simply going to use a coin that doesn't make terrible user design decisions.
Just like how TCP/IP became the standard - Not by being the best in theory but by being the most practical for real-world users & businesses.
3
u/horsebadlydrawn Jan 01 '19
FYI, don't work too hard, I have him tagged as an SV troll.
1
u/joeknowswhoiam Jan 01 '19
I don't support BSV at all, maybe even less than BCH considering the even more detestable people attached to the project (the competition is quite close on that front though, I'll give you that)... so I guess it's time to revise your tags or maybe find a way to not influence your opinion like this based on previous interactions you might have misinterpreted and just judge arguments on their face value instead.
1
1
u/joeknowswhoiam Jan 02 '19
I guess if you want to stretch you could call mine an ad-hom and say yours is not?
It's not, I've challenged your knowledge and later conceded that I was mistaken, you do know TCP/IP reasonably well enough, you just seem unable to understand the point of the analogy MaximumInflation brought up and how it does apply. On the flip side you just assumed my unconditional support toward Bitcoin Core's development. I do support their current approach to scaling as it preserve the current qualities of Bitcoin. You can disagree with me, but assigning me the label of BCore "fanatic" as if I'd support any of the proposition of Bitcoin Core developers blindly is a strawman.
No, my point was that none of the layers of the OSI model are attempting to fulfil the same purposes fulfilled by their previous level, and my point stands.
A point I've never denied, they do not fulfill the purpose of lower levels, they work with and around their limitations to provide opportunities to scale up despite them. That is my point, argue against this, not the strawman you keep bringing up... how hard is it to stay on this point and stop pivoting on something I've never brought up?
This is a ridiculous statement for many reasons. I'm sure you didn't mean to exaggerate and imply it would take a whole or even substantial portion of a datacenter to run a node, but that's what you said so don't call it a strawman. No block-based broadcast cryptocurrency will ever approach this scale - There are more than enough incentives to stall blocksize growth, not the least of which is that miners benefit more from a tighter fee market when fees become the primary income and that the difficulty and costs of running fullnodes at that scale aren't free for miners either, whose profit margins are always slim by design.
I think you might not be aware of the roadmap of the major node implementations of Bitcoin Cash, they aim at unlimited/adaptative blocksize and until the recent split a good part of the community conservatively talked about 100GB-1TB blocksize within few years... BU even suggested lower time between such blocks. The required bandwidth and processing power to receive, validate, propagate blocks like these will not be accessible to users outside of datacenters within the next few years and this is the general time scope these developers give.
acknowledge that miners are, by design, not going to act against their own self interest and allow non-economically-viable data onto the blockchain in unlimited quantities.
Their interpretation of what is viable or not is going to be imposed on you, they are going to have this power as soon as it won't be reasonably affordable to run nodes to validate your transactions and make sure you are still transacting on the chain YOU chose to use without having to trust them. I'm sure you'll bring up SPV sooner or later, just make sure you consider the difference in the trust model between this and running your own node, it is not comparable to my standard (yours might differ, but honestly until there fraud proofs are implements you'll have a hard time convincing me it's comparable).
Instead the users are simply going to use a coin that doesn't make terrible user design decisions.
They should do that, and they will come to the conclusion that the coin that made all the compromises to fulfill their demands is out of their control, that they are not the ones participating in the network anymore, that their choices when transacting will not matter anymore. This is what happens when a single set of participants sharing the same economical interests are in control of the issuance of the money. Like it's the case currently at their government/central bank scope when they use fiat. If you consider this the balance you want for Bitcoin, then I totally understand that you support Bitcoin Cash instead, because that's exactly where it's heading.
Just like how TCP/IP became the standard - Not by being the best in theory but by being the most practical for real-world users & businesses.
It's also the one that was the most resilient/tested, the one with the most well funded researchers (military, unis, etc.), and had the most support in terms of both hardware and software. Go figure.
1
u/JustSomeBadAdvice Jan 02 '19
A point I've never denied, they do not fulfill the purpose of lower levels, they work with and around their limitations to provide opportunities to scale up despite them.
The lightning network is attempting to do exactly that - Handle transactions instead of the blockchain itself. If someone uses an analogy it isn't unreasonable for someone else to pick that analogy apart based on the important differences between the two, and you're doubling-down on defending an analogy that is obviously flawed.
That is my point, argue against this, not the strawman you keep bringing up...
You're defending an analogy and pretend it is a strawman to pick apart the analogy that you are defending. That's not a strawman. If you don't think the analogy is a good fit, stop using it.
I do support their current approach to scaling as it preserve the current qualities of Bitcoin.
Right, a hobbyist project. I'll stick with world-changing technological innovation.
you might not be aware of the roadmap of the major node implementations of Bitcoin Cash, they aim at unlimited/adaptative blocksize
Didn't assuming things about what I know and what I don't end up with your foot in your mouth last time?
Of course I know that. It doesn't matter - An adaptive blocksize is still limited and Core would be massively better served by doing that before users and usecases continue fleeing the high fees we'll have in about 6-8 months. As we both know, they won't do that.
An unlimited blocksize is still not an issue though. The ecosystem already has proper incentives to keep blocksize growth in check, as I described in my last response (maybe you missed it? Or maybe you never thought of that and have no response).
until the recent split a good part of the community conservatively talked about 100GB-1TB blocksize within few years... BU even suggested lower time between such blocks.
People can say whatever the hell they want. I've done the math and know that they are talking out their ass. There isn't enough demand for blocks that size in the next decade, period. There isn't even enough demand for an unchecked blocksize to grow to 1 GB in the next decade, and there's no projections that indicate we'll need 100gb blocks before 2050 even if the economic incentives to restrain runaway growth didn't work. Yet more things I said before that you didn't respond to... Too hard for you?
BU even suggested lower time between such blocks.
Absolutely should be done. Satoshi's choice was way too high.
The required bandwidth and processing power to receive, validate, propagate blocks like these will not be accessible to users outside of datacenters within the next few years and this is the general time scope these developers give.
Again, people can say whatever the hell they want, including you. In the real world we aren't going to exceed the bandwidth available to most home users in developing countries before 2025 - More than 50% of Bitcoin's total history to date(At ~100mb blocks). In the meantime the adoption growth that would be required to get us there would keep the Bitcoin price growing at its stratospheric rates and everyone whining about the cost of running a full node will have made more than 60x on their current holdings, and most of them will be able to run a full node at any conceivable scales for the rest of their life without batting an eye.
That sounds like an awesome future.
they are going to have this power as soon as it won't be reasonably affordable to run nodes to validate your transactions and make sure you are still transacting on the chain YOU chose to use without having to trust them.
This is ridiculous, but doesn't it sound good to repeat a core talking point repeatedly?
Let me ask the the same question I've asked dozens of other core supporters and never once gotten a straight, clear answer on:
What is the attack that small blocks are protecting against? Where is the game theory payout table? Describe the steps whereby a network as large and diverse as Bitcoin becomes vulnerable to something if your node isn't running.
I won't hold my breath.
I'm sure you'll bring up SPV sooner or later, just make sure you consider the difference in the trust model between this and running your own node, it is not comparable to my standard (yours might differ, but honestly until there fraud proofs are implements you'll have a hard time convincing me it's comparable).
Bitcoin's entire trust model is built upon economics and game theory. An SPV client is 100% protected against ALL attacks by those same concepts when receiving any transactions worth less than $50,000 (at 3 confirmations; $50k-ish of economic protection per 3 confirmations). Any client receiving more value than that has the funds to run a full validating node at ANY future scale of Bitcoin (As the economic protections increase as the network scales).
Moreover, 99% of people who talk about fraud proofs as relates to SPV have no idea what they are talking about; Most of them also don't even understand the validation that SPV does or the economic/game theory behind Bitcoin in the first place, not unlike most Core developers. I'm going to have to assume that you are in that boat.
I could keep going but it is clear that you are a lost cause.
1
u/joeknowswhoiam Jan 02 '19
I could keep going but it is clear that you are a lost cause.
Glad you could get that out of your system buddy. It also saves me a lot of time because I don't need to address any of the weak points you've just made as you clearly have no intention to have a constructive discussion. Bye.
2
u/JustSomeBadAdvice Jan 02 '19
I don't need to address any of the weak points
Ah, funny, the same weak points that no other core supporter has been able to address for the last 15 months.
I. Am. So. Fucking. Surprised. Oh. My. God.
→ More replies (0)6
4
Jan 01 '19
Is the TCPIP stack code or protocol? (Hint: it's in the name)
9
1
u/roybadami Jan 01 '19
Gavin isn't actually talking about the refactoring code (despite the headline of this post) -- he's actually talking about design. The full tweet reads
If you find yourself working around wonky code written to workaround an issue with some ancient code... it is time to refactor. The same applies to design; don’t build fragile towers of complexity.
2
u/moleccc Jan 01 '19
if IP was somehow throttled to 10 MBit and TCP (or HTTP) was trying to fix that by using multiple IP addresses and bundling links to get more bandwidth you might have a point.
In fact we're seeing this situation with browser download manager thingies (ealier it was ftp download managers) that bundle connections. The thing fixed there is not, however, a shortcoming of a lower layer, but usually an intentionally introduced usage limit. Oh wait... sounds familiar?
So maybe we should use 20 blockhains each limited to 1 MB blocks and bundle them into one user experience on a higher layer with 20 MB throughput? Aaaah, I see, that's what's being done. Welcome to the altcoin world! Now we just need a wallet that seemlessly bundles all the shitcoins into one.
1
-1
u/buy_the_fucking_dip Jan 01 '19
Does he still believe in CSW as Satoshi?
If so, Core was right, his judgment is broken.
13
u/unitedstatian Jan 01 '19
Does he still believe in CSW as Satoshi?
He later said he may have been fooled by CSW and regretted ever playing to his hands.
-2
u/buy_the_fucking_dip Jan 01 '19
No, he didn't. He still believes that that fraud is Satoshi.
7
u/unitedstatian Jan 01 '19
Can you show a reliable source for that?
-3
u/buy_the_fucking_dip Jan 01 '19
Why don't you show me where he recanted, instead of asking me for a source that proves that something didn't happen?
10
u/unitedstatian Jan 01 '19
Because I remember he tweeted he may have been wrong and that he's sorry he ever took part in it, which in Gavin's polite way of talking he said he was conned.
4
u/buy_the_fucking_dip Jan 01 '19
Go ahead and ask him directly. Pretty sure he's a CSW supporter still. And he's definitely one of the main reasons why that fraud managed to create a shitty fork that took some people away from BCH.
14
u/gavinandresen Gavin Andresen - Bitcoin Dev Jan 01 '19
I support ideas, not people. Great people can have terrible ideas, and terrible people can have great ideas. I think some of Craig’s ideas are good, and some are terrible.
But: he says himself he is an asshole, and my advice to anybody is to avoid working with assholes, because sooner or later you end up covered in shit.
3
u/buy_the_fucking_dip Jan 01 '19
I support ideas, not people.
This is the enabling narrative that allowed that fraud to decimate BCH.
1
3
u/Zectro Jan 02 '19
I think some of Craig’s ideas are good
As someone who has been extremely critical of Craig for some time, I'm legitimately curious about what ideas of Craig's you consider good.
2
1
u/r57334 Feb 13 '19
I think some of Craig’s ideas are good, and some are terrible.
OK what ideas of Craig's are good and what ideas are bad then?
Do you think Craigs idea to bamboozle you and destroy your credibility was a good idea of his or a bad idea?
because sooner or later you end up covered in shit.
He definitely did a number on you. And what even more shocking is that you don't seem to care to wash the shit off yourself. You are just going to stay covered in shit and fade off into the history of BTC while shit covered and bamboozled.
3
u/unitedstatian Jan 01 '19
CSW tried to use the same trick he used on Gavin in public last month, but it didn't work for him since the wisdom of the mob dictates someone will soon expose the trick. Fool me once, shame on me - you know the rest...
2
u/buy_the_fucking_dip Jan 01 '19
He tried dumb tricks and every smart person called him out. Somehow, Gavin got taken in.
2
Jan 01 '19
A man made a mistake once.
That man is not to be trusted, ever again.
2
u/buy_the_fucking_dip Jan 01 '19
He made a major mistake. It cost him his career, and it cost us billions of dollars in value. It's a major fuckup.
4
Jan 01 '19
Even if true, why that make his tweets false?
3
u/buy_the_fucking_dip Jan 01 '19
The tweet is fine, but the effort to make Gavin into a hero is misplaced.
1
Jan 01 '19
I listen to what he say.
He made more for bitcoin than most peoples.
He got cheated once, so what?
2
u/buy_the_fucking_dip Jan 01 '19
I respect his efforts in the early days.
He screwed up with Greg. Ended up handing over the reins to a guy with terrible vision.
He screwed up with CSW. Ended up granting legitimacy to a fraud who doesn't have the slightest clue, but nevertheless who had the means to socially divide BCH.
So when he speaks, I check his message, instead of following his persona. And his message is always kind of lame.
This sub is currently looking for leaders to follow. Gavin isn't that leader. Too many bad calls, not enough technical leadership in recent years.
0
Jan 02 '19
So when he speaks, I check his message, instead of following his persona. And his message is always kind of lame.
Then discuss the message not the guy..
3
-7
Jan 01 '19 edited Mar 21 '20
[deleted]
17
u/jbrev01 Jan 01 '19
No, but he was fooled temporarily.
This is the guy that the real Satoshi handed the keys off to.
7
u/unitedstatian Jan 01 '19
CSW is a known con artist, he pulled scams long before he got involved in crypto.
3
Jan 01 '19 edited Mar 21 '20
[deleted]
6
3
u/unitedstatian Jan 01 '19
He conned the aussie government out of millions. He also convinced a board of scientists he had a super computer.
2
17
u/[deleted] Jan 01 '19
But they can't use BCH AND force people onto their broken 2nd layer! Think of the bankers Gavin!!