paddlepop's comments

This.

As a platform, where do you draw the line between offering a product vs not because a developer could do something stupid with it?

edit: keeping in mind the use cases they are pushing in their documentation are for local development

>> My question to those who support big brother any lawful but awful speech is - do you really think it won’t be used to silence any dissent of the ruling powers?

My question to those that use this line of reasoning is do you really think a ruling power willing to silence dissent would do so whether or not it is supported?

I recommend you read the FAQ for the implications. And as homework for the reader, consider the banlist is a bloom filter

>> Being decentralized means no single party controls it

I suggest you have a look at how many people are allowed to merge bitcoins PRs in github

I call this the "Vulnerability view" instead of a "Remediation view" and its something I feel a lot of Security people and tooling gets wrong when sharing information with those outside our bubble.

It is dead easy to export a vulnerability scan or penetration test report and throw it at the developers, but you will get much better outcomes and better rapport if you tell them what they need to do (i.e. patch to version x.x.x) versus telling them what is wrong ("the sky is falling!").

For project maintainers, yes absolutely Monero.

But then either only ever use Monero for everything (like pre-2013 bitcoin), or exchanges will need the will to "proof" the source of funds aren't illicit.

I think mainly that I do not envy the lawyer that has to make the service argument.

We could get lost in the technical details of why it is or isn't a service but ultimately they only need to prove that x person of the project knew about the issues, could have done something about it (like shut it down), and didn't do enough.

It was just the one contract wasn't it? i.e. someone was responsible for deploying the contract that inputs and outputs the blending between addresses. In this scenario, the other permission less stuff is theatre.

That's exactly what I mean, its the service that is getting sanctioned. The people that "knew and didn't do enough to stop it" will be arrested.

My meaning of "code is just code" as a bad take, was just that the code part in isolation wasn't sanctioned.

As someone else has stated elsewhere in this discussion, I don't think GitHub have much to worry about. Tornado Cash the service was sanctioned, and MS would choose to censor the repo out of an abundance of caution. In the same way that the pair that open-sourced the ransomware PoC didn't get arrested because they are further away from the offenses.

I have mixed thoughts on safe harbor for centralised exchanges, they are the closest thing we have to banks in cryptoland. Mostly because with grey areas like that, a prosecution is only going to be pursued with clear evidence they knew but did nothing.

Person that has worked on the defensive side of Money Laundering here.

The Tornado Cash sanction has been fascinating to watch and my key takeaway has been that there are two camps: that TC is a Money Laundering service or a Privacy service. Both are talking past each other, when it can in fact be both. Each camp see the service as their primary concern and consider the other camp as an unintended secondary.

I am seeing a lot of bad takes. "Money laundering requires all three aspects" particularly irks me because you can just point to KYC regulations to disprove that. "Code is just code" is another, but that is just because the code isn't why someone would be sanctioned or arrested. In the same way that The Pirate Bay was just code, its is how complicit they were in the offence that will get them.

Ultimately, the dichotomy feels like a problem unique to public blockchains, and will only be solved with a ZK L1 chain, whatever that looks like. The solution would require the blockchain equivalent of end-to-end encryption, one where intermediaries have zero knowledge but doesn't require co-mingling of dirty and clean money.

While I think money laundering is a more serious crime than piracy (at least the predicate offenses can be). Watch this play out like Megaupload, never ending legal issues for the first parties, and a technical solution like Mega.

This is a build deployment perspective.

I for one do not miss hosts never being patched because all those slight modifications to systems files that were tweaked several builds ago and now everyone is too scare to touch.

I won't miss the 12 month projects to upgrade some dated software to a slightly less dated version of that same software.

From my perspective in Security, DevOps has made life much better.

The only novel benefit, as you say, is "decentralized trust". The blockchain portion of the NFT in most cases is simple a pointer to the asset and the owner, with the actual asset being off-chain managed by a single entity that can do whatever they please with it. Why does the ownership need to be decentralized if ultimately, the asset is mutable?

I still don't understand why this needs to be decentralised?

> without having to solely trust the company issuing the nft ticket

For the transaction yes, but what about the thing you are buying? Perhaps I am not thinking creatively enough, but I can't think of a use case where there isn't ultimately some trust required other than solely digital assets.

Using your hotel example, you will end up at the hotel where they can choose to honor your ticket in the same way as their traditional booking system. There was no need for this to be on a distributed ledger as the asset (a hotel stay) was between you and the hotel.

You are not cutting out the middle man of some SaaS provider, you are substituting them.

...and they are?

I think the subtext that is implied with the no use case statement is really: "that couldn't be done with an existing technology (such as a database)".

This is called the Ferber method and it worked very well for us as well. Note to others considering using it, the method is just as much about the ritual leading up to sleep (bath, reading a book, etc)

A clinical consensus on whether addiction is a choice? Perhaps you are thinking of a clinical consensus on how best to treat addiction? This is often glossed over by the "addiction is a disease" crowd. The efficacy of treating addiction as a disease does not make it any more "true" as an explanation for the circumstances leading up to it.

I will admit to not being a fan of FB also, but discouraged by the number of Slippery Slope arguments on this piece.

MITREs response to this is a perfect example of the old-school security team mindset. If I had a nickel for every security team I've worked with that a) treat reporting as gospel and don't validate it, and b) don't talk to the developer. From my experience the key issue is they don't understand the issue enough to engage in a meaningful discussion with the developer

This doesn't work so well for video games. Reviews come out saying its thin on content with a score to match and can kill a game before its had a chance to expand. Developers have started trying to do this more often lately with mixed results, DICE and Blizzard are high profile examples of this. Blizzards latest World of Warcraft expansion was heavily criticized for the lack of content on release day and has yet to shake the bad blood even after two big content patches. DICE tried this with Star Wars Battlefront but couldn't keep fans long enough with the limited maps it released with.

From my experience the issues with this study have been well known for a long time. A first year Psychology paper I took over 10 years ago was at pains to point out the flaws in the study - not that this was unusual, a good lecturer will critically analyse any scientific study they present. Perhaps it has more to do with the increasing popular appeal of the study?