I think at this point I'd rather pay for a desktop browser, something with blocking baked in at compile time.
It would be such a QoL improvement that it's worth paying a yearly subscription for.
It's also unintuitive in the sense that if you are racing you usually want to discard/stop the other Promises that didn't finish in time.
But the only real way to do this is to pass through an AbortController down into whatever networking/IO task (and your own code for that matter) is happening to "cancel" it that way.
Otherwise you just end up with the result of the fastest Promise and the rest will continue when they get a chance.
I thought the point of using observables over promises is that they have cancellation, and presumably an implementation of race would cancel any slower request (i.e., handle the abort controller automatically)? Is that not the case?
My comment was just on the standard behavior. Not sure when it comes to observables, probably comes down to how you are implementing it. But in general it's impossible to cancel a hanging Promise, you have to have some kind of signalling mechanism that either throws so it rejects or otherwise resolves the Promise chain.
The contract is payable, i.e. will accept ether as payment but doesn't actually do anything.
From a glance looks like the withdrawal function is setup to generate the address of the scammer - through all of those obfuscated functions that have hex string slices - so ultimately only they can remove the funds.
Where I'm at, most of Kafka usage adds nothing of note and could be replaced with a rest service. It sounds good that Kafka makes everything execute in order, but honestly just making requests block does the same thing.
At least then I could autoscale, which Kafka prevents.
NATS JetStream seemed to support horizontal scaling (either hierarchical via leaf nodes or a flat RAFT quorum) and back pressure when I played with it.
I found it easy to get up and running, even as a RAFT cluster, but I have not tried to use JetStream mode heavily yet.
Thanks for the examples, I'm working on a TypeScript code base at the moment and this is fantastic way of adding compile-time typing across many of the basic types I'm using!
I also don't think this will work for them in the context of the Ripple case they just lost - and decided to not appeal - as this will be referenced as part of Kraken's defense.
It'd be very different if the SEC maintained a list of even examples of tokens that are/aren't compliant and a straightforward registration process with active registrants.
The fact that neither of these exist but the SEC likes to pretend they do isn't working in their favour.
There is no such thing as a 'registered securities exchange' for cryptocurrency, so how can they be at fault (note its unregistered, not illegal is the allegation).
There are at least hundreds of thousands (probably millions) of securities that have been properly registered in the USA: stocks, corporate bonds, private offerings, and many other kinds of financing structures. It’s not that hard since obviously all kinds of issuers can figure it out.
The crypto people want to pretend their tokens are something completely different, so they’re not willing to use the existing process and instead cry out for SEC to come up with something just for them.
How do you propose Bitcoin, or Ethereum, or any other decentralized & peer-to-peer asset be registered as a security? Coinbase and Kraken argue that there is no clear path toward registering these assets within the current framework.
For an example, some of the stringent per-transaction KYC/AML reporting requirements in traditional financial systems are often incompatible with today’s mechanisms of distributed ledgers.
These cases aren’t about Bitcoin and Ethereum but the dozens of other coins that these exchanges have listed.
Coinbase actively cooperated with token founders and venture capitalists like A16Z to list various newly issued tokens so that the creators and VCs could sell them to retail investors. This arrangement sure makes them look like securities.
Personally I’m fine if Coinbase and Kraken trade Bitcoin and Ethereum. Being restricted to those would be devastating for their profits though.
I checked, and the complaint[1] lists specific tokens, including ADA (Cardano), NEAR, SOL (Solana), ALGO (Algorand), MATIC (Polygon) and others. I have purchased some of these in the past from Kraken to evaluate the technology on my own terms. It would be a shame if the SEC forces consumers to use less reputable exchanges to access these tokens all in the name of "consumer protection."
There appears to be no clear path forward for crypto exchanges to legally list new crypto tokens to the public. I suspect that is the goal of the SEC and administration; to limit what is available to the public, rather than define clear policies that would enable regulated trading. The only token actually tested is XRP, which was deemed to not be a securities offering[2], and is notably absent from this new filing.
> "There appears to be no clear path forward for crypto exchanges to legally list new crypto tokens to the public."
That's American securities law. The exchanges can always sell these tokens to accredited investors, but that's not the business they want to be in, I guess.
Of the tokens you mention, Solana was a major component of Sam Bankman-Fried's fraud empire. You dismiss the consumer protection aspect, but clearly it would have been better for consumers if SBF and FTX/Alameda didn't have access to American retail investors through this token.
What I'm trying to say is, it's probably very hard right now to change securities laws in a direction that would make it easier for Americans to buy the kinds of tokens that SBF manipulated. That just seems like political reality.
Trying to prohibit citizens from something potentially risky is a poor approach to safety — we've seen it play out with alcohol, drugs, abstinence, etc. Another approach is creating new frameworks to engage and interact with these topics in a safe and secure manner. The SEC and US administration is taking the former approach.
> some of the stringent per-transaction KYC/AML reporting requirements in traditional financial systems are often incompatible with today’s mechanisms of distributed ledgers
Presume this is the sticking point for the companies as well since now they will have to actually manage their drivers to actually ensure they are working and not just gaming it.
So it will end up being the additional cost from the minimum wage plus everyone else required to police it.
Except that it would exclude a raft of non-US citizens then, i.e. any sanctioned country, Coinbase would also need to become registered as an ATS and their current settlement and clearing processes would need to be re-engineered from the ground up.
For all intents and purposes you cannot register a cryptocurrency with the SEC and then go on trading it anywhere publicly - it doesn't exist.
There's only been a few projects that managed to avoid this: Enigma for example moved to a decentralized network and changed their coin over (so it was magically no longer a security according to the SEC) and the SEC just fined them and made them issue refunds for the project raise.
In some cases, I find it sympathetic. For example, I don't think it's a clear cut moral resolution that people should exclude Iran from buying US goods and services, but they are on the sanctioned list. I supported Obama dropping sanctions on Iran back when he was president.
There's a difference between what is legal and what is moral. For what is moral, there are hardly any absolute answers.
> I don't think it's a clear cut moral resolution that people should exclude Iran from buying US goods and services, but they are on the sanctioned list
Sure. But crypto is an inefficient way to express that policy preference. And it's difficult to comport claims of altruistic intent with crypto's financial incentives.
