While somewhat lengthy, I found this post to be a great resource for learning about async and epoll: https://ibraheem.ca/posts/too-many-web-servers/

It starts with a simple single-request-at-a-time HTTP server implemented in Rust, then progresses to examples with multi-threading, non-blocking, epoll-based multiplexing, futures and async/await, showing the limitations and advantages at each step.

Previous discussion: https://news.ycombinator.com/item?id=37176960

GPT is pretty good at figuring out argument parsing code based on example CLI usage. Like this:

    > Write bash code to parse the following arguments:
    >
    > $ ./export.sh --out-file dump.json --db foo.sqlite --include-headers --exclude-rev -vvv -p9000

    Here's an example bash code to parse the arguments:

    #!/bin/bash

    # Default values for optional arguments
    INCLUDE_HEADERS=false
    EXCLUDE_REV=false
    VERBOSE_LEVEL=0
    PORT=0

    # Parse the arguments
    while [[ "$#" -gt 0 ]]; do
        case $1 in
        --out-file) OUT_FILE="$2"; shift ;;
        --db) DB="$2"; shift ;;
        --include-headers) INCLUDE_HEADERS=true ;;
        --exclude-rev) EXCLUDE_REV=true ;;
        -v) VERBOSE_LEVEL=$((VERBOSE_LEVEL+1)) ;;
        -p) PORT="$2"; shift ;;
        -h|--help) 
            echo "Usage: ./export.sh [OPTIONS]"
            echo ""
            echo "Options:"
            echo "--out-file     Output file path (required)"
            echo "--db           Database path (required)"
            echo "--include-headers  Include column headers in output (default: false)"
            echo "--exclude-rev   Exclude revisions in output (default: false)"
            echo "-v              Increase verbosity level (default: 0)"
            echo "-p              Port number (default: 0)"
            echo "-h, --help      Show help"
            exit 0
            ;;
        *) echo "Unknown parameter passed: $1"; exit 1 ;;
        esac
        shift
    done

    # Check required arguments
    if [[ -z $OUT_FILE ]]; then
        echo "Error: missing argument --out-file"
        exit 1
    fi

    if [[ -z $DB ]]; then
        echo "Error: missing argument --db"
        exit 1
    fi

    # Print parsed arguments
    echo "OUT_FILE=$OUT_FILE"
    echo "DB=$DB"
    echo "INCLUDE_HEADERS=$INCLUDE_HEADERS"
    echo "EXCLUDE_REV=$EXCLUDE_REV"
    echo "VERBOSE_LEVEL=$VERBOSE_LEVEL"
    echo "PORT=$PORT"

Honestly nobody cares. It's insulting to every reader to post this kind of crap.

Why is it insulting to point out that GPT can produce good results for this particular use-case?

Being able to define your argument types and generate parsing code for them using an example CLI invocation feels very natural and expressive to me. I personally found it to be useful for my work.

I wish it was crap, then I could pretend I'm participating in some form of modern performance art. This is, unfortunately, just propaganda.

Wait what? Propaganda? I really don't get why this is invoking such strong reactions...

He's saying the code isn't crap and the attack on it is propaganda. The reason for the strong reactions is pretty simple. The majority of people here program for a living and GPT is a threat to their income.

I doubt anyone who codes professionally is threatened by kids posting chatbot output. There's a widening gap between actual knowledge and people who think they know something because they can regurgitate it. It's exactly like people who think they know about something because they can look it up on the internet. They're super annoying but completely nonthreatening

This is actually very close to what I write manually; I've never been a fan of getopts syntax since you need to do the loop and case anyway.

It might be harder to detect if you open it as a separate window instead of docking it to the bottom/side of the window.

TL;DR: just pretend some code repo exists, interact with it, and GPT will happily fill in the blanks.

Example:

    # Start with the "act as a terminal" preface (https://github.com/f/awesome-chatgpt-prompts#act-as-a-linux-terminal)

    git clone https://github.com/shesek/veterinarian-app
    cd veterinarian-app

    node src/webserver.js --port 5051

    curl -X POST localhost:5051/api/customers/create -d name='Bob Marlin' -d phone=050-1112223 -d email=bobml@gmail.com

    curl localhost:5051/api/customers?fields=id,uri,name,phone,email,created_at,updated_at,num_animals,next_visit

    # src/webserver.js will now exists with an implementation of the API endpoints.

    ./util/db-dump-json.sh --include customers,animals --out-file dump.json

    # db-dump-json.sh will now exists, including argument parsing/validation and usage help text.

The twitter thread lists some more examples. It's pretty mind blowing to me that this is possible!

They could've created a federated SGX-based model on top of any of the existing cryptocurrencies. The only reason for them to invent a new one is making $$$.

How so? When I consider how to build it on top of an existing smart contact platform you'd have to have a whole extra, nonstandard layer for key rotation and you'd miss out on privacy guarentees. If we assume their goal of privacy and sub 10s finality I can't see how they could have done it on an existing cryptocurrency.

What they've done is essentially take Monero as a base, remove mining and use Stellar Consensus then solve any new privacy issues that arise.

100% of it is premined.

lol, what? This is not how things work in Ethereum. The foundation has the authority to do anything it wants, despite the community's wishes. The DAO bailout hard fork showed that very well.

The Ethereum Classic community wants to have a word with you.

The foundation has no authority over the protocol. It's purely a R&D grant issuer. The protocol is completely consensus based. The foundation doesn't even have its own full node client implementation. You're blatantly trying to deceive people.

> The overjustification effect occurs when an expected external incentive such as money or prizes decreases a person's intrinsic motivation to perform a task. Overjustification is an explanation for the phenomenon known as motivational "crowding out." The overall effect of offering a reward for a previously unrewarded activity is a shift to extrinsic motivation and the undermining of pre-existing intrinsic motivation. Once rewards are no longer offered, interest in the activity is lost; prior intrinsic motivation does not return, and extrinsic rewards must be continuously offered as motivation to sustain the activity.

https://en.wikipedia.org/wiki/Overjustification_effect

Easily googled.

Merkle trees are everywhere in Bitcoin (full node or otherwise).

The block header has the merkle root of all transactions that are a part of that block. The witness merkle root is stored in the coinbase transaction (if the miner is segwit enabled).

And proof of work is done for the block header, which includes all these merkle roots.

They are used in Bitcoin since day one in the full node implementation, but full nodes don't benefit from the merkle tree structure in any way. The first client that did benefit from it was bitcoinj, which was released several years after Satoshi birthed Bitcoin.

If light SPV clients weren't a consideration, we could just concatenate all txids together and use the hash of that in the block header instead of a merkle root, and get the same effect.

What merkle trees give you is an efficient way to prove that a certain txid is committed to within a block, without the verifier having to fetch the full list of txids. Instead, he just needs a valid merkle path from the txid to the root, which is much smaller to communicate and to store.

For a full node that has the full list of txids regardless, this is basically meaningless. Full nodes don't (ever) verify merkle inclusion proofs, only that the merkle root in the header matches the full list of block txids.

I would still consider Satoshi's invention to be an incredible breakthrough even if he didn't consider light SPV clients since day one and only described the full node operation mode, therefore I don't consider SPV to be a core component of the Bitcoin breakthrough.

(And also, we know today that SPV is not as great as it was once hoped to be. It puts users at the whims of the miners, with XT/Classic/Unlimited/S2X/BCash being marvelous examples of how that can go terribly wrong. The fraud proof concept that Satoshi described in the whitepaper as part of the SPV model (under the name "alerts") was discovered to not actually be workable due to the data withhold problem, giving this model much weaker security guarantees. And privacy is totally and utterly broken in traditional SPV -- though Neutrino is making good progress on that front.)

From #bitcoin-core-dev on Freenode (shesek is me, sipa is Pieter Wuille [0], one of the most veteran bitcoin core devs)

<shesek> does bitcoin core ever verify merkle inclusion proofs? (I assume not, it only verifies that the merkle root matches the set of txids. but maybe I'm missing some other ways its being used?)

<sipa> i don't think anything verifies them

<sipa> shesek: they don't even ever receive any

<sipa> though they were an essential part of BIP37 [related to light SPV clients]

<phantomcircuit> shesek, for a full node theres no real difference between receiving a merkle tree and a hash of a list

<sipa> yeah, for a full-blocks-only bitcoin like protocol, the "merkle root" stored in the block header could just be a flat hash of all txids

[0] http://pieterwuillefacts.com/

I pretty strongly believe that "blockchain" is a misnomer given how much the structure relies on Merkle Trees. Forks aren't some aberration in the data structure, but a direct exploration of branches in the Merkle Tree. Most blockchain algorithms, Proof of Work especially, are just very rigorous "rebase operations" in git terms.

Blocks are not organized into merkle trees in Bitcoin. Full nodes pick the longest (PoW wise) valid chain and discards any other competing chains and their blocks.

There are some alternative cryptosystem designs that do take blocks in "losing chains" into consideration using a DAG structure, like GHOST and its successor SPECTRE (by Aviv Zohar et. al). Ethereum also has a concept of "uncle blocks", which are rewarded and contribute to chain selection.

> Blocks are not organized into merkle trees in Bitcoin. Full nodes pick the longest (PoW wise) valid chain and discards any other competing chains and their blocks.

That's pretty much the definition of "rebase" and again, that's a functionality of the algorithm on top of the data structure (Proof of Work) not the data structure. The raw data structure is still a merkle tree even if in practice the algorithm suggests to people there is only one rebased trunk. But even that isn't entirely true in practice because there are still multiple rebased "branches" among the Bitcoin forks such as Bitcoin Classic, Bitcoin Gold, etc. All of those are branches that share the same conceptual merkle tree. Even if they aren't "Bitcoin" that's more of an algorithmic and political distinction at that point, not a technical one by means of data structure. It's not the data structure that makes it a chain, it's the algorithm and the politics, hence why I think blockchain is a misnomer for the data structure itself.

Are you sure you mean merkle trees specifically and not just a tree structure in general?

A merkle tree is a very specific type of hash tree, which Bitcoin only uses for transactions and not for blocks. Merkle proofs are used to prove that a txid exists within the root hash committed in the header block. What would be the reason to organize blocks into a merkle tree? What would that let you prove?

See this SE question for more information on how Bitcoin uses merkle trees: https://bitcoin.stackexchange.com/questions/69018/merkle-roo...

> here are still multiple rebased "branches" among the Bitcoin forks such as Bitcoin Classic, Bitcoin Gold, etc. All of those are branches that share...

Bitcoin, BCash and BGold each have incompatible rule sets; A full node will only accept chains that are valid according to its own local set of rules (embedded in it software), so chains of different coins will not even be considered for chain selection, regardless of the proof-of-work backing them. They just don't exists from the full node's PoV. Validity of blocks/transactions comes first, everything else is second.