They appear to be included, with rationale that you can already include syntactically valid crap in an unprovable way: github.com/bitcoin/bitcoin/issues/320 Better then have syntactically invalid crap that is provable.
The outputs of this transaction seem to be the first syntactically incorrect scripts of the blockchain: blockchain.info/tx/ebc9fa1196a59e192352d76c0f6e73167046b9d37b8302b6bb6968dfd279b767?format=json, found by parsing everything locally. The transaction was made in 2013 for 0.1 BTC, which then became unspendable.
The first invalid script is just e.g. "script":"01", which says will push one byte into the stack, but then ends prematurely.
5660d06bd69326c18ec63127b37fb3b32ea763c3846b3334c51beb6a800c57d3 by 
Ciro Santilli 35 Updated 2025-01-29 +Created 1970-01-01
Ciro Santilli 35 Updated 2025-01-29 +Created 1970-01-01In this malformed Coinbase transaction, the mining pool "nicehash" produced a provably unspendable Bitcoin output script due to a bug, and therefore lost most of the entire block reward of 6.25 BTC then worth about $ 123,000.
The output is unspendable because it ends in a constant 0, the disassembly of the first and main output is this series of constants:and for the second smaller one:the third one being an OP_RETURN message.
0 017fed86bba5f31f955f8b316c7fb9bd45cb6cbc 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0aa21a9ed62ec16bf1a388c7884e9778ddb0e26c0bf982dada47aaa5952347c0993da 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0This event received some coverage:
a165c82cf21a6bae54dde98b7e00ab43b695debb59dfe7d279ac0c59d6043e24 by Ciro Santilli 35 Updated 2025-01-29 +Created 1970-01-01
Ciro Santilli 35 Updated 2025-01-29 +Created 1970-01-01Sister transaction of 4373b97e4525be4c2f4b491be9f14ac2b106ba521587dad8f134040d16ff73af with another variant of the XSS but without IF and
OP_FROMALTSTACK, thus making it spendable:OP_ADD OP_ADD 13 OP_EQUAL <large xss constant> OP_DROP Provably unspendable Bitcoin output script by Ciro Santilli 35 Updated 2025-01-29 +Created 1970-01-01
Ciro Santilli 35 Updated 2025-01-29 +Created 1970-01-01The opposite of a human-readable format.
BSHUNTER: Detecting and Tracing Defects of Bitcoin Scripts by Ciro Santilli 35 Updated 2025-01-29 +Created 1970-01-01
Ciro Santilli 35 Updated 2025-01-29 +Created 1970-01-01Authors: Peilin Zheng, Xiapu Luo, Zibin Zheng
Epic title.
In this project Ciro Santilli extracted (almost) all Git commit emails from GitHub with Google BigQuery! The repo was later taken down by GitHub. Newbs, censoring publicly available data!
Ciro also created a beautifully named variant with one email per commit: github.com/cirosantilli/imagine-all-the-people. True art. It also had the effect of breaking this "what's my first commit tracker": twitter.com/NachoSoto/status/1761873362706698469
GitHub Archive query showing hashed emails
. It was Ciro Santilli that made them hash the emails. They weren't hashed before he published the emails publicly.
All GitHub Commit Emails repo before takedown
. Screenshot from archive.is.Where blog is taken in a wide sense, including e.g. Medium, WordPress, Facebook, Twitter, etc., etc.
The main shortcoming of blogs is the lack of topic convergence across blogs. Each blog is a moderated castle. So who is the best user for a given topic, or the best content for a given tag, across the entire website?
The only reasonable free material we have for advanced subjects nowadays are university lecture notes.
While some of those are awesome, when writing a large content, no one can keep quality high across all sections, there will always be knowledge that you don't have which is enlightening. And Googlers are more often than not interested only in specific sections of your content.
Our website aims to make smaller subjects vertically curated across horizontal single author tutorials.
MIT calculus course UCLA calculus course
* Calculus <---> * Calculus
* Limit <---> * Limit
* Limit of a function
* Limit of a series <---> * Limit of a series
* Derivative <---> * Derivative
* L'Hôpital's rule
* Integral <---> * IntegralSome more links:
- prose.sh/ multiblog, the only feature is easy of publishing from CLI
Here is a very direct description of the system:Code 1. "Sample Bitcoin transaction graph" illustrates these concepts:
- each transaction (transaction is often abbreviated "tx") has a list of inputs, and a list of outputs
- each input is the output of a previous transaction. You verify your identity as the indented receiver by producing a digital signature for the public key specified on the output
- each output specifies the public key of the receiver and the value being sent
- the sum of output values cannot obvious exceed the sum of input values. If it is any less, the leftover is sent to the miner of the transaction as a transaction fee, which is an incentive for mining.
- once an output is used from an input, it becomes marked as spent, and cannot be reused again. Every input uses the selected output fully. Therefore, if you want to use an input of 1 BTC to pay 0.1 BTC, what you do is to send 0.1 BTC to the receiver, and 0.9 BTC back to yourself as change. This is why the vast majority of transactions has two outputs: one "real", and the other change back to self.
tx0: magic transaction without any inputs, i.e. either Genesis block or a coinbase mining reward. Since it is a magic transaction, it produces 3 Bitcoins from scratch: 1 inout0and 2 inout1. The initial value was actually 50 BTC and reduced with time: Section "Bitcoin halvening"tx1: regular transaction that takes:Since this is a regular transaction, no new coins are produced.- a single input from
tx0 out0, with value 1 - produces two outputs:
out0for value 0.5out1for value 0.3
- this means that there was 0.2 left over from the input. This value will be given to the miner that mines this transaction.
- a single input from
tx2: regular transaction with a single input and a single output. It uses up the entire input, leading to 0 miner fees, so this greedy one might (will?) never get mined.tx3: regular transaction with two inputs and one output. The total input is 2.3, and the output is 1.8, so the miner fee will be 0.5
tx1 tx3
tx0 +---------------+ +---------------+
+----------+ | in0 | | in0 |
| out0 |<------out: tx0 out0 | +------out: tx1 out1 |
| value: 1 | +---------------+ | +---------------+
+----------+ | out0 | | | in1 |
| out1 |<-+ | value: 0.5 | | +----out: tx2 out0 |
| value: 2 | | +---------------+ | | +---------------+
+----------+ | | out1 |<-+ | | out1 |
| | value: 0.3 | | | value: 1.8 |
| +---------------+ | +---------------+
| |
| |
| |
| tx2 |
| +---------------+ |
| | in0 | |
+----out: tx0 out1 | |
+---------------+ |
| out0 |<---+
| value: 2 |
+---------------+Since every input must come from a previous output, there must be some magic way of generating new coins from scratch to bootstrap the system. This mechanism is that when the miner mines successfully, they get a mining fee, which is a magic transaction without any valid inputs and a pre-agreed value, and an incentive to use their power/compute resources to mine. This magic transaction is called a "coinbase transaction".
The key innovation of Bitcoin is how to prevent double spending, i.e. use a single output as the input of two different transactions, via mining.
For example, what prevents me from very quickly using a single output to pay two different people in quick succession?
The solution are the blocks. Blocks discretize transactions into chunks in a way that prevents double spending.
A block contains:
- a list of transactions that are valid amongst themselves. Notably, there can't be double spending within a block.People making transactions send them to the network, and miners select which ones they want to add to their block. Miners prefer to pick transactions that are:
- small, as less bytes means less hashing costs. Small generally means "doesn't have a gazillion inputs/outputs".
- have higher transaction fees, for obvious reasons
- the ID of its parent block. Blocks therefore form a linear linked list of blocks, except for temporary ties that are soon resolved. The longest known list block is considered to be the valid one.
- a nonce, which is an integer chosen "arbitrarily by the miner"
For a block to be valid, besides not containing easy to check stuff like double spending, the miner must also select a nonce such that the hash of the block starts with N zeroes.
For example, considering the transactions from Code 1. "Sample Bitcoin transaction graph", the block structure shown at Code 2. "Sample Bitcoin blockchain" would be valid. In it
block0 contains two transactions: tx0 and tx1, and block1 also contains two transactions: tx2 and tx3. block0 block1 block2
+------------+ +--------------+ +--------------+
| prev: |<----prev: block0 |<----prev: block1 |
+------------+ +--------------+ +--------------+
| txs: | | txs: | | txs: |
| - tx0 | | - tx2 | | - tx4 |
| - tx1 | | - tx3 | | - tx5 |
+------------+ +--------------+ +--------------+
| nonce: 944 | | nonce: 832 | | nonce: 734 |
+------------+ +--------------+ +--------------+
nonces are on this example arbitrary chosen numbers that would lead to a desired hash for the block.block0 is the Genesis block, which is magic and does not have a previous block, because we have to start from somewhere. The network is hardcoded to accept that as a valid starting point.Now suppose that the person who created Clearly, this transaction would try to spend Notably, it is not possible that
tx2 had tried to double spend and also created another transaction tx2' at the same time that looks like this: tx2'
+---------------+
| in0 |
| out: tx0 out1 |
+---------------+
| out0 |
| value: 2 |
+---------------+tx0 out1 one more time in addition to tx2, and should not be allowed! If this were attempted, only the following outcomes are possible:block1containstx2. Then whenblock2gets made, it cannot containtx2', becausetx0 out1was already spent bytx2block1containstx2'.tx2cannot be spent anymore
block1 contains both tx2 and tx2', as that would make the block invalid, and the network would not accept that block even if a miner found a nonce.Since hashes are basically random, miners just have to try a bunch of nonces randomly until they find one that works.
The more zeroes, the harder it is to find the hash. For example, on the extreme case where N is all the bits of the hash output, we are trying to find a hash of exactly 0, which is statistically impossible. But if e.g. N=1, you will in average have to try only two nonces, N=2 four nonces, and so on.
The value N is updated every 2 weeks, and aims to make blocks to take 10 minutes to mine on average. N has to be increased with time, as more advanced hashing hardware has become available.
Once a miner finds a nonce that works, they send their block to the network. Other miners then verify the block, and once they do, they are highly incentivized to stop their hashing attempts, and make the new valid block be the new parent, and start over. This is because the length of the chain has already increased: they would need to mine two blocks instead of one if they didn't update to the newest block!
Therefore if you try to double spend, some random miner is going to select only one of your transactions and add it to the block.
They can't pick both, otherwise their block would be invalid, and other miners wouldn't accept is as the new longest one.
Then sooner or later, the transaction will be mined and added to the longest chain. At this point, the network will move to that newer header, and your second transaction will not be valid for any miner at all anymore, since it uses a spent output from the first one that went in. All miners will therefore drop that transaction, and it will never go in.
The goal of having this mandatory 10 minutes block interval is to make it very unlikely that two miners will mine at the exact same time, and therefore possibly each one mine one of the two double spending transactions. When ties to happen, miners randomly choose one of the valid blocks and work on top of it. The first one that does, now has a block of length L + 2 rather than L + 1, and therefore when that is propagated, everyone drops what they are doing and move to that new longest one.
Converts RNA to DNA, i.e. the inverse of transcription. Found in viruses such as Retrovirus, which includes e.g. HIV.
How to write technical help requests and bug reports by Ciro Santilli 35 Updated 2025-01-29 +Created 1970-01-01
Ciro Santilli 35 Updated 2025-01-29 +Created 1970-01-01Ciro Santilli often sees all those genius who are much smarter than him making shitty forum/mailing list posts, they need to learn this:
- The apparently most important one liner error message must appear in the title, and fuller apparently relevant logs must appear on the body
- You must always give the version of the software that you are using as either a tag or git SHAThese are an important part of the minimal working example.
- For build errors, you must give your OS and compiler version and version of any relevant external library
Pinned article: ourbigbook/introduction-to-the-ourbigbook-project
Welcome to the OurBigBook Project! Our goal is to create the perfect publishing platform for STEM subjects, and get university-level students to write the best free STEM tutorials ever.
Everyone is welcome to create an account and play with the site: ourbigbook.com/go/register. We belive that students themselves can write amazing tutorials, but teachers are welcome too. You can write about anything you want, it doesn't have to be STEM or even educational. Silly test content is very welcome and you won't be penalized in any way. Just keep it legal!
We have two killer features:
- topics: topics group articles by different users with the same title, e.g. here is the topic for the "Fundamental Theorem of Calculus" ourbigbook.com/go/topic/fundamental-theorem-of-calculusArticles of different users are sorted by upvote within each article page. This feature is a bit like:
- a Wikipedia where each user can have their own version of each article
- a Q&A website like Stack Overflow, where multiple people can give their views on a given topic, and the best ones are sorted by upvote. Except you don't need to wait for someone to ask first, and any topic goes, no matter how narrow or broad
This feature makes it possible for readers to find better explanations of any topic created by other writers. And it allows writers to create an explanation in a place that readers might actually find it.
Figure 1. Screenshot of the "Derivative" topic page. View it live at: ourbigbook.com/go/topic/derivative - local editing: you can store all your personal knowledge base content locally in a plaintext markup format that can be edited locally and published either:This way you can be sure that even if OurBigBook.com were to go down one day (which we have no plans to do as it is quite cheap to host!), your content will still be perfectly readable as a static site.
- to OurBigBook.com to get awesome multi-user features like topics and likes
- as HTML files to a static website, which you can host yourself for free on many external providers like GitHub Pages, and remain in full control
Figure 2. You can publish local OurBigBook lightweight markup files to either OurBigBook.com or as a static website.
Figure 3. Visual Studio Code extension installation.
Figure 4. Visual Studio Code extension tree navigation.
Figure 5. . You can also edit articles on the Web editor without installing anything locally. Video 3. Edit locally and publish demo. Source. This shows editing OurBigBook Markup and publishing it using the Visual Studio Code extension.Video 4. OurBigBook Visual Studio Code extension editing and navigation demo. Source. - Internal cross file references done right:
- Infinitely deep tables of contents:
Figure 6. Dynamic article tree with infinitely deep table of contents.Live URL: ourbigbook.com/cirosantilli/chordateDescendant pages can also show up as toplevel e.g.: ourbigbook.com/cirosantilli/chordate-subclade
All our software is open source and hosted at: github.com/ourbigbook/ourbigbook
Further documentation can be found at: docs.ourbigbook.com
Feel free to reach our to us for any help or suggestions: docs.ourbigbook.com/#contact