Wikipedia cites sources. Go to those sources, find the ones that best line up with the data you need, and cite them directly.

Treat Wikipedia like an aggregator -- you wouldn't cite an HN post, you'd cite the link it pointed at.

To counteract this negative feedback loop, assuming the increased prices don't drive away all of your real customers, you can spend the increase on transaction analysis, and turn away customers based on their likelihood of fraud, so you've added inefficiency into the system to help deal with a criminal element, and also likely turned away real sales due to false positives in your analysis.

It's no surprise that these types of merchants are looking for a disruptive technology to remove this inefficiency. Doing so would allow them to charge less and outcompete as well as capture the entire market of people marked as false positives by other merchants.

EASTL provided a bunch of value that the standard STL would not. The biggest benefit was a unified implementation across all platforms. Standard library STLs all had their own idiosyncrasies and code that worked on one platform might not compile, or worse, have a bug on another.

At the time, EASTL was equal or higher quality than standard implementations. Performance was better, code quality was better, and it broke from the standard in some key ways that were important for performance, and it had some key upgrades that allowed usage patterns and data structures that the standard STL simply didn't allow:

Vectors supported "trivial relocation" before the existence of move constructors. While move constructors have ameliorated the problem, I argue that feature is still missing from c++. Please support P1144! http://open-std.org/JTC1/SC22/WG21/docs/papers/2020/p1144r5....

Intrusive containers (in particular, intrusive linked lists in eastl::intrusive_list) embed the container overhead into objects themselves. This allows non-movable objects to be stored in these lists without requiring an extra pointer dereference on access. It also lets you convert an object reference into an iterator over the list that contains it. There are tons of uses for this. It also allows polymorphic lists (e.g. intrusive_list that actually holds instances of various subclasses, again without an extra pointer dereference)

If you want more information, EASTL's lead programmer Paul Pedriana (rip) goes into detail in http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n227...

That said, they definitely had problems with failing to culturally assimilate immigrants during the late empire -- when "citizens" of the empire didn't think of themselves as Roman but instead primarily part of some other group.

It's clearly an industry with huge potential if it is economically viable to spend money buying an Argentina's worth of power on it.

Here is the exact text from the DMCA from https://www.aclu.org/other/text-digital-millennium-copyright...

(vi) A statement that the information in the notification is accurate, and under penalty of perjury, that the complaining party is authorized to act on behalf of the owner of an exclusive right that is allegedly in-fringed.

Note the particular phrasing. The requirement that the information in the notification be accurate is not under penalty of perjury. The only thing that is under penalty of perjury is that you can only DMCA claim things that you have copyright to (or are a lawyer representing that entity).

And it's worse than that, because you can claim something that is totally unrelated without this penalty as long as you own the copyright you claim to be enforcing.

The only explanation I can think of is that they are relying on a sidechannel to communicate the actual transactions, which makes sense in the miner case (the utxo pool) but not in the general node case.

Beyond that, I run a BTC node occasionally and the bottleneck is validating blocks, not downloading them. Transactions are complicated enough right now that I'm only able to catch up at about 350x real-time (that is, it takes around a full cpu-day to validate a year of blocks/transactions).

The code you want to write is something like:

  fn f( filename ) {
    val someUrl = computeTheUrl();
    val data = await http.get( someUrl );
    val processedData = process(Data);
    await filesystem.writeFile( filename, processedData );
  }

But the code you want to run is an event loop:

  while( program_is_running() ) {
      poll_io()
      poll_network()
      run_ready_tasks()
  }

You're right that you can use a green thread per task to solve this problem, and "await" is then just a function that switches context to the scheduler. For various reasons, the Rust community decided that green threads were too heavy of an abstraction, and instead the compiler generates state machines (which are, in some ways, equivalent to green threads if you squint hard enough).

> if a future is inert, how can it ever detect that it is ready to make progress and call wake?

The future doesn't. When the future makes a blocking call, it needs to push its waker into some data structure handled by the top level event loop / scheduler. And then the job of the waker is to understand how to push the task back into the ready queue when whatever was being waited on completes.

The complications in Rust's design is due to their goal of making it so those compiler-generated-state-machines can be used by a library runtime -- to not require a particular standard library.