pull down to refresh
@leaf
stacking since: #495061
0 sats \ 0 replies \ @leaf OP 16 Oct \ on: Interview with Bob Colwell, former chief IA-32 architect architect at Intel devs
Also in mp3 here: https://www.sigmicro.org/resources/oralhistories.php
The whole thing is full of wisdom, but this passage came to mind recently, with the whole "spam" thing.
I had many opportunities at Intel to go to my boss and say I've been asked to do this feature by marketing for perfectly good reasons, but after we evaluated this technically it's my conclusion that you’re asking to inject too much risk into this project. Or the return on that investment isn’t high enough to warrant that much risk. And so I'm going to argue against it and the marketing guys are going to scream and call us idiots and say you didn't understand what we said. I don't know how many times I prevailed on that, but at least I had the terms to couch it in.Looking back at it I think we did a decent job overall of hitting those compromises. Those were the hardest ones. It's easy to go to your boss and say they ask for this, we looked at it and we'll put it in. And it isn't going to cost you anything. Who wouldn’t love that? If you say, well, we're going to put it in but it's going to cost you 3 percent of the die, now all the sudden it's got a real price tag and the boss goes, "oh, I don't know. This hurts. Can you please make it 0?". Er, no. We often had those discussions. Who wouldn't want something for free? Anytime the discussion hinged around risk it got awkward really fast. Because engineers are quantifiers. Tell me a percentage then I can deal with it but if you just say I want to stick a feature in it that will make it this much faster, you can quantify that, it will cost this much in schedule, you can quantify that. It will use this much die size, I can quantify that. I get to sit and say, well wait a minute, it's going to be awfully risky in terms of complexity. There might be some bugs. I don't want to do it. You can quantify your answer. I can't quantify mine. Now how do I trade those off?Those are very difficult conversations to have. I was lucky that people like Albert Yu, my executive VP at Intel, would sometimes say look, I don't completely understand the argument you're making, for good reasons because you're basing them on things that inside the chip that I can't possibly know, and you're comparing other things that I do know and I know the price tag of. But in a sense you're asking me to trust your intuition, because I can't do it myself. I can't do it based on what I know. I said, I agree with you. That's the right way to view this. But, if the day comes that you can't trust my intuition as your chief architect you need to fire me and find somebody else. Because I don't think there's another way to do this.
If storage space is a concern, wouldn't utxo snapshots be a better solution? Then a new node doesn't need all blocks since the genesis block.
Can someone explain the Core vs Knots debate in basic terms I can understand?
I'd just ignore it. In my opinion, bitcoin is fine regardless.
If you're the type of person who cannot use the internet without wanting to understanding the details like tcp/ip, bgp, etc., then maybe it's something you'd be interested in exploring.
I think it’s that the two sides trying to save the gold standard actually had other motives and it would have been better to just stick with the gold standard as it was.
I don't really understand it - and am happy to be corrected - but I think garbled circuits may change what is possible even if bitcoin stuck to its "gold standard".
The latest continuous divide within the Bitcoin community may look like another technical battle. But does it point to something deeper?
By expanding the Op_Return size (protocol inflation), are we not reintroducing the debasement Satoshi rooted out?
How does someone throwing out a particular transactions from their node's mempool for ~10 minutes before that same transaction is mined in block represent "protocol inflation"? What does "protocol inflation" even mean?
Even if I believed "spam" was some kind of existential threat to bitcoin, policy wouldn't be the way to fight it. The way to fight it would be through a consensus change. The only argument I've seen for why they don't push for consensus change is that it wouldn't happen - and yes, it wouldn't happen, because the real stakeholders understand that's a dumb change to make.
Every so often, I try to find an argument for why bitcoin doesn't work or isn't what I think it is. If such an argument exists, I want to know it. Yet every time I've done this, I've only found misunderstandings. But I continue to periodically look for such an argument in case someone has a new argument I haven't considered.
The same thing happens when I look at knots runner arguments: that Core is a unified group of devs that are somehow all compromised and/or that they're trying to sneak in a dangerous change and/or they're all lefties. All I've seen is people that haven't read any communications between core devs, don't understand the difference between policy and consensus, or don't understand the cat-and-mouse game that results if you try to block arbitrary data.
No matter how many times those arguments are refuted, those same people outright deny the truth and continue posting the same bullshit. A refuted point, frequently repeated by many (supposedly authoritative) people, doesn't somehow make that point true.
At the risk of falling foul of Godwin's law, you might as well take the Nazi's "big lie", substitute Jews for Core devs, and you'll find the strategy is exactly the same.
The state exploits illogical ignorance like yours to push its propaganda via "well respected experts"
I agree that authority is a bad way to establish truth. I'm not more likely to consider someone's arguments because they're a "well respected expert".
You cannot rely on a positive/negative bias towards the messenger if you expect to be a free thinker in this age of information war.
My approach is a direct response of the problem of having too much information than is possible to process. Whether it's effective is hard to measure.
I think the best we can do is hold our beliefs tentatively and seek out different opinions and be open to new arguments/perspectives.
But that's not to be confused with "explore every position that differs to me". As I said, that is impossible. So when I consider a position counter to my own, I need to maximise the chance I'm going to get some utiliity out of that time.
An ad hominem would be if I said "Kratter is wrong about bitcoin because he's a really bad person!". I'm not attacking his position based on his character or motivations.
What I'm doing is not considering his opinion at all. He could be right, but I won't know because I've got better places to spend my time than considering all the things that cascade out of his piss-stream mouth.
My general view is that, in an ideal world, people would focus on the topic at hand and explore all available arguments in depth, regardless of their source.
Unfortunately, with the amount of arguments on any topic, and the amount of topics to explore, this usually isn't feasible. So we need to reduce the number of arguments we will explore to a manageable amount. We can use the trustworthiness of the source to achieve this.
That opens the possibility of dismissing a valid argument based on the source, but I believe it is necessary given the unmanagable amount of arguments in total. In a single human lifetime, it impossible to explore everything.
There are strategies to avoid falsehoods when doing this, like occasionally going deep on a single topic to better identify the trustworthy sources, or once in a while randomly exploring a source you would have otherwise dismissed.
In summary, I feel very comfortable dismissing Kratters opinions on bitcoin based on his crazy-ass views on other topics. There are plenty of better sources for arguments counter to my beliefs without having to turn to a nutjob like Kratter.
How about this one on mental telepathy https://m.youtube.com/watch?v=fWyxzoFWAzs
Or this one about how JFK shot down a UFO https://m.youtube.com/watch?v=6syCI3yKH6Q
I also think this. It's is essentially impossible to predict all the changes that bitcoin will bring. And some of them are bound to be profoundly negative, even if it ends up a net benefit overall.
I believe early internet enthusiasts also claimed similar things to "fix the world". The internet has brought so many good things. But now we have propaganga on steroids and a huge loss of privacy. People are losing their minds due to information overload.
Many bitcoiners, imo, like early internet adopters, tend to be dogmatic and look at things through rose-tinted glasses. Bitcoiner's deeper consideration of the topic doesn't prevent outsiders recognising their common tendency to gloss over the potential negatives.
Nobody seems to have a problem accepting that there is a knowledge asymmetry between bitcoiners and nocoiners. Bitcoiners tend to accept that nocoiners, for whatever reason, don't get it. I imagine that many nocoiners have complained that bitcoiners are arrogant and are treating nocoiners as dumb.
I think I could uncontroversially use this quote in relation to nocoiners here: "It requires wisdom to understand wisdom: the music is nothing if the audience is deaf."
What some bitcoiners don't get, in my opinion, is there is knowledge asymmetry between bitcoiners themselves. Specifically, between the technical and nontechnical.
Many nontechnical people think they know more than they do, or think the little insight they do have makes them qualified on technical issues. The hard truth is it doesn't.
In my opinion, people generally underestimate the amount of knowledge required to do something like bitcoin development. It is gargantuan. Without that, you cannot understand the technical discussion, distinguish the strong arguments from the weak. And that assumes your mum popped enough tylenol when pregnant to give you the brain required.
So I say again, but about nontechnical bitcoiners: "It requires wisdom to understand wisdom: the music is nothing if the audience is deaf."
The good news is that I don't think people need to. There is a wide variety of bitcoin devs from different backgrounds with different views.
If a genuine questionable change was being pushed, we can rely on a subset of them (i.e. more than one) to raise the alarm.
This is why I'd say we want as many devs as possible: lots of funding, and reduce the pressures and demands on them so they can speak their minds. If bitcoin development is insufferable, you'll get less devs, less ethical devs, making a bad change less likely to get called out.
I'll grant you that this all depends on how it is implemented. Hypothetically, it could just be a service - I sincerely doubt that's what it would be.
For one thing, with SPV clients, I think this service essentially already exists. If someone is willing to trust someone else to validate blocks because they're squeamish about block data, they can just connect to a few nodes they trust with a light client.
There is no need for some complex solution where it's difficult to determine the risks and long-term consequences. Unless you wanted to muddy the waters and confuse the nontechnical. I can see the arguments now: "It is trustless though! Trust us!"
My other point is Why is this service suddenly required now? It's long been known there is illegal data in blocks. Nobody seemed to care a year ago. And with all the financial infrastructure etc. built up around bitcoin, I doubt anyone will.
So why is this narrative being amplified now? If we step back and interpret this in the full context of the knots drama, it seems fairly obvious to me. Ultimately, this is about control. The knots crew aren't getting the code changes they want, and are willing to create a false crisis, slander all other bitcoin devs, roll out lawyers, and more, if they think it'll give them the control they want.
I am not convinced.
The mere consideration of such a change where a small group are given any such power should be absolutely and utterly rejected by anyone interested in keeping bitcoin trustless and uncensorable.
There is a such an obvious slippery slope from supposedly trusted individuals removing illegal material to outright censorship of transactions they don't like.
And then there is the ocean lawyer contacting mining pools, which Adam Back corroborates https://x.com/adam3us/status/1971330468961542213
Few people seem to be discussing that part which is arguably worse...
I think the whistleblower was right to leak these messages and reveal what is obviously an attack on bitcoin.
People that don't want to discern what they're downloading would then be less likely to download changes they don't need. That's good.
I'd say a loss in trust in bitcoin due to issues will be a bigger factor, even if those issues were isolated.
Core has multiple major versions per year, that's worse than many js frameworks.
That's not a metric I'd judge a project's coding practices by. I think something like the number of bugs and their severity would be better.
the actual prescription is to prevent a politburo from impersonating Bitcoin
I doubt that would happen. They might fool the gullible, but few else, imo. Certainly not big miners or businesses who would have a lot to lose if bitcoin failed.
People just download blindly with zero discernment because the repo is trusted.
They trust that others are looking at the code, and you get that with one main repo.
It's unrealistic to expect most people to start doing code review and verifying the code for themselves.
but it's changed more like a fledgling javascript framework
As I understand it, PRs are often in review for months or even years, if thet get merged at all. That's hardly like the javascript community.
Regardless, if there were multiple code forks, I'd expect that to reduce code security/reliability, not increase it. The eyeballs would be split between repos and there would be more chance of a bug or questionable change getting through.
I think the worst case scenario is a new repository gets the same mind-share
I think the community will always want a repo with a lot of eyes on it, to manage PRs and ensure changes are well reviewed.
If you had loads of code forks, it would be tough to know what has and hasn't been thoroughly reviewed. That won't cut it on a project that requires absolute reliability.