jude-

STX did. SEC reg A sale docs: https://www.sec.gov/Archives/edgar/data/1693656/000110465919...

Disclaimer: I work on STX and its blockchain

Yes. See the Reg A token sale filing docs on the SEC Edgar system for the STX token [1].

Disclaimer: I work on STX and its blockchain

[1] https://www.sec.gov/Archives/edgar/data/1693656/000110465919...

> It's important to note that event for the projects creating new tokens, there is NO WAY to register.

Yes there is. You register them as securities. STX[1] did this. Other projects need to suck it up and do it legally.

[1] disclaimer: I work on the Stacks blockchain (STX)

You just replied to him

[flagged]

Very few French are dying of it (like, 300/day), which I'd call a massive success story. Containing COVID is of course out of the question at this point, and I never argued otherwise. However, the risk of life and limb to people who did get vaccinated is nevertheless increased by the presence of those who did not, because the unvaccinated get sick and eat up hospital resources that would then be denied to people who need medical attention for unrelated reasons. Moreover, they increase the risk of spreading COVID to people who cannot get the vaccine (e.g. babies, folks with weak immune systems). So, it really is in everyone's interest to get everyone vaccinated -- everyone's risk of dying a preventable death decreases.

What's the cost of this? Why, it's the very same as the cost of getting most everyone vaccinated for literally anything else we get vaccinated for! No one has a conniption about vaccine regimens for measles, mumps, polio, etc., because the programs for implementing them at scale have been so successful that hardly anyone gets hospitalized or dies from them anymore. Want to attend public school? Get vaccinated. Want to join the military? Get vaccinated. Want to live in a college dorm? Get vaccinated.

The marginal cost of adding one more required vaccine on top of the ones almost everyone regularly gets (and almost no one complains about) in order to participate in normal society is negligeable.

So no, it's not a case of "everyone gets corona" vs "everyone gets corona and we have a miserable digital dystopia", as you put it. It's a choice of "everyone gets corona and a lot of other people needlessly die for want of medical care" vs "everyone gets corona and/or the vaccine, you have to fill one more checkbox on your vaccine card (which already has a dozen or so), and comparatively fewer people die for want of medical care." Life will get back to normal either way; at this point it's really a question of dealing with the selfish, paranoid, delusional, despicable people who would rather see the mass death of their fellow countrymen over having to fill one more checkbox on their vaccine card.

Or, we can do what we've done in the past to address this very situation by giving everyone the following choice: get the vaccine, or forfeit some privileges. It's not hard, and it's not without lots of precedent, so it should not be controversial.

I can expect that if a sufficiently high body count or death rate is reached (now or in a future variant), certain high-risk activities will require proof of recent vaccination to participate in. See also: seatbelts, child-specific seats, etc. Why should I, a responsible member of the public, be forced to put up with other people's needlessly risky behavior when it directly affects me and mine?

Face masks and vaccines will be the new seatbelts and DUI laws at the rate we're going. I predict that certain activities like flying on an airline, going to public school, or working at a job with close quarters will one day require proof of vaccination and/or masking up to participate. Omicron won't be the last variant, and there is no guarantee that a future variant won't come along that is just as virulent but far more deadly.

The problem is that a certain slice of the population adamantly refuses to wear a mask or get a vaccine, thereby prolonging the pandemic.

It sounds like you are calling me and my friends Nazis for wanting a more egalitarian Web?

I have the opposite experience. My circles are super left/socialist and are also very pro-crypto. Reorganizing a traditional web 2.0 app into a web3 app governed by a DAO is very much a proletariat revolution. In web3, users, not the SaaS operators, own the means of production and wealth distribution.

Why settle for quadratic? Why not cubic? Or why not n^1.2? What's so special about quadratic that makes it the best candidate?

Yeah, how dare people try to make money without resorting to surveillance capitalism. What's the world coming to.

You address this by taxing at the fiat on/off ramps. The ones with access to the deepest liquidity also happen to operate in jurisdictions that have functioning governments that are amenable to passing taxes on PoW. And if that doesn't work, you impose sanctions and tariffs on the countries that permit limitless PoW mining, up to and including black-holing their IP blocks.

It can be done. We banned CFCs after all.

Firefox needs to go with a one locked-down process per tab model. There is no excuse these days for a single tab crash to kill off substantial portions of the browser. Moreover, there is no excuse for a tab compromise to allow access to other tabs' memory.

I use Chromium because it has both a safer and more reliable design and implementation. If web browsers were OS's, Firefox would be Mac OS 9. If Mozilla wants to understand why they're losing market share, they should try and understand why no one builds OS's like that anymore.

You can't transmute Bitcoin back into electricity and ASICs. You have to generate more of both, which is extrinsic to the protocol and thus available to currently-non-participating actors. PoS does not have this property.

> This is a threshold that real-world contracts don't typically have to achieve

And boy does it show!

How do you debug your smart contract? Your users tell you their money got stolen out of it. I wish that was a joke.

> Also, if you're just going to replace one immutable contract with another, you're back to meatspace and re-negotiation, which can be time consuming and expensive.

Is upgrading them in place somehow better? At least by keeping the old systems around, the people who still get mileage out of them aren't sold up-river.

> verifiers need to have a copy of everything.

Hate to break it to you, but if your consensus rules permit forks, then there's no getting around this. A fork can be mined arbitrarily far in the future that builds off of a block arbitrarily far in the past.

We intend to partition state by application, for applications that are willing to trade smart contract composibility for more block space: https://gist.github.com/jcnelson/c982e52075337ba75e00b799421...

> But then again if you're building it on top of the literal money fire that is bitcoin, who cares about scalability and resource use!

Show me a more resilient blockchain and we'll build on that instead. Popular systems see lots of usage; news at 11.

> Flaws, once known, can be remediated. I don’t think macOS has bulletproof security but I’m sure glad Apple keeps updating it.

My point is that a piece of software does not need an upgrade procedure if there exists a way to install a newer copy without touching the old one. Trying to build an upgrade procedure when there is always the option to install a newer version this way (especially if it can seamlessly access the older version's state) is at best over-engineering.

> Out of curiosity, how does this typically get exposed in dApps (or wallet UIs) built on Stacks?

This is being done right now with Stacks' on-chain naming system, which is realized as a smart contract. The new naming system does not need to import any state from the old system in order to resolve pre-existing names, nor does the existing naming system need to be disabled, because the new system is instead able to call the name resolution method via this "run read-only code on the chainstate as of this block" feature. The past is immutable, so future changes to the state of the old system beyond a predetermined sunset block (defined in the new contract) will not be visible to the users of the new system.

Consider this example. Suppose the name "alice.btc" was registered at block 1000 (hash 0x123) in the old system, and suppose the new system was deployed to use all the state in the old system up to block 1001 (hash 0xabc). Resolving alice.btc in the new system runs code to the effect of:

  (let (
    (alice-rec (at-block 0xabc
      (contract-call? 'SP000000000000000000002Q6VF78.bns name-lookup? "alice.btc")))
    )
    ;; Do something with alice-rec
  )

Internally, the (at-block) function runs the given code body with access to the system state as it was as of the end of block 0xabc. The system state is represented internally as a set of key/value pairs indexed by a forest of authenticated hash tries which make it efficient to query a key as of a particular block (see https://github.com/stacksgov/sips/blob/main/sips/sip-004/sip... for details).

Suppose bob.btc was registered in block 1002 (hash 0xdef). The above (at-block) call will not resolve bob.btc in the old contract, because its state was written after the sunset block 0xabc.

> You shouldn’t, because no code of sufficient complexity is flawless.

So why build an upgrade procedure at all, when you don't have to?

> On the Ethereum blockchain (for instance) storage and smart contracts are tightly coupled.

Sounds like an unforced error on these smart contracts' authors parts, and should not be used as an excuse to compromise the principle of code immutability.

If the possibility existed that they need to replace the business logic at a later date, then they should factor the storage logic so as to avoid this coupling. It can be done -- for example, a smart contract dapp can leverage a shared contract that only implements a public key/value store, where the keys are prefixed by the calling contract's address. Then, when the business logic contract changes, it can access any old versions' state with the old versions' contract address, apply any migrations on-the-fly, and store new state that will not overwrite old state due to this key prefixing.

In the Stacks blockchain (which I work on), we go one step further by making it so you can run an arbitrary read-only code snippet on the state of the blockchain at any point in the past (as given by a block hash). Then, you don't even need to do any migrations -- you can just query the historic state of your old contract and only store new data once it's necessary.

> I’d put that in the category of code that really could benefit from carefully controlled upgradability.

First, if you're saying that you need a way to upgrade your money-managing code periodically because you will likely ship versions of it with show-stopping bugs (such as those that enable the destruction or theft of the users' funds), then why should I trust that you will ship flawless code for upgrades?

Second, if the combined security budget of the people who can carry out the upgrade is less than that of the majority of the block producers on the chain, then why build an upgrade procedure at all? Why risk it? Instead, just deploy a new version of the smart contract, and ask users to use that one instead. If it gets confirmed, then an honest majority of block producers will ensure that it stays confirmed. This takes no code at all. You simply sign the new code with the same key that deployed the old code to demonstrate that it originates from the same author(s). Let users decide on their own whether or not to use your upgraded code -- after all, it might introduce new bugs, and the "bugs" you are fixing might be features to other people. It's not your place to tell users what version of the code should be used, and what should not be used.

As a user who might prefer the first version of the code to the second, why should I be excited about a software system that can force me to use the upgraded version? That's a design flaw in the current Web -- when a Web service I rely on changes its behavior and goes out of business, I'm SOL. Web3, with immutable smart contracts that stay online, has the potential to fix this.

> At the same time, smart contracts have some deeply problematic constraints: > Smart contracts can’t be upgraded. Smart contracts are deployed once and run forever; their code cannot be changed. The software development industry has literally zero experience with such a deployment model.

I stopped reading here. First, this is factually wrong -- the software industry has tons of experience dealing with software that can't be upgraded. Ever try to upgrade the firmware on a chip with no I/O facility for doing so? The answer is you don't; you instead focus on getting the code correct the first time, and possibly you build out a way to recall the product and replace it with a fixed version and price in the risk of needing to do so into the product itself. It can be done; it just takes discipline.

Second, if you don't understand why smart contracts being immutable is a necessary and desirable feature of the system, not a bug, then you're not going to understand much of web3. Like, think about it for five minutes -- if your smart contracts can be upgraded by default, and this code manages valuable digital assets, then their code can be replaced with code that steals those assets. Making this very, very, very hard is deliberate.

The conclusion I drew from the article was "I had to lose a hand to appreciate GNOME." The author does not intend to stay with it once her hand heals.

This code is just an example. The state machine can easily run in its own thread, separate from the main thread. As long as the state machine had an IOClient instance that lets it send I/O requests to the IOServer and receive I/O results, you're good. Also, you could imagine an IOClient having an API that takes a StateMachine instance as input, and returns an IOClient::Future that resolved to the machine's main() return value.

I'm not saying that we should go back to hand-rolling our own epoll loops. I'm saying that we can do better than async/await by making both the state machines and event loop explicit. For example, here's an API I'd prefer to use over async/await:

   /// A state machine that adds three numbers and uploads them to a web server
   struct AddAndUpload {
      /// I/O handle to the event loop
      io: IOClient,
      /// Buffer to store numbers I load
      nums: [u64; 3],
      /// URL to upload the data to
      url: String
   }

   impl AddAndUpload {
      /// Constructor
      pub fn new(io: IOClient, url: String) -> AddAndUpload {
         AddAndUpload {
            io,
            nums: [0u64; 3],
            url
         }
      }

      /// Entry point to this state machine
      pub fn inner_main(&mut self) -> Result<(), IOClient::Error> {
         /// go and get the data
         let n1_fut : IOClient::Future<u64> = self.io.sql_async("SELECT n1 FROM table1", &[])?;
         let n2_fut : IOClient::Future<u64> = self.io.sql_async("SELECT n2 FROM table2", &[])?;
         let n3_fut : IOClient::Future<u64> = self.io.sql_async("SELECT n3 FROM table3", &[])?;

         // wait for all I/O operations to finish
         IOClient::wait_all(&[&n1_fut, &n2_fut, &n3_fut])?;

         // extract results
         let n1 = n1_fut.into_inner();
         let n2 = n2_fut.into_inner();
         let n3 = n3_fut.into_inner();

         // upload them
         let sum = n1 + n2 + n3;
         let upload_fut : IOClient::Future<IOClient::HTTPStatus> = self.io.http_post_async(&self.url, &["content-type: application/octet-stream"], &sum.to_be_bytes())?;

         let upload_http_status = upload_fut.wait()?.into_inner();

         match upload_http_status.as_u16() {
            200 => {
               Ok(())
            }
            400..499 => {
               Err(IOClient::Error::Custom("client error"))
            }
            500..599 => {
               Err(IOClient::Error::Custom("server error"))
            }
            x => {
               Err(IOClient::Error::Custom("Nonsensical HTTP code"))
            }
         }
      }
   }

   impl IOClient::StateMachine for AddAndUpload {
      type Return = ();
      fn main(&mut self) -> Result<(), IOClient::Error> {
         self.inner_main()
      }
   }

   /\* somewhere else \*/

   fn main() {
       let io_server = IOServer::spawn().unwrap();
       let io_client = io_server.client().unwrap();
       let add_and_upload = AddAndUpload::new(io_client, "http://example.com".to_string());
       loop {
         io_server.run().unwrap();
         match add_and_upload.get_machine_status() {
            Ok(IOClient::StateMachine::Finished(result)) => {
               eprintln!("add_and_uploaded exited with {:?}", &result);
               break;
            }
            Ok(_) => {},
            Err(e) => {
               panic!("add_and_upload aborted: {:?}", &e);
            }
         }
      }
      io_server.terminate();
   }

Except doing so introduces a bunch of needless programming difficulties, including but not limited to the ones discussed in this article. For example, if you make the state machines and epoll loop explicit, you don't have the function coloring problem -- all your I/O requests from state machines to the poll loop (which may or may not cross thread boundaries) are explicit synchronization points with your global business logic, which gives you fine-grained control over how your state machines handle things like request timeouts, resource quota limits, cancellations, execution suspend/resume, and so on. As another example, you're not limited to factoring your state transitions into closures. As a third example, your business logic would have global, explicit control over I/O scheduling, which greatly simplifies end-to-end QoS and request prioritization.

"Maybe we could just have kept Rust as it was circa 2016, and let the crazy non-blocking folks write hand-crafted epoll() loops like they do in C++. I honestly don’t know, and think it’s a difficult problem to solve."

I think this is the most underappreciated part of this article. Since when did everything have to be async? There are other ways to represent concurrency that more accurately reflect what the computer is actually doing.

For example, an alternative to async is to represent a workstream as a state machine, where state transitions happen between I/O. Then, your state machine can be a struct, and each state transition can be an impl function on that struct that takes one or more completed I/O requests as input and emits one or more I/O requests as output. This saves you from having to implement everything as a closure, which this article rants about. Your top-level epoll loop merely services I/O requests from state machine instances, and invokes your global application logic to start and stop state machines to carry out business logic tasks.

I realize that many complicated workstreams could have many states due to all the I/O they might do, but the task of converting a high-level workstream into a state machine could be automated by the tooling.

The psychological manipulations that religions put in place to keep you adhering to the faith through tough times do not apply to either Nazism or racism in general. Like, neither political ideology promises you eternal life or reincarnation after death, nor does either one promise you a divine reward if you are persecuted in this life for holding these beliefs. Neither say anything about divine punishment for non-believers, and neither offer divine rewards for proselytization.

This is what makes religious indoctrination that much harder to shake off. If you truly believe that you will face divine and eternal punishment for becoming apostate, or will receive divine and eternal rewards for adhering to the faith, then you'd naturally take the latter path even if only out of your own self-interest. Breaking out of this mental model requires recognizing the psychological manipulation for what it is, despite having known no other mental framework.

By contrast, racism and Nazism do not manipulate you this way. They instead appeal to your senses of grievance, entitlement, and resentment, in a way that enhances your self-esteem. While this can also be difficult to break away from, the psychological barriers for doing so are a lot lower -- like, you're not dealing with eternal consequences.

But regardless, the topic at hand is whether or not religious or political discrimination are acceptable when it comes to using a platform like Twitter. I'd say "yes" in both cases -- Twitter isn't a vital service (compared to, say, housing, banking, or employment), and you not having a Twitter account does not inhibit your ability to hold and act on either your religious or political beliefs.