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!
snsabot: Logged on 2021-01-24 21:14:04 verisimilitude: I'll leave this up for a few days or so: http://verisimilitudes.net/base58
feedbot: http://mvdstandard.net/2021/01/dutch-begin-rebelling-against-virus-regime/ << The Montevideo Standard -- Dutch Begin Rebelling Against Virus Regime
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.
Aerthean: 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.
Aerthean: 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.
Aerthean: 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.
shinohai: 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.
snsabot: 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.
shinohai: Warning, wayback machine https://web.archive.org/web/20170204215826/http://cascadianhacker.com/base58-encoding-in-common-lisp
shinohai: 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
shinohai: (Which claims to be same as Gavin's original)
Aerthean: Thanks shinohai. For an input of "Hello". Gavin: 9Ajdvzr BV: Da7kCzT
Aerthean: I pass to BV #( 72 101 108 108 111), to Gavin "Hello"
Aerthean: Also result from c++ BC implementation for "Hello": 9Ajdvzr
verisimilitude: I specifically noted I didn't read the base 58 documents, and but mimicked.
verisimilitude: 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.
snsabot: 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!
shinohai: 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.
shinohai: (What if I had decided to use bv b58-encode to generate actual addys and sent coin into the void? xD )
Aerthean: 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.
Aerthean: shinohai: For all I know, the output is only broken on my machine, and I should run some tests elsewhere to verify.
verisimilitude: Does the C++ implementation use BIGNUMs or something else?
Aerthean: 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
Aerthean: 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)
verisimilitude: Alright; if I ever make a better effort to implement base 58, I'll keep that in mind.
verisimilitude: I'd rather do it in Ada, though, in all likelihood; I don't write enough Ada.
Aerthean: 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.
Aerthean: At least in BV's code, your implementation differs
verisimilitude: I mimicked his, but wrote the same algorithm better.
verisimilitude: Using DPB (DePosit Byte) for building a large number is best.
Aerthean: I like your implementation although it took me longer to parse as you use aspects of the language I'm less familiar with.
verisimilitude: I'm glad to educate.
asciilifeform finds the 'drag in a complete bignum stack just to convert bases' mega-ughly
asciilifeform: really oughta be able to do it group-of-digits at-a-time.
asciilifeform: (challenge for alert reader!1111)
asciilifeform: in misc. lulz, 'amd threadripper' cpu apparently includes.... a miniature torque wrench.
verisimilitude: 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.
verisimilitude: I've a nicer solution still.
asciilifeform: verisimilitude: knuth vol.2 iirc has'em
asciilifeform: verisimilitude: what's yours ?
verisimilitude: Oh, I'll need to check my copy, then.
verisimilitude: Rather than create a base using these symbols, selected to avoid misconceptions, I'd rather just have a set of glyphs designed better.
asciilifeform: waiwat?!
verisimilitude: I've done light work on creating a set of thirty glyphs for a base thirty system.
asciilifeform: how does this answer the q of how to convert the bases ?
verisimilitude: Oh, we're discussing different topics, I see.
asciilifeform: aa
verisimilitude: My ``nicer solution'' was avoiding the original problem.
asciilifeform: 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'
asciilifeform: verisimilitude: 'dun use weird bases' ?
verisimilitude: Sure.
asciilifeform: lol
Aerthean: asciilifeform: Thanks for the book rec: http://logs.nosuchlabs.com/log/asciilifeform/2021-01-16#1029235
snsabot: 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.
asciilifeform: Aerthean: was in re 'human-facing systems on non-vonneumann iron' thrd.
Aerthean: 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.
asciilifeform: Aerthean: plz don't hesitate to post here re: these observations.
asciilifeform: Aerthean: which fpga are you using ?
Aerthean: I'm going to be doing some development on one of the beefier Xilinx Spartan-6s that use ISE rather than Vivado
asciilifeform: Aerthean: funnily enuff i had several 6s kits in the past
asciilifeform: worx w/ ise 13 & below iirc.
asciilifeform: iirc you don't even need to crack ise to use 6s series (unlike 'virtex')
Aerthean: 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.
Aerthean: More specifically one of the Kintex Ultrascale models w/many DSPs