nadaviv

I really enjoyed Crafting Interpreters by Robert Nystrom and found it valuable for the development of a DSL I'm working on.

From https://craftinginterpreters.com/:

> Crafting Interpreters contains everything you need to implement a full-featured, efficient scripting language. You’ll learn both high-level concepts around parsing and semantics and gritty details like bytecode representation and garbage collection. Your brain will light up with new ideas, and your hands will get dirty and calloused. It’s a blast.

The book is available for free on the website: https://craftinginterpreters.com/contents.html

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

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

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.

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"

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 $$$.

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 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

Source?

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/

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.

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.

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.)

I wouldn't consider merkle trees to be a core component of Bitcoin. Full nodes don't benefit from them, they're only relevant for light SPV clients, which didn't even exists for a few years after Bitcoin was released.

The source code (in Rust with LALRPOP) is available on GitHub: https://github.com/shesek/minsc

The website has some example scripts and a compiler that you can experiment with.

Happy to answer questions!

This is the article in question, co-authored by Gwern and published on Wired in August 2015:

"Bitcoin's creator Satoshi Nakamoto is probably this unknown Australian genius"

https://www.wired.com/2015/12/bitcoins-creator-satoshi-nakam...

This was one of the first and strongest "evidence" supporting Craig's claims, published by a well-known magazine and a reputable researcher. I've personally talked with several people who were convinced of the authenticity of Craig's claims using this publication as one of their primary justifications.

The linked thread has a long discussion between Greg Maxwell (/u/nullc) and Gwern (/u/gwern), where Greg calls him out and repeatedly asks him to retract his previous claims; Gwern acknowledges that he was deceived, but refuses to make an official retraction.

> see anyone neutral arguing it wasn't.

Well, FWIW, I've never heard _anyone_, neutral or not, claiming the DAO hack was a bug in the Ethereum protocol before now...

And that's because, well, it very clearly isn't. hackingdistributed has a good overview[0] of the coding bug in the DAO that enabled the hack which I recommended you to read.

Looking at this another way, this could've been avoided by the DAO developers if they developed the smart contract more carefully. And the exact kind of bug that lead to the hack was still possible on Ethereum following the bail-out hardfork. So how can one claim the hardfork fixed a protocol bug?

> If you argue The DAO hacker had the right for the Ether

I didn't say that. I only argued about the differences between fixing a protocol bug and bailing-out companies that build on top of the protocol.

[0] http://hackingdistributed.com/2016/06/18/analysis-of-the-dao...

> Light nodes have the same guarantees about the integrity and irreversibility that full nodes do.

This is not true. SPV nodes blindly follow the longest chain and are at the mercy of miners. Running a full node guarantees you that all the protocol rules are being followed to the letter, while an SPV node cannot verify chain validity rules (like the 21M coin limit) and could be fooled to accept payments with money made out of thin air.

> Ethereum is that it had a hard fork to revert a millionaire hack caused by a bug in early stages of the project; whereas something not too different also happened to Bitcoin

The Bitcoin developers fixed a bug in the Bitcoin protocol. The Ethereum developers bailed-out a buggy smart contract written by a third-party, where the bug had nothing to do with the Ethereum protocol itself. I don't think the two are comparable.

Something that would've been comparable is the Bitcoin developers doing a chain-rollback to save the funds lost by MtGox. Which of course would be a horrible idea.

Also, when that happened in 2010, Bitcoin was a pet project valued at $0.08, with a total market cap of ~$250k. Ethereum was nearly a two-billion dollars project when they bailed out the DAO!

Well, doesn't that mean that the security model is based on you acting as trusted third party and relying on you to only write truthful data to the blockchain?

In other words, the delivery proof is not based on trusting the blockchain mechanics, its based on trusting Gmelius Ltd.

So you're acting as a trusted party to get delivery confirmations from Google? What if Google doesn't confirm delivery, but you decide to write to the blockchain anyway?

Also, won't Google servers return a cryptographically verifiable delivery confirmation? If so, couldn't this be used as the delivery proof directly instead?

How does that prove the email was sent, though? Couldn't one timestamp the email into the blockchain, without actually sending the email to the other party?

Edit: btw, I released something that utilizes bitcoin's blockchain for timestamping back in 2013: https://news.ycombinator.com/item?id=5790382 (the website is no longer available because better solutions came since, but its up on github[0] and the wayback machine[1])

This has some interesting use-cases, but people tend to overestimate what blockchain timestmaping actually gets you. You can prove that some piece of data existed at some point in time, but that's it. It doesn't prove this data is authentic, that this data was communicated to anyone, that no one else timestamped this data earlier, etc.

[0] https://github.com/shesek/btproof

[1] http://web.archive.org/web/20140430152135/https://www.btproo...

It's an open-source project and not a startup, but I think that Namecoin [0] is a very interesting non-currency use for blockchains.

It is a decentralized name registry that maps domain names to public keys and IP addresses, removing the need for Certificate Authorities and resolving Zooko's triangle [1].

I do agree that blockchain is insanely over-hyped, has very few real use-cases and mostly used as a PR tool in ways that makes no sense. Sound money and cryptographic identity registries are among the only reasonable use-cases that I can name.

[0] https://en.wikipedia.org/wiki/Namecoin

[1] https://en.wikipedia.org/wiki/Zooko%27s_triangle

Don't believe everything you read online, especially in the Bitcoin space, which is flooded with nonsense, conspiracies and deception promoted to push agendas. I highly recommend you do some more independent research before taking your parent comment at face value.

Ugh. These silly conspiracy theories don't hold up to reality. An overwhelming majority of the technical development community, wider community and industry was and still is supportive of Bitcoin's scaling roadmap. Trying to attribute that to Blockstream or to the moderation policies of a subreddit (among hundreds of online bitcoin communities) is just silly and not grounded on any facts.

See my previous comments on that topic for some more info:

https://news.ycombinator.com/item?id=15774816

https://news.ycombinator.com/item?id=15033611

https://news.ycombinator.com/item?id=15033489

https://news.ycombinator.com/item?id=15026822

https://news.ycombinator.com/item?id=13911867

https://news.ycombinator.com/item?id=13627362

Source code: https://github.com/ElementsProject/filebazaar

Demo gif: https://twitter.com/shesek/status/976967775309762561

The capacity was increased (more than doubled). Now its a matter of utilizing this new capacity by upgrading to SegWit-supporting wallets.

Note that upgrading your own wallet to SegWit immediately saves you about 50% on mining fees, regardless of whether other network participants upgraded or not.

> The core developers (employed by Blockstream)

There are hundreds of Core developers; only about 6 of them are related to Blockstream. Your conspiracy theory does not hold up to reality.

> have intentionally kept the block size at 1MB

The block size has already been lifted to 2MB-4MB with SegWit.

> Blockstream ... support the product they're attempting to develop (lightening network layers)

Lightning Network was invented by people that have nothing to do with Blockstream, who founded their own company for that: https://lightning.engineering/team.html

There are 5 different teams developing Lightning Network implementations. Blockstream is merely responsible for the C implementation, they have no special control over Lightning.

> It's a red herring to claim larger blocks increase centralization when it's just data storage.

It's not just storage; the main issues are bandwidth, latency and IBD time. There are very real engineering limitations and trade-offs that have been discussed in depth over the years that you're just brushing off here. It's not as simple as you make it appear.