Given a matrix with metric signature containing positive and negative entries, the indefinite orthogonal group is the set of all matrices that preserve the associated bilinear form, i.e.:
Note that if , we just have the standard dot product, and that subcase corresponds to the following definition of the orthogonal group: Section "The orthogonal group is the group of all matrices that preserve the dot product".
As shown at all indefinite orthogonal groups of matrices of equal metric signature are isomorphic, due to the Sylvester's law of inertia, only the metric signature of matters. E.g., if we take two different matrices with the same metric signature such as:
and:
both produce isomorphic spaces. So it is customary to just always pick the matrix with only +1 and -1 as entries.
Iterative in-order by Ciro Santilli 40 Updated 2025-07-16
This is a bit harder than iterative pre-order: now we have to check if there is a left or right element or not:
  • (START) push current
  • if there is left:
    • move left
  • else:
    • (ELSE) pop
    • visit
    • if there is right
      • move right
      • GOTO START
    • else:
      • GOTO ELSE
The control flow can be slightly simplified if we allow NULLs: www.geeksforgeeks.org/inorder-tree-traversal-without-recursion/
WebGL by Ciro Santilli 40 Updated 2025-07-16
HTML snippet:
new class extends OurbigbookCanvasDemo {
  init() {
    super.init('webgl', {context_type: 'webgl'});
    this.ctx.viewport(0, 0, this.ctx.drawingBufferWidth, this.ctx.drawingBufferHeight);
    this.ctx.clearColor(0.0, 0.0, 0.0, 1.0);
    this.vertexShaderSource = `
#version 100
precision highp float;
attribute float position;
void main() {
  gl_Position = vec4(position, 0.0, 0.0, 1.0);
  gl_PointSize = 64.0;
}
`;

    this.fragmentShaderSource = `
#version 100
precision mediump float;
void main() {
  gl_FragColor = vec4(0.18, 0.0, 0.34, 1.0);
}
`;
    this.vertexShader = this.ctx.createShader(this.ctx.VERTEX_SHADER);
    this.ctx.shaderSource(this.vertexShader, this.vertexShaderSource);
    this.ctx.compileShader(this.vertexShader);
    this.fragmentShader = this.ctx.createShader(this.ctx.FRAGMENT_SHADER);
    this.ctx.shaderSource(this.fragmentShader, this.fragmentShaderSource);
    this.ctx.compileShader(this.fragmentShader);
    this.program = this.ctx.createProgram();
    this.ctx.attachShader(this.program, this.vertexShader);
    this.ctx.attachShader(this.program, this.fragmentShader);
    this.ctx.linkProgram(this.program);
    this.ctx.detachShader(this.program, this.vertexShader);
    this.ctx.detachShader(this.program, this.fragmentShader);
    this.ctx.deleteShader(this.vertexShader);
    this.ctx.deleteShader(this.fragmentShader);
    if (!this.ctx.getProgramParameter(this.program, this.ctx.LINK_STATUS)) {
      console.log('error ' + this.ctx.getProgramInfoLog(this.program));
      return;
    }
    this.ctx.enableVertexAttribArray(0);
    var buffer = this.ctx.createBuffer();
    this.ctx.bindBuffer(this.ctx.ARRAY_BUFFER, buffer);
    this.ctx.vertexAttribPointer(0, 1, this.ctx.FLOAT, false, 0, 0);
    this.ctx.useProgram(this.program);
  }
  draw() {
    this.ctx.clear(this.ctx.COLOR_BUFFER_BIT);
    this.ctx.bufferData(this.ctx.ARRAY_BUFFER, new Float32Array([Math.sin(this.time / 60.0)]), this.ctx.STATIC_DRAW);
    this.ctx.drawArrays(this.ctx.POINTS, 0, 1);
  }
}
Blockchain.info by Ciro Santilli 40 Updated 2025-07-16
TODO who owns it? Are they reliable?
This helper dumps a transaction JSON to a binary:
bitcoin-tx-out-scripts() (
    # Dump data contained in out scripts. Remove first 3 last 2 bytes of
    # standard transaction boilerplate.
    h="$1"
    echo curl "https://blockchain.info/tx/${h}?format=json" |
    jq '.out[].script' tmp.json |
    sed 's/"76a914//;s/88ac"//' |
    xxd -r -p > "${h}.bin"
)
Their API limit witout key is 1 query per 10 seconds!!!
BitcoinStrings.com by Ciro Santilli 40 Updated 2025-07-16
bitcoinstrings.com has all strings -n20 strings, we can obtain the whole thing and clean it up a bit with:
wget -O all.html https://bitcoinstrings.com/all
cp all.html all-recode.html
recode html..ascii all-recode.html
awk '!seen[$0]++' all-recode.html > all-uniq.html
awk to skip the gazillion "mined by message" repeats.
A lot of in that website stuff appears to be cut up at the 20 mark. As shown in Force of Will, this is possibly because they didn't use -w in strings -n20, and the text after the newlines was less than 20 characters.
That website can be replicated by downloading the Bitcoin blockchain locally, then:
cd .bitcoin/blocks
for f in blk*.dat; do strings -n20 -w $f | awk '!seen[$0]++' > ${f%.dat}.txt; done
tail +n1 *.txt
Remove most of the binary crap:
head -n-1 *.txt | grep -e '[. ]' | grep -iv 'mined by' | less
Satoshi uploader by Ciro Santilli 40 Updated 2025-07-16
The uploader, and its accompanying downloader, are Python programs stored in the blockchain itself. They are made to upload and download arbitrary data into the blockchain via RPC.
These scripts were notably used for: illegal content of block 229k. The script did not maintain its popularity much after this initial surge up loads, likely all done by the same user: there are very very few uploads done after block 229k with the Satoshi uploader.
Our choice of name as "Satoshi uploader" is copied from A Quantitative Analysis of the Impact of Arbitrary Blockchain Content on Bitcoin by Matzutt et al. (2018) because the scripts are Copyrighted Satoshi Nakamoto on the header comment, although as mentioned at Hidden surprises in the Bitcoin blockchain by Ken Shirriff (2014) this feels very unlikely to be true.
A more convenient version of those scripts that can download directly from blockchain.info without the need for a full local node can be found at: github.com/cirosantilli/bitcoin-inscription-indexer/blob/master/download_tx_consts.py by using the --satoshi option. E.g. with it you can download the uploader script with:
./download_tx_consts.py --satoshi 4b72a223007eab8a951d43edc171befeabc7b5dca4213770c88e09ba5b936e17
mv 4b72a223007eab8a951d43edc171befeabc7b5dca4213770c88e09ba5b936e17.bin uploader.py
The scripts can be found in the blockchain at:
The uploader script uses its own cumbersome data encoding format, which we call the "Satoshi uploader format". The is as follows:
This means that if we want to index certain file types encoded in this format, a good heuristic is to skip the first 9 bytes (4 size, 4 CRC, 1 OP_1) and look for file signatures.
Let's try out the downloader to download itself. First you have to be running a Bitcoin Core server locally. Then, supposing .bitcon/bitoin.conf containing:
rpcuser=asdf
rpcpassword=qwer
server=1
txindex=1
we run:
git clone git://github.com/jgarzik/python-bitcoinrpc.git
git -C python-bitcoinrpc checkout cdf43b41f982b4f811cd4ebfbc787ab2abf5c94a
wget https://gist.githubusercontent.com/shirriff/64f48fa09a61b56ffcf9/raw/ad1d2e041edc0fb7ef23402e64eeb92c045b5ef7/bitcoin-file-downloader.py
pip install python-bitcoinrpc==1.0
BTCRPCURL=http://asdf:qwer@127.0.0.1:8332 \
  PYTHONPATH="$(pwd)/python-bitcoinrpc:$PYTHONPATH" \
  python3 bitcoin-file-downloader.py \
  6c53cd987119ef797d5adccd76241247988a0a5ef783572a9972e7371c5fb0cc
worked! The source of the downloader script is visible! Note that we had to wait for the sync of the entire blockchain to be fully finished for some reason for that to work.
Other known uploads in Satoshi format except from the first few:
  • tx 89248ecadd51ada613cf8bdf46c174c57842e51de4f99f4bbd8b8b34d3cb7792 block 344068 see ASCII art
  • tx 1ff17021495e4afb27f2f55cc1ef487c48e33bd5a472a4a68c56a84fc38871ec contains the ASCII text e5a6f30ff7d43f96f61af05efaf96f869aa072b5a071f32a24b03702d1dcd2a6. This number however is not a known transaction ID in the blockchain, and has no Google hits.
This is likely a system that uploads text to the blockchain.
One example can be seen on the Marijuana plant.
Messages are uploaded one line per transaction, and thus may be cut up on the blk.txt, and possibly even out of order.
But because each line starts with j( you can generally piece things up regardless.
TODO identify. The first occurrence seems to be in tx e8c61e29c6b829e289f8d0fc95f9eb2eb00c89c85cfa3a9c700b15805451ae6a:
j(DOCPROOF@?pnvf=!;AG
Due to the failures of earlier generations, which believed that would quickly achieve AGI, leading to the AI winters, 21st researchers have been very afraid of even trying it, rather going only for smaller subste problems like better neural network designs, at the risk of being considered a crank.
While there is fundamental value in such subset problems, the general view to the final goal is also very important, we will likely never reach AI without it.
This is voiced for example in Superintelligence by Nick Bostrom (2014) section "Opinions about the future of machine intelligence" which in turn quotes Nils Nilsson:
There may, however, be a residual cultural effect on the AI community of its earlier history that makes many mainstream researchers reluctant to align themselves with over-grand ambition. Thus Nils Nilsson, one of the old-timers in the field, complains that his present-day colleagues lack the boldness of spirit that propelled the pioneers of his own generation:
Concern for "respectability" has had, I think, a stultifying effect on some AI researchers. I hear them saying things like, "AI used to be criticized for its flossiness. Now that we have made solid progress, let us not risk losing our respectability." One result of this conservatism has been increased concentration on "weak AI" - the variety devoted to providing aids to human
thought - and away from "strong AI" - the variety that attempts to mechanize human-level intelligence
Nilsson’s sentiment has been echoed by several others of the founders, including Marvin Minsky, John McCarthy, and Patrick Winston.

There are unlisted articles, also show them or only show them.