#asciilifeform | 2021-01-25

Logged on 2021-01-24 21:14:04 verisimilitude: I'll leave this up for a few days or so: http://verisimilitudes.net/base58

~ 2 hours 49 minutes ~

12:49

feedbot

http://mvdstandard.net/2021/01/dutch-begin-rebelling-against-virus-regime/ << The Montevideo Standard -- Dutch Begin Rebelling Against Virus Regime

12:56

shinohai and verisimilitude: Does Ben Vulpes's base58 encoding actually follow the one specified in BitCoin? I'm not getting the same results on the same input.

↖

12:59

I found the spec / algorithm at: https://tools.ietf.org/id/draft-msporny-base58-01.html very unhelpful. I found the bitcoin source more useful.

13:01

Also I could very well be doing something incorrectly. BV's implementation also might not implement the BC version or implement a different one which would explain it.

13:02

Not something to waste much time on, I wanted the practice and so also implemented a (very ugly) version in Lisp, based on the BC version.

13:11

http://logs.nosuchlabs.com/log/asciilifeform/2021-01-25#1030198 <<< have not personally experienced tis behavior, but did manage to dig up his original article *after* I made yesterday's post.

13:11

Logged on 2021-01-25 12:56:12 Aerthean: shinohai and verisimilitude: Does Ben Vulpes's base58 encoding actually follow the one specified in BitCoin? I'm not getting the same results on the same input.

13:11

Warning, wayback machine https://web.archive.org/web/20170204215826/http://cascadianhacker.com/base58-encoding-in-common-lisp

13:13

So far, verisimilitude's version posted seems most concise, but have not tried yet. In heathendom there exists this one as well: https://github.com/eudoxia0/cl-base58/blob/master/src/cl-base58.lisp

13:14

(Which claims to be same as Gavin's original)

13:22

Thanks shinohai. For an input of "Hello". Gavin: 9Ajdvzr BV: Da7kCzT

13:23

I pass to BV #( 72 101 108 108 111), to Gavin "Hello"

13:24

Also result from c++ BC implementation for "Hello": 9Ajdvzr

13:24

I specifically noted I didn't read the base 58 documents, and but mimicked.

13:26

http://logs.nosuchlabs.com/log/asciilifeform/2021-01-25#1030195 I'm glad, shinohai. I've no intention whatsoever to preserve this code, so feel free to do so, if it will ever be used as a reference.

13:26

Logged on 2021-01-25 09:59:30 shinohai: http://logs.nosuchlabs.com/log/asciilifeform/2021-01-24#1030177 <<< this *is* much nicer to read verisimilitude. So many irons in fire atm but will serve as nice ref if I decide to tackle own. Thanx!

13:27

Aerthean: Now I am curious as to what causes the difference in output lol. A project for a rainy afternoon when the girls are out.

13:28

(What if I had decided to use bv b58-encode to generate actual addys and sent coin into the void? xD )

13:28

verisimilitude: I saw that, you rewrote BV's version. I also wanted to write an implementation and decided to look the spec up and see what it said. Finding the spec...unclear, I went to the BC implementation and figured out how it worked, and thought I'd compare the output of the different versions as a cross-check and came across the differing outputs.

13:29

shinohai: For all I know, the output is only broken on my machine, and I should run some tests elsewhere to verify.

~ 24 minutes ~

13:53

Does the C++ implementation use BIGNUMs or something else?

14:06

It uses a Span (vector source) of unsigned chars an input. Processes everything as ints / unsigned chars and at the end converts to a standard (c++) string of charactors

~ 16 minutes ~

14:23

I think that BV and your versions implement a different algorithm. The BC algorithm has a different inner loop when it applies the input value to the output bytes, that as far as I can tell you and BV don't implement. The value stored in some subset of output bytes gets adjusted for almost every different byte input. It's not as simple as looking up the mod(someValue*256, 58)

14:29

Alright; if I ever make a better effort to implement base 58, I'll keep that in mind.

14:29

I'd rather do it in Ada, though, in all likelihood; I don't write enough Ada.

14:44

verisimilitude: If you get around to it, post it, I'd like to read an Ada version. Also you guys are doing something more complicated than what I wrote above. It looks like you build a big-number based on summing (* (expt 256 byte-position) value-at-byte-position). Then convert to b58 via repeated use of the floor(_, 58) function.

14:45

At least in BV's code, your implementation differs

14:46

I mimicked his, but wrote the same algorithm better.

14:46

Using DPB (DePosit Byte) for building a large number is best.

14:48

I like your implementation although it took me longer to parse as you use aspects of the language I'm less familiar with.

14:57

I'm glad to educate.

15:04

*

asciilifeform finds the 'drag in a complete bignum stack just to convert bases' mega-ughly

15:06

really oughta be able to do it group-of-digits at-a-time.

15:06

(challenge for alert reader!1111)

15:08

in misc. lulz, 'amd threadripper' cpu apparently includes.... a miniature torque wrench.

15:12

I'm certain there's some trick for when only a single base needs conversion, and it's not the same base as the underlying machine, asciilifeform.

15:13

I've a nicer solution still.

15:13

verisimilitude: knuth vol.2 iirc has'em

15:13

verisimilitude: what's yours ?

15:13

Oh, I'll need to check my copy, then.

15:14

Rather than create a base using these symbols, selected to avoid misconceptions, I'd rather just have a set of glyphs designed better.

15:14

waiwat?!

15:14

I've done light work on creating a set of thirty glyphs for a base thirty system.

↖

15:14

how does this answer the q of how to convert the bases ?

15:14

Oh, we're discussing different topics, I see.

15:14

aa

15:15

My ``nicer solution'' was avoiding the original problem.

15:15

i dun have anyffin against folx who want to use martian glyphs on their terminal (apl!!) but is separate q from 'how convert base x to base y'

15:15

verisimilitude: 'dun use weird bases' ?

15:15

Sure.

15:15

lol

15:15

asciilifeform: Thanks for the book rec: http://logs.nosuchlabs.com/log/asciilifeform/2021-01-16#1029235

15:15

Logged on 2021-01-16 12:03:15 asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2021-01-15#1029215 << i strongly rec the fun b00k 'Designing Video Game Hardware in Verilog' (S. Hugg, 2018) , will make it 100% clear.

15:16

Aerthean: was in re 'human-facing systems on non-vonneumann iron' thrd.

15:20

Yeah, I've been getting much more in to FPGA development lately. Has come to understand asciilifeform's various complaints on a much more visceral level.

15:20

Aerthean: plz don't hesitate to post here re: these observations.

15:21

Aerthean: which fpga are you using ?

15:22

I'm going to be doing some development on one of the beefier Xilinx Spartan-6s that use ISE rather than Vivado

15:23

Aerthean: funnily enuff i had several 6s kits in the past

15:23

worx w/ ise 13 & below iirc.

15:24

iirc you don't even need to crack ise to use 6s series (unlike 'virtex')

15:25

I've also done some development on the lower-level Zynq using Vivado, which also doesn't require a paid for license. Though I have access to a license at work for some of the bigger Xilinx FPGAs.

15:29