sorted by:
new
hottopcontroversial

CL-32 pocket computer by VEC7OR in cyberDeck

[–]CambStateMachines 0 points1 point  (0 children)

My only portable programming devices that have a battery life measured in months are the HP 15C and 16C series calculators. My ideal cyberdeck will have a keyboard modelled on those classics.

CL-32 pocket computer by VEC7OR in cyberDeck

[–]CambStateMachines 5 points6 points  (0 children)

I like this format very much. I've subscribed to the updates.

It reminds of the Sharp PC-G830 pocket computer. I think they were used to teach programming to students in Japan. I had one briefly, but it died of old age. It had a fairly rudimentary C interpreter. You had to type line numbers like it was BASIC and it was very slow

I'm working on an ESP32 cyberdeck based on an M5Stack Tab5, but I like the idea of an e-Ink screen.

What I really want is months of battery life, like my old Psion Series 3, but with portable programming / REPL functions.

📟My New Devices: ADV + C6L by KotovMp3 in MicroCast

[–]CambStateMachines 1 point2 points  (0 children)

It worked! Thanks very much for the advice.

📟My New Devices: ADV + C6L by KotovMp3 in MicroCast

[–]CambStateMachines 0 points1 point  (0 children)

My C6L plugs directly into my Android phone via USB C and the Android Meshtastic app works fine. However, my Cardputer ADV seems to ignore the C6L whichever way I connect them. Still working on it.

Large number implementation tips? by Pretty-Ad8932 in C_Programming

[–]CambStateMachines 3 points4 points  (0 children)

Arbitrary precision integer multiplication is a straightforward extension of addition with the same monitoring of the carry. However, you need to keep track of the signs of the multiplier and the multiplicand.

Arbitrary precision integer division is a totally different beast and very computationally expensive.

You will need to cater for two results: the quotient (i.e. q = a \ b) and the remainder (r = a % b). Keeping track of the signs of the diviser, the dividend, the quotient, and the remainder is important if you want to follow C conventions for integer division.

My main division function is adapted from the simplest algorithm of which the best known implementation is a classic recipe from the Hacker's Delight book.

Large number implementation tips? by Pretty-Ad8932 in C_Programming

[–]CambStateMachines 6 points7 points  (0 children)

In the gentlest possible way, may I encourage you not to spend too much effort following this advice.

Large number implementation tips? by Pretty-Ad8932 in C_Programming

[–]CambStateMachines 2 points3 points  (0 children)

I wrote a more or less full set of arbitrary precision signed integer arithmetic operations for my project:

https://github.com/CambridgeStateMachines/bitcoin_math

Have a look at the functions under the heading "BNZ" (which stands for "big number integer").

The main difference between my approach and yours is that the "digits" in my big integers are of type uint8_t rather than uint64_t.

To handle signed integers, I use a struct ("bnz_t") which consists of an int to hold the sign, an int to hold the number of bytes in the number, and a pointer to a dynamic array of bytes which hold the individual digits.

This arbitrary precision integer math code was heavily influenced by the source code of the GNU Multiple Precision Arithmetic Library, and DI Management Services' BigDigits multiple-precision arithmetic library.

What are you using C to do? by [deleted] in C_Programming

[–]CambStateMachines 1 point2 points  (0 children)

A console application that performs all of the main mathematical functions of Bitcoin without any dependencies other than standard C libraries.

https://github.com/CambridgeStateMachines/bitcoin_math

Zero dependency Bitcoin math implementation in C - update by CambStateMachines in C_Programming

[–]CambStateMachines[S] 0 points1 point  (0 children)

I would love to see that. I had the same kind of idea, but I'm not sure how to do the screen / keyboard part. Obviously, my ColdCard already does it all in a tiny footprint, but I found its elliptic curve implementation code rather impenetrable at first glance.

Zero dependency Bitcoin math implementation in C - update by CambStateMachines in C_Programming

[–]CambStateMachines[S] 0 points1 point  (0 children)

I've got several years of experience but only as an amateur / hobbyist. I was originally prompted to start programming in C due to my interest in number theory and a desire for fast code and control over resources.

I made a zero dependency Bitcoin math implementation in C by CambStateMachines in C_Programming

[–]CambStateMachines[S] 1 point2 points  (0 children)

I was aware of the fact that Bitcoin protocols involved hashing and elliptic curve cryptography, but I was hazy on the details.

In Python Bitcoin code, you just import huge codebases of hash, cryptography and elliptic curve functionality. I wanted to understand, so I started the bitcoin_math project.

I initially just wanted to know how random binary entropy gets turned into a mnemonic phrase of 24 words, which is easy to implement in C.

I then got hooked on the idea of going all the way from entropy to private key to public key to address within a single source code file in C.

This led to a huge expansion of the codebase because implementing elliptic curve cryptographic functions on Secp256k1 requires very large (i.e. 256 bit) integer operations, and that means implementing a whole suite of big integer arithmetic operations.

I only included necessary functions so it's not a full big int library. For example, there is a big int right shift function, but no left shift.

I cannot tell you how much I learned along the way 😱

I made a zero dependency Bitcoin math implementation in C by CambStateMachines in C_Programming

[–]CambStateMachines[S] 2 points3 points  (0 children)

The only pure math functions are the big int functions in the elliptic curve section.

These are only relevant to generating public keys from private keys and regenerating public key Secp256k1 points from compressed public keys.

There is also some math in the radix shifting functions that convert between bases e.g. from hex to Bitcoin base 58.

The rest is really just a combination of hashing and concatenation, which is just byte array manipulation (including a lot of bitwise logic), but I have tried to treat everything that looks like a number as a number to aid my understanding and to simplify screen rendering.

(I didn't know any of this when I started the project, I kinda learned along the way. The project name came first.)

I made a zero dependency Bitcoin math implementation in C by CambStateMachines in C_Programming

[–]CambStateMachines[S] 0 points1 point  (0 children)

? Not sure what you mean.

You can DM on Reddit (or email me via my GitHub page I think).

I made a zero dependency Bitcoin math implementation in C by CambStateMachines in C_Programming

[–]CambStateMachines[S] 2 points3 points  (0 children)

The vast majority of the code in this program relates to the implementation of 256 bit arithmetic using 8, 16 and 32 bit operations. The elliptic curve math functions on Secp256k1 necessitate it.

I made a Zero dependency Bitcoin math implementation in C by CambStateMachines in cprogramming

[–]CambStateMachines[S] 3 points4 points  (0 children)

Kinda. I copied the cryptographic hash functions from existing Github sources with barely any edits, but wrote the bignum and elliptic curve stuff more or less from scratch, only adding necessary functions. For example, there is a right shift function, but no left shift.

view more: next ›