- cypherpunks - lists.cpunks.org

[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

Re: Larson FOIL 5th Extension (letter (Richard Weber - General Counsel, NY-DFS)
by Gunnar Larson 02 Feb '23

02 Feb '23

Thank you very much. Gunnar Gunnar Larson xNY.io - Bank.org 646-454-9107 On Thu, Feb 2, 2023, 1:36 PM Garvin, Sheila Y (DHR) < Sheila.Garvin(a)dhr.ny.gov> wrote: > Dear Mr. Larson: > > > > Pursuant to your request, please see the attached. > > > > *Best,* > > > > *Sheila Garvin* > > > > *DHR Records Access Clerk* > > *Legal Management Records Unit* > > One Fordham Plaza, 4th Floor, Bronx, NY 10458 > > Tele: (718) 741-8423/ e-Fax: (718) 741-8256 > > *foil(a)dhr.ny.gov <foil(a)dhr.ny.gov>* > > *Sheila.Garvin(a)dhr.ny.gov <Sheila.Garvin(a)dhr.ny.gov>* > > *www.dhr.ny.gov <http://www.dhr.ny.gov/>* > > > > *This transmission and its attachments may contain confidential or > privileged information, which is intended for use by the individual or > entity to which the transmission is addressed. If you are not the intended > recipient, you are hereby notified that any disclosure, dissemination, > copying, or distribution of this transmission or its attachments is > strictly prohibited. If you have received this transmission in error, > please notify the sender immediately at the above address and delete the > transmission and its attachments**.* > > > > > > > > >

1 0

18 States Send a Message to FTX Bankruptcy Judge John Dorsey: We’re Watching You
by Gunnar Larson 02 Feb '23

02 Feb '23

"By Pam Martens and Russ Martens: February 2, 2023 ~ John T. Dorsey (2016 Photo from Internet Archives’ Wayback Machine) A showdown in the Delaware bankruptcy proceedings for Sam Bankman-Fried’s collapsed crypto exchange, FTX, before presiding Judge John Dorsey is scheduled for next Monday morning at 9:30. (You can listen to the hearing live at this link. Just turn on your speakers and click on the box with the flag.) The battle lines have been drawn for the showdown – but not in the manner that Big Law firm, Sullivan & Cromwell, had hoped. The U.S. Trustee, who represents the U.S. Department of Justice in bankruptcy cases, has been asking Judge Dorsey to agree to the appointment of an independent examiner in the case since December 1. And over the presiding two months, the deeply conflicted Sullivan & Cromwell law firm has been aggressively opposing the U.S. Trustee’s pursuit of an independent examiner. Yesterday, a Joinder was filed by the securities regulator of Texas, supporting the motion by the U.S. Trustee. The joinder included letters from 15 other state securities regulators and Washington, D.C., also supporting the appointment of an independent examiner. The states included the three largest U.S. states by population: California, Texas and Florida. The states of Wisconsin and Vermont had previously filed their own joinders requesting the appointment of an independent examiner, meaning that the position of the U.S. Trustee is currently being advocated by 18 state securities regulators and the District of Columbia. In the joinder filed by Wisconsin’s Attorney General and state securities regulator on December 21, it made the following points: “Here, the [bankruptcy] estate, creditors, and society writ large would benefit from the investigation of a neutral, third-party, as the U.S. Trustee’s motion argues. As part of the broader societal interest, state and federal government regulators would benefit from a neutral fact-finder’s investigation, which would enable them to learn from a disinterested source what happened and how it happened under the current regulatory framework (or lack thereof to address this particular industry). These answers are necessary so that government regulators can put into place an effective regulatory framework to ensure that something like this — a colossal fraud costing billions of dollars in economic waste — never happens again.” The U.S. Trustee has another pesky detail on its side: the appointment of an examiner is mandatory under U.S. Bankruptcy Code Section 1104 if requested by the U.S. Trustee and the debtor meets the statutory debt threshold of $5 million or greater. (FTX and its more than 100 affiliated companies owe billions of dollars in debts to investors and customers.) In the latest court filing yesterday by the U.S. Trustee, it explains that every U.S. District Court to publish a decision on this issue has agreed that the appointment of an independent examiner is mandatory under the terms of Section 1104 of the U.S. Bankruptcy Code. The only Court of Appeals to issue a published opinion, the Sixth Circuit, has taken the same view. Notwithstanding the plain language of the law and legal precedent, Judge Dorsey previously stated in open court during a hearing that he doesn’t believe the appointment of an independent examiner is mandatory. Bench rulings (an unpublished ruling by a Judge which carries no weight in terms of legal precedent) in the Delaware bankruptcy district have also taken the position that the appointment of an independent examiner is not mandatory. (This might explain why Sullivan & Cromwell law partners are arguing their case in U.S. Bankruptcy Court in Delaware instead of in Manhattan where their office is located.) Damian Williams, the U.S. Attorney for the Southern District of New York, whose office is prosecuting the criminal case against former FTX CEO Sam Bankman-Fried (who has pled not guilty) and two other executives, Caroline Ellison and Gary Wang (who have pled guilty and are cooperating with prosecutors) has called the FTX collapse “one of the biggest financial frauds in American history.” The new CEO of FTX, John Ray, testified to the House Financial Services Committee on December 13 that $8 billion of customer funds are missing. On the basis of those facts alone, one would think that Judge Dorsey would be anxious to comply with the Justice Department’s U.S. Trustee and quickly agree to the appointment of an independent examiner. Instead, and despite the fact that Sullivan & Cromwell has filed multiple declarations revealing raging conflicts of interest in the case, Judge Dorsey has ignored multiple objectors and signed an order allowing the law firm to become the lead counsel in the bankruptcy proceedings – which effectively puts the firm in charge of investigating its own conduct. In a filing with the bankruptcy court, an FTX customer, Warren Winter, described the situation as the fox guarding the henhouse, writing: “Sullivan & Cromwell was one of the FTX Group’s ‘primary external law firms’ before the FTX Group collapsed. To date, the FTX Group has paid the firm more than $20.5 million in fees and retainers. Now, in the most flagrant attempt by a fox to guard a henhouse in recent memory, Sullivan & Cromwell has applied to be appointed the FTX Group’s bankruptcy counsel with duties that would include ‘investigating all potential estate causes of action’….” Sullivan & Cromwell belatedly owned up in court filings to personally representing Sam Bankman-Fried – the man charged under an 8-count indictment by the Department of Justice with being the kingpin of this alleged international crypto fraud enterprise. On January 17, Sullivan & Cromwell law partner, Andrew Dietderich, filed a document with the bankruptcy court acknowledging that the law firm had not only done extensive legal work for FTX but personally represented Sam Bankman-Fried from April 14, 2022 through August 5, 2022. The disclosure noted that “This matter was arranged, and paid for, by Alameda,” a reference to Alameda Research, Bankman-Fried’s hedge fund which prosecutors have alleged he used to loot FTX customer funds. The specific nature of the work Sullivan & Cromwell did for Bankman-Fried involved “a position that had been established in the stock of Robinhood Markets, Inc.” according to the Dietderich declaration. That stock position totaled more than half a billion dollars. According to a letter from federal prosecutors recently filed in the criminal case, a foreign special purpose vehicle was set up in the Robinhood stock matter, to “obscure his criminal misuse of FTX customer property.” The independent examiner would certainly want to know what lawyer and/or law firm created that offshore vehicle. Sullivan & Cromwell has also conceded that it did legal work on a multitude of transactions and regulatory matters for FTX and had collected legal fees and expenses of $8,564,487.50 from FTX and its affiliates over the prior 16 months, plus a $12 million retainer for bankruptcy work. State attorneys general and state securities regulators representing more than a third of the population of the United States are going to be watching carefully to see what Judge Dorsey has to say at the hearing on Monday." https://wallstreetonparade.com/2023/02/18-states-send-a-message-to-ftx-bank…

1 0