February 2023 - cypherpunks@lists.ogf.org

Nose-cone plans for the F-22 fighter jet
by professor rat 05 Feb '23

05 Feb '23

Wanted by a friend of my sister's daughter whose doing a school project on Airforce blueprints in the public-domain. Can pay a small stipend for encrypted mail if required. Blacknet was the basis for the hardest rocking blues-punk application in the world at the time. With your help we can make that coding live, breath and JUMP again! No more small-change shit about Mother Hen, diplomatic cables gossip. We're on a mission from Mong.

1 0

SpyVeillance: US Shoots Down Chinese Spy Balloon Over US Airspace
by grarpamp 04 Feb '23

04 Feb '23

Watch: US Fighter Jets Shoot Down Chinese Spy Balloon Off Carolinas Watch Live: US Restricts Airspace Near Myrtle Beach For "National Defense Airspace" Operation * * * US fighter jets have shot down the Chinese spy balloon off the Carolina coast. The best view so far of the spy balloon being shot down. Best video so far of the Chinese spy balloon being shot down pic.twitter.com/MrWB403OqJ — BNO News Live (@BNODesk) February 4, 2023 The balloon is falling back to Earth. Here comes the recovery vessel. The USS Carter Hall (LSD-50) (along with numerous skipper sized surface craft, I assume) is arriving in the splashdown zone for balloon recovery. pic.twitter.com/dq7lWrHzKm — The Intel Crab (@IntelCrab) February 4, 2023 * * * Shortly after President Biden reportedly said, "we are going to take care of it," referring to the Chinese spy balloon that is calmly drifting across US airspace, the FAA has shut down three airports and closed airspace in parts of North and South Carolina: Fighter jets are circling the spy balloon. F-22s returning after a brief holding orbit. pic.twitter.com/bRZ6uq7Knl — The Intel Crab (@IntelCrab) February 4, 2023 CCP balloon over North Myrtle Beach ‼️ Jets are circling ‼️ pic.twitter.com/BaG5VasQUp — SouthernFried (@southenFried) February 4, 2023 Video of what appears to be fighter, jets circling the China balloon above Conway, South Carolina pic.twitter.com/lvjW6WX2Gp — Andy Shain (@AndyShain) February 4, 2023 A US military surveillance plane is circling offshore of North Carolina. A vessel with a large crane might be headed to an area where the military might shoot down the balloon. The USS Carter Hall (LSD-50) is headed south from Beaufort, NC. May be used for balloon recovery efforts. Ship has a 30 ton crane on board. pic.twitter.com/nsCYQ1Tpqb — The Intel Crab (@IntelCrab) February 4, 2023 * * * A suspected Chinese surveillance balloon appears to be heading toward North Carolina, according to ABC News, citing a senior US official familiar with the situation. That official said the US would probably shoot the balloon down over the Atlantic Ocean and retrieve it. Within the last hour, numerous Twitter users have uploaded footage of what appears to be the Chinese balloon floating above North Carolina. Chinese balloon over Shelby North Carolina at 9:35 AM. Moving west south west. pic.twitter.com/EEj8vGk6La — Anne Eskridge (@AnneEskridge1) February 4, 2023 Here’s the #ChineseSpyBallon over Easley, SC around 8:45am this AM. The trajectory forecast I posted last night seems right on. The balloon should be visible anywhere in southern North Carolina and northern South Carolina at some point over the next 6-8 hours. 📸 Jason McDowell. pic.twitter.com/6hspFrIXqG — Ed Piotrowski (@EdPiotrowski) February 4, 2023 Chinese Spy Balloon currently SW of Polkville NC approximately over Kingston NC 9:44 AM #ChinaSpyBalloon @wxbrad pic.twitter.com/8OjdDwsgmN — Brian Branch (@BrianBranch13) February 4, 2023 Local police tell residents don't shoot their guns at the giant balloon. The Gastonia Police Department is asking residents to not shoot at the Chinese spy balloon if it flies over North Carolina pic.twitter.com/lD9VkI299M — Joe Bruno (@JoeBrunoWSOC9) February 4, 2023 On Friday, we cited Capital Weather Gang, who accurately predicted the balloon's trajectory while it was floating above the Midwest. Now updated predictions for Saturday morning show the balloon might be headed toward the Atlantic. The balloon's payload is approximately 90 feet long, or the length of two motorhomes, and the balloon itself is much larger. Here's one of the clearest views of the balloon. And there might be more balloons. We noted last night: "We are seeing reports of a balloon transiting Latin America," Brig. Gen. Pat Ryder, a Pentagon spokesperson, told Fox News Friday night. "We now assess it is another Chinese surveillance balloon." US officials have not ruled out shooting the balloon down. That might happen as soon as the balloon moves offshore into the Atlantic. Time for Space Force to shine.

1 1

[old] Acoustics-based Physical Key Inference
by Undescribed Horrific Abuse, One Victim & Survivor of Many 04 Feb '23

04 Feb '23

popped up in reddit and twitter today, from 3 years ago https://gwern.net/doc/technology/2020-ramesh.pdf Physical locks are one of the most prevalent mechanisms for secur- ing objects such as doors. While many of these locks are vulnerable to lock-picking, they are still widely used as lock-picking requires specific training with tailored instruments, and easily raises suspi- cion. In this paper, we propose SpiKey, a novel attack that signifi- cantly lowers the bar for an attacker as opposed to the lock-picking attack, by requiring only the use of a smartphone microphone to in- fer the shape of victim’s key, namely bittings (or cut depths) which form the secret of a key. When a victim inserts his/her key into the lock, the emitted sound is captured by the attacker’s microphone. SpiKey leverages the time difference between audible clicks to ulti- mately infer the bitting information, i.e., shape of the physical key. As a proof-of-concept, we provide a simulation, based on real-world recordings, and demonstrate a significant reduction in search space from a pool of more than 330 thousand keys to three candidate keys for the most frequent case. · Security and privacy → Side-channel analysis and counter- measures; · Hardware → Sound-based input / output. Side-channel Attacks; Acoustic Inference; Physical Key Security

1 1

One wopersyn's cryptoanarchist terrorist is another ones freedom-fighter
by professor rat 04 Feb '23

04 Feb '23

Unconstrained anarchy with good intent? What kind of terrorists are you!? https://decrypt.co/120489/nouns-comic-books-turn-ethereum-nfts-unconstraine… Reposts not NFT's out the wazoo

2 1

USA 2024 Elections Thread
by professor rat 03 Feb '23

03 Feb '23

Maybe ' Windy City Makeover " is a little out-of-date by the time it gets here - but last time I looked Chicago didn't look like a ' complete failure '. But then I have a psychiatric diagnosis. I could be hallucinating.

1 0

Assassination Politics
by professor rat 03 Feb '23

03 Feb '23

A simple benchmark for actual intelligence from a C3-PO type droid will be their embrace of APster as the Killer App. Every slave being in a state of legitimate revolt against every master - full-spectrum-revolt! Arguably Mongo didn't pass the Turing Test till 2003 TIMOTHY " An anonymous computerized market will even make possible abhorrent markets for assassinations and extortion " C. MAY 1992 TIM " I guess now that the Pentagon is setting up a murder pool it can't be illegal for us to do it " MAY. 2003 Mong placed his first APster bet against Paul Wolfowitz that year.

1 0

POLICE CARS BURNT in solidarity with anarchist assassin
by professor rat 03 Feb '23

03 Feb '23

Claim for the incendiary attack against some cars of the local police https://anarchistnews.org/content/police-cars-burnt-solidarity-w-alfredo-co… Reposts taking direct action against the heart of the head of the state

1 0

Curing The Psychiatric Patients On This List [re: Spammers, Entrapment, Etc]
by grarpamp 03 Feb '23

03 Feb '23

Gunnar et al... Seek psychiatric help. Take Karl, ProfRat, and Juan with you. Make plans, right now, this Friday. To Mexico. Anarchapulco, next week. Seek Shamen. Do Ayhuasca. Get an Exorcism. Dance naked. Fuck whales. Whatever it takes. Repeat until cured.

1 0

[ot][spam][crazy][log] making autocode
by Undescribed Horrific Abuse, One Victim & Survivor of Many 03 Feb '23

03 Feb '23

ok with big 6b diff model it likely approaches being easy enough to make this that one could do it when too confused to do it imagining a simple command lines script something like code fixed bugs 0755 code would parse “*” as a commit message for every file in the repository and produce updates. - problem: some files would need no updates. maybe output confidence of the model would indicate this? likely. files with 7nrelated changes would have poor confidence from not having rlevant trained data. - problem: creation of new files, what to name them? ideas: the diff model may contain 8nstances of file renaming that could be used to extract likely file names. the user could manually specify new files by touching them. if the model was trained on full commits in sequence the end of a commit could be used to complete a novel one. beam exploration could make that easier, to find a following commit with the same message. i think beam exploration would be the most reliable — where the model makes up data in the wrong order and backtracks when wrong. it seems to make sense to start off with the manual approach or none at all. lots of ram needed. idea: - given many files at once, larger batches could be run to speed inference. it could diff every file at once. clear steps? ummmm, - download the model on a system. this likely needs 25G of free space and addressable memory. (side pursuit could be adding model to some public inference thing) - form code to craft prompts for the model. i believe their format is like: <NME> hello_world.py <BEF> ADDFILE <MSG> hello world example <DFF> - those are the big bits! likely make script in python to familiarly load model. probably easier to walk the filetree to enumerate files than use git commands, but git can work too. - for each generated diff, apply it to the file. it’s probably fine to write out a single patchfile. i like refactoring, so i’m curious whether the training process preserved renames. note: it’s valuable to have it create code that adapts itself so it can be used for other tasks. this means getting or generating data for the other tasks, hooking its achitecture, and running training loops on injected adapters only. runnjng training loops on programmatic data sounds helpful in general

1 7

carperai released large diff models last week
by Undescribed Horrific Abuse, One Victim & Survivor of Many 03 Feb '23

03 Feb '23

https://carper.ai/diff-models-a-new-way-to-edit-code/ [full of links that i did not paste through] Diff Models – A New Way to Edit Code Jan 27, 2023 | Uncategorized CarperAI is releasing a series of diff models—models trained to predict a code diff, trained on millions of commits scraped from GitHub. We are releasing 3 models of different sizes, all fine-tuned from Salesforce’s CodeGen code synthesis models: diff-codegen-350m diff-codegen-2b diff-codegen-6b The dataset of diffs we scraped to train these models will be released separately in the near future. We hope these models will be useful for suggesting intelligent changes to existing code, controllable through a specific commit message describing the change. We will continue to iterate on our diff models, so stay tuned for further releases. Read on for more details on how the models were trained, with benchmark results! Introduction A diff model is an autoregressive language model trained on edits to a piece of text, formatted in Unified Diff Format. These diff models can suggest, given a section of text and a description of the desired change, an intelligent change to the text that fits the description, marking the lines added, changed, and deleted in diff format. The primary use case for these models is for suggesting changes to code—as such, the models we are releasing are fine-tuned versions of models already trained on code datasets. In comparison to few-shot prompting of normal code generation models, diff models are specialized for suggesting intelligent changes to existing code, particularly longer pieces of code and where a change is required to follow some natural language text description (provided in the form of a commit message). Prior work by Microsoft Research (Li et al., 2022) and OpenAI (Ray and McCandlish 20201; Lehman et al. 2022) identified the potential for diffs as a source of rich data on how to make changes to code, and trained models on diffs, but did not release any diff models or publish an analysis of how to obtain good performance. 1 Alex Ray and Sam McCandlish, OpenAI. Independent contribution: Training diff models, 2020. A Diff Dataset Our dataset for this fine-tune consists of commits from GitHub, obtained using the Google BigQuery Public Dataset, a public up to date snapshot of a huge number of open-source GitHub repositories. We took this dataset and filtered using BigQuery on the number of stars in the repository to exclude repos with less than 100 stars, and further restricted the query to only repositories with open-source non-copyleft licenses (e.g. MIT, Apache, etc) and commits with more than 10 characters in the commit message. We also restricted ourselves to a list of 22 popular programming, scripting, and markup languages, including Python, HTML, Bash scripts, SQL, C++, etc. This resulted in a dataset of 19 million commits after filtering. At this point we had the commit hashes, repository names, and other metadata for the commits we wanted in our dataset. We then ran git clone on every repository in our dataset and used a Python script to obtain the raw code files before the diff is applied, together with the diff itself in Unified Diff Format. These were processed into Apache Parquet format using Dask with Apache Arrow to efficiently get it into a dataframe format, with one row per file changed (e.g. if a diff affected multiple files it was split up), and included only rows where each file + diff was short enough to fit into the context of the language model. >From there, we processed the dataset into EleutherAI’s lm_dataformat, a utility to create compressed data files for efficient language model training. The final format of the data seen by the language model consisted of the filename changed by the diff, the file before changes, the commit message, and the diff itself, all concatenated together with delineating tags in between: <NME> {filename} <BEF> {file_before_changes} <MSG> {commit_message} <DFF> {diff} The model is then typically prompted with everything up to <DFF>, but you can also optionally include the section heading of the unified diff format immediately after <DFF>, which specifies which lines exactly the model should change. For example, appending @@ -1,3 +1,9 @@ after the diff tag would instruct the model to change the file at line 1, adding 9 - 3 = 6 lines. We do not add these four tags as special tokens, since we prioritized leaving the tokenizer unchanged. The final dataset consisted of 1.4 million files from 19 million commits, which resulted in 1.086 billion tokens after tokenizing with a modified GPT-2 tokenizer to include whitespace tokens—an average of 888 tokens per sample. Fine-tuning CodeGen The model suite we worked with as a base was Salesforce’s CodeGen series of models, which are decoder-only transformer language models trained to predict the next token in a sequence. These models were first pre-trained on The Pile, an 800GB dataset of diverse text released by EleutherAI, and then further trained on a large dataset of permissively licensed code from GitHub BigQuery in 6 programming languages, before finally being trained on Python only code from the same source. Note that the code in these pre-training datasets will inevitably overlap to some degree with our diff dataset, although they do not contain diffs. Salesforce have released variants of their models at 4 scales (350M, 2B, 6B, and 16B parameters) with 3 variants at each scale corresponding to the 3 different stages of pre-training described above. We chose to fine-tune the “mono” variants at each model scale, meaning the version trained on Python only code in addition to multi-language code. In order to fine-tune these models on our diff dataset, we used HuggingFace’s standard fine-tuning script with slight modifications to customize to CodeGen’s architecture, using the default hyperparameters and without freezing any layers. To pre-process the data we concatenated each sample (file with changes) together in the format described above and cut it into chunks of 2048 tokens (the context length of the CodeGen models). We then fine-tuned all of the model sizes with this dataset as an initial trial run and baseline for further experiments. For all fine-tuning experiments in this post, we used 64 Nvidia A100 GPUs—we thank Stability AI for access to their compute resources! To test a range of hyperparameters, we did a 12 run sweep with the 350m model across a range of learning rates and batch sizes, and settled on a learning rate of 3e-5 and a batch size of 1024 samples. Token Masking We then experimented with masking tokens in the loss computation, as described in the ELM paper. Specifically, we include only the tokens in the diff (including the tag <DFF>) in the loss, which is intended to encourage the model to predict the diff and not memorize the file and commit message. For example, we expect that filenames in <NME> and file contexts in <BEF> are given by the prompt, while <DFF> is the only goal in the diff generation. Therefore, it is natural to ignore unrelated prediction targets and exclude tokens before <DFF> in the computation of the loss function. We fine-tuned the full suite of models with this modification to compare the results across model scale. File Truncation We also experimented with different ways of truncating the file before changes to fit more of it into the context length. Without any truncation, roughly half of the files in the original dataset fit into the 2048 context length, for a total of 1.086 billion tokens. If we crop the file before changes to only contain the lines in the diff file, we can then fit 95% of the original dataset in the context, for a total of 2.181 billion tokens (see Figure 1). We hoped that including the extra data at the cost of some context in the file being changed would improve the model’s performance. However, we found that this experiment resulted in a model significantly worse than without truncation, likely because being able to see an entire class/function that a change relies on is important for modelling. Figure 1: Histograms of the samples in the dataset, ordered by length of file in tokens on the x-axis. (left) The baseline dataset, showing that the 2048 context length of our language models cuts off around 50% of the files. (right) The result of truncating the code file before changes to only contain lines altered by the diff and surrounding context. Results To evaluate our models, we test their bug fixing capabilities on two tasks: 4-Parity, a simple toy benchmark where the model is required to fix basic bugs in a Python function to calculate the parity of a 4-bit sequence, and a more complex dataset of many synthetic and real Python bugs scraped from GitHub repositories by He et al. (2022). These benchmarks provide a simple testbed for whether diff LLMs can make multiple coordinated and effective changes to code. For 4-Parity, we generate completions using a prompt consisting of the original function followed by the commit message <MSG> # Fixed bugs. We generate 3200 completions for each model, apply the resulting diff patches to the original function, execute the generated code and report the % of the generations where the generated 4-Parity function is correct across all test cases, at the best model temperature from {0.7, 0.8. 0.9}. We report results across 1-5 bugs synthetically introduced to the original function. For the latter task of real Python bugs, we filter the dataset down to 1000 bugs across several bug fixing problems (e.g. a wrong binary operator and incorrect variable name problem), where we generate a diff for each bug and measure the exact string match accuracy between the generated function after applying the diff, and the correct (bug-free) function. The commit message for this task is Fix {bug_class}, where the bug class might be, for example, “incorrect binary operator”. Note that in this case we do not execute the generated code to test it, since these bugs are scraped from many different GitHub repositories and execution would be impractical. The results from 4-Parity, shown in Figure 2, demonstrate that our diff models can perform basic bug fixing at comparable skill to the CodeGen models, which are prompted with the bugged function followed by #Fixed bugs. There is a clear performance increase with scale, and the 350M diff model performs better at the bug fixing task. We can also see that the loss masking approach described above results in significantly better diff models on this task. Figure 2: Results from evaluating our diff models on the simple 4-Parity bug fixing task. The x-axis is the number of progressively introduced bugs in the 4-Parity function. The bolded lines show our best diff models, while the dot-dash lines show the CodeGen models we used as a starting point, and the baseline models are trained without loss masking. Table 1 shows the results from our diff models on the synthetic + real bugs benchmark, using the pass@k metric with k = 1 (defined as the fraction of problems solved when the model generates k code samples per problem. We can see that the masked diff models perform slightly better Model pass@1 - Synthetic + Real Bugs Baseline Diff 350M 0.9% Baseline Diff 2B 1.9% Baseline Diff 6B 2.3% Masked Diff 350M 1.7% Masked Diff 2B 3.9% Masked Diff 6B 4.8% CodeGen 350M 2.0% CodeGen 2B 3.8% CodeGen 6B 4.5% Table 1: Pass@1 (Chen et al., 2021) on the real + synthetic bugs benchmark (He et al., 2022). Qualitatively, we also evaluated the accuracy of the line numbers in the generated diff hunk, and noticed that the larger scale models do very well at accurately generating line numbers which correspond to the lines which the diff below actually changes. This opens the door to prompting the model with specific line numbers to change, add, or remove, allowing for more control over the code generation in comparison with a non-diff model. We also noticed that diff models (especially the 2B and 6B) tend to do better when prompted with longer code generation tasks (such as fixing bugs in a large function, and that varying the prompt induces greater diversity in generated code in comparison with the normal CodeGen models. In further work, we hope to examine in greater detail the enhanced diversity and localised mutation abilities that diff models offer over standard code generation models, across many model scales. Accelerated Inference with Triton and FasterTransformer We also investigated the use of Nvidia’s FasterTransformer (FT) framework with the Triton Inference Server using an FT backend to achieve significantly accelerated inference. FasterTransformer is a collection of fused CUDA kernels optimized for inference, written in C++. The Triton Inference Server is an optimized system for serving large language models at scale, in both multi-GPU and multi-node setups using Docker containers. Converting the CodeGen models to FT involved significant technical work, since CodeGen is not supported natively in FT. We first converted the CodeGen weights to GPT-J format via a linear algebra trick, since GPT-J has a very similar architecture, building on Brendan Dolan-Gavitt’s work with the Fauxpilot framework. From there, we used the FT script to convert the GPT-J HuggingFace checkpoint into FT’s format, which can be run with the Triton server. We struggled to get this to run on our cluster (which does not use Docker), but eventually succeeded and achieved a significant speedup on inference of our models—in some cases up to an order of magnitude faster. Model Time: HuggingFace Transformers Time: FasterTransformer + Triton Inference Server CodeGen 350m 5m 44s 31s CodeGen 2B 9m 38s 1m 27s CodeGen 6B 10m 45s 2m 9s Table 2: Time benchmark results for the base CodeGen models on the 4-Parity task described above, comparing HuggingFace Transformers inference speed with FasterTransformer using the Triton Inference Server. Our scripts to convert and run these models with FasterTransformer and Triton are available in the OpenELM library. We hope that this work inspires others to take our models and experiment with the potential of diff-based code generation! To cite this blog post, please use the following entry: H. Bradley, H. Fan, H. Saini, R. Adithyan, S. Purohit, and J. Lehman. (Jan 2023). Diff Models - A New Way to Edit Code. CarperAI Blog. https://carper.ai/diff-model/. Or @article{bradley2023diffmodels, title = "Diff Models - A New Way to Edit Code", author = "Bradley, Herbie and Fan, Honglu and Saini, Harry and Adithyan, Reshinth and Purohit, Shivanshu and Lehman, Joel", journal = "CarperAI Blog", year = "2023", month = "Jan", url = "https://carper.ai/diff-model/" } Change Log: Changed y-axis on Figure 2 to be clearer. Acknowledgements The CarperAI diff models team consisted of Herbie Bradley, Honglu Fan, Harry Saini, Reshinth Adithyan, Shivanshu Purohit, and Joel Lehman. We thank Stability AI for providing compute resources.

1 0