How many people have committed such egregious crimes using blockchains that it is literally worse to spend your entire life in jail than it is to give up your Bitcoins? That scenario you've presented makes absolutely no sense to me.
But anyway, it's still entirely wrong because they can still just catch you using traditional means. Like catching you on tape admitting you stole the Bitcoins, or getting a video of you doing it, or getting credible witnesses to say that you did it. Or similarly, to retrieve the stolen coins just get a video of your keyboard while you type the pass phrase to the wallet, or just liquidate the rest of your assets into dollars and pay back the victim that way... Like the whole thing just makes no sense. Even if it did actually work it would still be terrible because the system you describe means that if you get your bitcoins stolen and you catch the thief and he admits he did it and then intentionally goes to jail to avoid having to give the tokens back so they just sit there unused in the wallet just to spite you... you can literally never get them back. Why would anyone actually want that??? I am honestly trying not to make this so outlandish but this is entirely what you just described. It's completely ridiculous.
The only thing this accomplishes is if you are trying to destroy money and make someone suffer by taking destructive actions... but like, if you are really an evil and petty criminal person you can also just do that with anything else? Like, rob them at gunpoint and set their cash on fire? Or slash their car tires? No one needs Bitcoins just to be an asshole, you can see that every day on this planet...
>the right to examine products and discuss what you learn is really really important and is the basis of security research
I hate to push back on you (of all people) for this, but no it's actually not. You are talking too much with your hacker hat on and not enough with your legal hat on. There is quite a difference between accredited security firms doing responsible security research, and random unaffiliated parties with shifting and conflicting motivations doing "security research". That angle is a losing angle and it's not because these companies did anything, it's because it is actually a fallacious and bad meme that has propagated around forever in hacker circles, seemingly for no other reason than that it is fun to think about it.
In my opinion, if you follow that "right" to its legal and technical conclusion, you will end up with the "right" of corporate security firms to do research. That's it. I don't mean to be all doom and gloom though. You are right that the idea of "right to repair" is a much broader thing that makes a much more compelling case for any kind of consumer protection angle.
I'm not sure what you are arguing :(... is your premise that it is sufficient for only "accredited" (is that even a thing? I didn't know that was a thing) security research firms that are, I guess, hired by the company that is selling the product for the world to be safe? As that definitely doesn't seem to be true in practice, and puts a LOT of power in some extremely biased hands :(. It also doesn't, from my understanding, match the intention of the laws either... the weakest part of the Green case (which is what was referenced and which is almost annoyingly-narrowly about security research being published in book form, and so sidesteps any confusion we might be having here with respect to my personal agendas that involve "jailbreaking")--as far as I can tell, as a non-lawyer who spends way too much time talking to the lawyers--is that the DOJ actually came out during the hearing to say they don't see anything wrong with the activity in the first place ;P. I'm thereby really confused that you seem to think this is somehow, I guess, illegal currently? Cause like, AFAIK, it isn't: the issue at hand is whether there is a chilling effect being caused by Section 1201's anti-trafficking provisions on someone's first amendment right to explain not only that something is insecure but in exactly what way it is insecure (as I, for example, often do in my post-mortems: see my articles on Optimism or Master Key, etc.) when those exploits happen to affect an "effective" (lol: I hate that wording) technological measure protecting someone's copyright, as, in the US, we tend to be pretty adamant about reserving the right to publish information.
If we are offering absolutist opinions, I would like to offer a counterpoint.
>I've got macros to do automatic bounds checking. I've got RAII and stack traces. I've got structured concurrency, which will give the same capabilities as the Rust borrow checker if you adjust your coding style. And all this in portable C11.
You can do this all in C but it is an absolute nightmare. Every large C program grows some strange bespoke and incompatible versions of all that stuff at some point. And they're all a pain to use because none of it is idiomatic to the language. It's seriously awful. Things like the Linux kernel are the worst offenders. I will be happy when the C language finally reaches the end of its miserable, slow, agonizing death.
The argument you are missing: Your position is bespoke and incompatible. You don't use idioms in your C code. You use idiolect. Thus, you exist in your own universe and are a party of one.
And the clue was something you might not expect...
I programmed C++ for five years, and C for over ten years before that. I don't know rust, but I followed this discussion with great interest.
One of the topics that came up several times was being able to identify who wrote what C++ code based upon their choice of language subset without using blame.
In the pro-rust arguments and C++ counter-arguments and rust counter-counter-arguments and C++ counter-counter-counter arguments in discussions above yours, I was pleasantly surprised to see that grandfather comments were rarely (never?) the same author. At least the rust and C++ arguments were made by different people sharing some sort of group mentality.
Then I hit your thread and saw the grandchild comment: "I understand you think it's awful, but I do like it. Everyone has their preference." and I was like: "Okay. I bet grandparent is also ghoward."
The simple fact that no one is chiming in to grandchild your arguments is the point that you're missing. In fact, the entire subthreads you've spawned involve basically ghoward defending ghoward's position.
It's nice when other people can take over your work. That's what we're after.
I prefer to finish software. [1] I get it to where it needs to be and put it in maintenance mode.
I don't accept outside contributions. [2]
I prefer to work alone to keep the scope of my software manageable and to reduce communication overhead. And to avoid working with people. People are too complicated.
I obsessively document my software. [3]
I comment all of my code. I wrote design documents and requirements lists. I write documents about the source code, its concepts, and how to understand and read it. I turn my code into something that can be studied and used far into the future.
Most programmers are not like Donald Knuth. But there are a few that are. I'm one of them.
Please let me be like that. Don't make me work like everyone else because I can't; I've tried.
I'm fine if you all want to use Rust. I even said to use it by default in my first post.
You all seem unhappy that I do not want to use Rust. I don't get why.
I'm defending my position because it appears you all think it's not acceptable. You're wrong.
I was going to start this reply by saying "I am not necessarily defending / supporting ghoward's position", but after I read his whole reply, I realize I am.
I enjoy writing C (more than C++); I do not find it awful. If you cannot accept that, then there is nothing I can say to change your mind. What I don't understand is this atavistic obsession that "everyone must migrate to rust now", and "C is so dangerous in can explode in your hands while you are sleeping".
Please, go forth and multiply, and use rust to your heart's content. But be more open minded to the fact that there are people who like, enjoy or even love using C. As for me, I admit I have gone from interested in rust, to neutral, to an active dislike, because this narrow-mindedness some of its proponents show.
You do you. Maybe it isn't said often enough, but each side (Rust-lovers and Rust-haters) has to be confident enough to allow others to disagree.
However, let's be serious, the anti-Rust crowd has not been some bastion of high-minded virtue with its flimsy arguments ("Just write better code..." and "Modern C++ doesn't have these issues..."), mole hill matters of taste ("Egads! The syntax!"), drive by hype hate, and unexplained red-herring cul de sacs ("I doesn't have a spec!" Okay, why do you need a spec?).
> I'm defending my position because it appears you all think it's not acceptable. You're wrong.
I'm not sure this and sentiments like it represent something less narrow-minded? Most of the time, it seems kinda resentful?
Because it is. And it is because you all say things that imply people like me are terrible, awful, evil, no-good, very bad people for not using Rust.
We are not. We just have different preferences.
You all have also implied that we are negligent for using C. I don't know about others, but I have not been.
That's why I have the challenge to break a release of my `bc`. I actually have not been negligent because I do put in the effort required to eliminate memory bugs as much as possible.
Until the RESF refrains from implying we are bad or negligent for not using Rust, we will be resentful.
> You all have also implied that we are negligent for using C. I don't know about others, but I have not been.
I’m sorry that people have implied that, but I feel most of the time when Rust people say languages like C should be retired or deprecated, are doing so because your skill and attention to detail does not scale.
Maybe you personally have advanced enough to write safe code, and you have the requisite skills and insight to avoid any and all memory bugs, such that your C code is just as safe as what Rust would compile. That’s great.
But there’s always someone starting out and they will not have your skills. They will make the use after free, null pointer deference, buffer overflows, and other issues that the C language not only allow but encourage.
So the question is: how long do we tolerate new programmers making these mistakes in production code, leading to bugs and exploits for all, when other languages are readily available that would have caught those mistakes before reaching production? C was released 50 years ago, and in the intervening time a lot has been learned about how to write programs, and what language features are desirable in enforcing those practices. We also learned that when practiced aren’t enforced, they aren’t followed. So “just write modern c++”, which is espoused throughout this thread, doesn’t work to make c++ code safer, because it’s not enforced. Not taking advantage of those lessons learned seems like folly, irrespective of how bug-free your particular C codebase is.
> I’m sorry that people have implied that, but I feel most of the time when Rust people say languages like C should be retired or deprecated, are doing so because your skill and attention to detail does not scale.
This is a fair argument.
On the other hand, I wish we had less software so that attention to detail did not need to scale.
For example, I run a Gentoo machine with the Awesome Window Manager and no systemd. The end result is less than 50 processes running after I login.
My machine is powerful, but if I were running Gnome, it would still feel laggy. With this minimal setup, my machine is snappy even when running an update and compiling Rust, Chrome, Firefox, or anything else. (I did have to make my update script renice Portage to the lowest priority to make that happen, but it works.)
Nevertheless, it is good when less attention to detail is needed.
I'm making my own C replacement, and I'm going to rewrite my current project in it when it's done. It will be about as safe as Rust, if not safer because it will not have async/await.
> Maybe you personally have advanced enough to write safe code, and you have the requisite skills and insight to avoid any and all memory bugs, such that your C code is just as safe as what Rust would compile. That’s great.
Thank you.
> But there’s always someone starting out and they will not have your skills. They will make the use after free, null pointer deference, buffer overflows, and other issues that the C language not only allow but encourage.
Yes, they will. But I view this argument as equivalent to "roll your own crypto."
If no one actually rolls their own crypto, then we as an industry will lose the ability to do so, even when we need to. If nobody uses C, then we as an industry will lose the ability to do so, even when we need to.
When I started writing `bc`, I sucked at C. `bc` was so full of security holes.
So what I did was spend enormous amounts of time on the test suite and asserts and then hooked those up with sanitizers and Valgrind. Patterns of bugs repeated over and over.
But I eventually got to a point where I started to get good. I didn't release a 1.0 before that point; I waited until I was good and had done thorough checks with as many tools as I could learn.
I'm currently learning and implementing crypto. I am following the same process, except that I'll add in professional code audits by actual cryptographers, which I have to pass before I release the code.
I'm doing this because someone has to.
> So the question is: how long do we tolerate new programmers making these mistakes in production code, leading to bugs and exploits for all, when other languages are readily available that would have caught those mistakes before reaching production?
We should not tolerate this in production code, but this is a failure of the industry. Why are beginners writing production code in the first place?
This industry grew too fast for its own good. It would have been better if it had had a master and apprentice model. The best programmers would be "masters" (in the sense of master and apprentice), and juniors would be apprentices who would write code under the master until the master thought them good enough to be journeymen (moving up from junior), and over time, such journeymen would themselves come to be recognized as masters, and the cycle would repeat.
If the industry does not do that, we may soon lose the ability to do things we need to do.
(Funnily enough, this is another argument for less software because there will be less people to write production software, and they'll all be good at it.)
> C was released 50 years ago, and in the intervening time a lot has been learned about how to write programs, and what language features are desirable in enforcing those practices. We also learned that when practiced aren’t enforced, they aren’t followed. So “just write modern c++”, which is espoused throughout this thread, doesn’t work to make c++ code safer, because it’s not enforced. Not taking advantage of those lessons learned seems like folly, irrespective of how bug-free your particular C codebase is.
Surprisingly, I agree with you that it's folly. I really do. In my original post, I ended it by saying
> But seriously, use Rust if it's available for your target platforms, and you have no other preference.
People really should do that, even though I don't like Rust.
All I was doing was just to remind everyone that there is a time and a place for C.
By the way, the reason I don't use Rust is because I'm pretty sure I would actually write buggier code in Rust than in C. The reason for this is async/await: I just can't get it. I mean, I do get it, but the rules seem too complicated for my brain to do as safely as I can do threads and locks.
I think I am one of those people for whom async/await is dangerous, just like there are those that just can't get Lisp or Haskell.
I say this so people know I'm not some great programmer; I have my weaknesses like everybody else.
So it would be folly for me personally to write Rust.
At the same time, yes, it is folly to write anything but Rust if it works for you.
> This industry grew too fast for its own good. It would have been better if it had had a master and apprentice model. The best programmers would be "masters" (in the sense of master and apprentice), and juniors would be apprentices who would write code under the master until the master thought them good enough to be journeymen (moving up from junior), and over time, such journeymen would themselves come to be recognized as masters, and the cycle would repeat.
I 1,000% agree with this perspective. I also actually suspect that some form of professional licensing and/or personal liability would benefit the industry greatly, in that it would give more power to engineers to decline to build software irresponsibly due to pressure from management. Obviously this would be wildly complicated and there would be (potentially intolerable) downsides, but I do wonder what things would look like if we could revoke the licenses of people who repeatedly exercise poor judgment, or if responsible engineers knew they had the backing of a professional organization when pushing back against management.
The irony isn't lost on me that elsewhere in this thread I said that nobody is coming after your software engineering license if you keep writing C :) And I do realize that would probably be a disastrous idea in practice. But in my mind it's great.
And while I do agree that the industry grew too fast for its own good, this is unfortunately the reality we live in. The need for software has exceeded both our ability to produce it reliably and our capacity for training qualified engineers. So we have countless junior developers writing production code without good mentors. And worse, I think we also have a terrifying number of "senior" engineers who are actually junior engineers with a lot of experience but trapped in a local maximum. I don't know how we fix this.
> By the way, the reason I don't use Rust is because I'm pretty sure I would actually write buggier code in Rust than in C. The reason for this is async/await: I just can't get it. I mean, I do get it, but the rules seem too complicated for my brain to do as safely as I can do threads and locks.
I "get" async/await but I… hate that it has to exist. I avoid it in all of my Rust projects. Partly because I don't want to use it, but also because I've never needed to solve a problem in a domain where it would have been invaluable. So just so you know, I've been writing Rust since right around 1.0 and I've been essentially able to just pretend it doesn't exist. I've never used it, but also I've never had to think about not using it if that makes sense.
> I 1,000% agree with this perspective. I also actually suspect that some form of professional licensing and/or personal liability would benefit the industry greatly, in that it would give more power to engineers to decline to build software irresponsibly due to pressure from management.
I also 1,000% agree with this. In fact, if there is any activism I do within the industry, it's pushing for this.
> Obviously this would be wildly complicated and there would be (potentially intolerable) downsides, but I do wonder what things would look like if we could revoke the licenses of people who repeatedly exercise poor judgment, or if responsible engineers knew they had the backing of a professional organization when pushing back against management.
I don't think there would be any downside other than expensive software. But studies have shown that poor software is more expensive!
The one thing that would complicate it is Open Source, but I think that hobbyists should be allowed to practice and put code up with no vetting, just like an engineer might design a shed for his backyard and post it on a blog without his/her seal of approval.
However, if some company decides to use that shed/Open Source code in a project, that company's certified engineers/programmers should be required to vet it the same as they would do for their own code.
And as for the gatekeeping of certification, I think uncertified programmers should be allowed to program, but under the supervision of a certified programmer who accepts liability for their work because that chief programmer should be checking their work.
> The irony isn't lost on me that elsewhere in this thread I said that nobody is coming after your software engineering license if you keep writing C :)
Maybe a litte irony, but I would probably be harsher on myself than you would think.
I think there would probably be a certification for writing C, one for writing Rust, etc.
So I would not be allowed to program as a certified engineer for Rust, but I could probably be certified in C, even though the certification and standard of care for C would be much harder and have a higher bar, for obvious reasons.
I don't know what the industry would set the standard of care for C at, but I personally wouldn't set it lower than my personal standards. If it was set at that, then my license should not be taken away, even if I were paid to work on `bc`.
But if it was set higher, say at the level given to libcurl or SQLite, then yes, I should lose my license if I were working for pay on `bc`, unless I stepped up.
In addition, if I worked on `bc` for pay, my failure to prevent memory bugs in `bcl` recently (the one where Valgrind was not hooked into its tests properly) should, at the very least, put me in front of a licensure board to explain myself. My recent failure to prevent the double-free on `SIGINT` when running expressions should also put me in front of a licensure board to explain myself.
If any paying user had been caused trouble for those bugs (no one ran into them as far as I know), I should have to compensate them for the trouble and probably lose my license for negligence. I was extremely upset that I let those slip through.
So no, I shouldn't lose my license for using C, but there should be one for C, and I should have at least come close to losing it for the recent mistakes that I would consider near-negligence.
> And I do realize that would probably be a disastrous idea in practice. But in my mind it's great.
I want to hear why it might be a disastrous idea. I can't see how it would be because it would lead to less but better quality software, and if bad software actually costs more in the long run, it would actually save the industry money! So I fail to see how it would be disastrous.
Please enlighten me on this; I have to know the weaknesses.
> And while I do agree that the industry grew too fast for its own good, this is unfortunately the reality we live in. The need for software has exceeded both our ability to produce it reliably and our capacity for training qualified engineers. So we have countless junior developers writing production code without good mentors.
Yes, this is the reality. This is why I don't dismiss Rust even though I hate it.
> And worse, I think we also have a terrifying number of "senior" engineers who are actually junior engineers with a lot of experience but trapped in a local maximum.
I really don't want you to be right, but I think you are, and that terrifies me because something bad is going to happen. I don't know how we fix this.
However, the end result of that bad thing might actually be certification and standard of care, which wouldn't be a bad thing.
As they say, regulations are written in blood, and I think that's the only way to fix this.
It's just too bad that people will have to die before that happens. I mean, I thought the Boeing 737 MAX would be the wake-up call, but it wasn't. Sigh...
> I "get" async/await but I… hate that it has to exist. I avoid it in all of my Rust projects. Partly because I don't want to use it, but also because I've never needed to solve a problem in a domain where it would have been invaluable. So just so you know, I've been writing Rust since right around 1.0 and I've been essentially able to just pretend it doesn't exist. I've never used it, but also I've never had to think about not using it if that makes sense.
That makes a lot of sense, and I don't blame you.
It's too bad we had a misunderstanding at the beginning of our conversations about this because I think we would agree more than disagree on the direction the industry would go. Oh well; we got to a point where we cleared up the misunderstanding.
> I want to hear why it might be a disastrous idea. I can't see how it would be because it would lead to less but better quality software, and if bad software actually costs more in the long run, it would actually save the industry money! So I fail to see how it would be disastrous.
My answer to this is probably too large for a reply here, but TL;DR is that software engineering is an enormous, complex field. I do know that there are far more ways to do something like this wrong than there are ways to do it right, but I have no idea what would be the right way. Language-based licensing makes sense, but so does licensing for sub-fields like security-related areas (handling PII, cryptography, even different areas of cryptography), operating systems (Windows, macOS, Linux, *BSD, et al), and large frameworks (Hibernate, Rails, React, etc.). But I imagine in practice things would get real murky real quick.
And it's also something where it could easily become too onerous and impossible to develop software.
> I enjoy writing C (more than C++); I do not find it awful. If you cannot accept that, then there is nothing I can say to change your mind. What I don't understand is this atavistic obsession that "everyone must migrate to rust now"…
Nobody is saying this!
In the original tweet, Mark Russinovich said he thinks C and C++ should be deprecated. I believe if you asked him to elaborate on this, he would say he believes we should stop using them when possible. Not "must". "Should". And further, I suspect he'd clarify that he is imploring this of the industry as a whole, and not at the scale of individual developers.
People still write asm, and nobody is coming for their heads. We need people like that! And we will need people who are skilled in C for the far foreseeable future. But the time has come where there exist alternatives to C and C++ which are superior for a very large bulk of their remaining use-cases. He's not scolding individual engineers who choose to continue writing code in a language he enjoys. He's calling for the industry as a whole to recognize this new reality and move forward with the times.
Part of the issue though can be perceived psychological pressure, that can border on being coercive or even come off as intimidation. Kind of like all the "cool kids" are using X, and if you are not, then something must be wrong with you. And while Mark is probably not trying to purposefully create that kind of environment, remember there are powerful corporate interests involved, that probably wouldn't mind some intimidation or unnecessary peer pressure to promote their agenda.
If you take that angle then crypto will still never be a legitimate investment class either way, because all of it (including BTC and ETH and everything else) is a giant fraud predicated on the falsehood that it is "decentralized" and somehow that makes it unregulated. There is no other reason for it to exist. This is just another nail in the coffin, they can't lie about it anymore.
If crypto-land really wants to follow through on their lawless anarchist fantasies, then they should be even happier if the SEC bans all of it outright. Then they can all go back to their roots when the only thing bitcoin was used for was illegal black market drug transactions...
ETH is operating and trading with the US. It falls under US jurisdiction. The line of "we are not registered anywhere therefore we don't have to follow laws in any jurisdiction" is pretty weak and farcical. And sorry to be cheeky but... Have you seen some of the absurd claims and arguments crypto people make about the "infinite power" of crypto to somehow evade all laws and solve all social problems, while simultaneously making everyone rich just for holding some tokens? I wish I was making this up, or maybe I was just getting trolled...
I did read it and it is honestly not that complicated. The SEC is being generous here. They could make the argument even if there were no validators. But I hope this is the start of them shutting down the validators too.
US gov has a way of keeping certain things illegal that would otherwise take away employment and purpose of their own agencies. Just look at the DEA/"war on drugs".
>GNOME is probably worst DE imaginable. After 20 years, they still don't have thumbnails in filepicker and even dropped preview side pane in GTK4.
Really disappointing to see this very lazy and trite criticism upvoted. If you look in KDE Plasma or Sway, you can also find plenty of missing features and bugs. You can find those anywhere.
You might also want to note that the fantasy of being able to use the same protocol to drive the local display and also operate over a network, is long dead. It seems like a clever idea but it doesn't actually work. It ceased to be a thing entirely the moment wide area networks became popular. The local and remote cases are two completely different situations that need their own individual attention. Even when developing against X11 protocol you still have to consider this in modern times because the DRI extension is not available over the network.
Compare to a protocol like RDP which is extremely optimized for efficient and secure network operation, but is also way more complicated as a result, and it would be foolish to use it on a local display server.
You can make all the arguments you want but it won't do anything meaningful. If those 1000x people expressing opinions have the necessary domain expertise, and aren't just tossing out their feelings on what they think might be cool or might be nice in a perfect world, then they should start contributing to these projects and fixing the bugs.
I mean, I think it would be cool if my PC never crashed. Isn't it easy and fun to say things like that?
>and I'm not really interested in hearing that my own experience with it working well is a lie or some trick.
Your own experiences with it aren't a lie, but they're probably based around ignoring the last 20-30 years of advancements, and ignoring many actual statements from the X11 developers saying that it's bad for remoting.
>Wayland gives up some things
Well in the case of X11 fowarding, no it doesn't. That still works.
>Also, those of us who use non-mainstream window managers (such as Window Maker) are not interested in hearing that we should switch to some UI which doesn't support our workflow just because it's more fashionable these days.
By insisting on using these obscure, non-mainstream and under-maintained environments you are setting yourself up for an extraordinary amount of pain for very little benefit. The more time you spend avoiding the issue the harder it gets to figure out how to adapt your workflow to something else. I'm sure you understand that more deeply than anyone else here. So why keep up with the charade? It is not doing you any favors. At some point we have to let bad habits die.
But GNOME has zero reason to implement server side decorations in Wayland. All GNOME apps use client side decorations and have done so for years. The other major toolkits (Qt and Electron) have also added support for client side decorations. Legacy X apps are still able to use the X decorations. The only thing left is apps that were broken in Wayland in the first place.
Client side decorations are fine, but removing the option of server side decorations from app developers is stupid IMO. KDE and wlroots have this functionality.
Practically, for small apps that don't really have their own style (or games that are just one big opengl window) it's much better to rely on the window manager to provide a titlebar that somewhat fit in with the rest of the system. This is what users expect when coming from Windows or macOS.
Instead, apps like kitty just provide a godawful stopgap titlebar for GNOME users, because implementing good CSD is outside the scope of the project.
But anyway, it's still entirely wrong because they can still just catch you using traditional means. Like catching you on tape admitting you stole the Bitcoins, or getting a video of you doing it, or getting credible witnesses to say that you did it. Or similarly, to retrieve the stolen coins just get a video of your keyboard while you type the pass phrase to the wallet, or just liquidate the rest of your assets into dollars and pay back the victim that way... Like the whole thing just makes no sense. Even if it did actually work it would still be terrible because the system you describe means that if you get your bitcoins stolen and you catch the thief and he admits he did it and then intentionally goes to jail to avoid having to give the tokens back so they just sit there unused in the wallet just to spite you... you can literally never get them back. Why would anyone actually want that??? I am honestly trying not to make this so outlandish but this is entirely what you just described. It's completely ridiculous.
The only thing this accomplishes is if you are trying to destroy money and make someone suffer by taking destructive actions... but like, if you are really an evil and petty criminal person you can also just do that with anything else? Like, rob them at gunpoint and set their cash on fire? Or slash their car tires? No one needs Bitcoins just to be an asshole, you can see that every day on this planet...