log☇︎
66400+ entries in 0.038s
BingoBoingo: billymg: The CoC situation is lulzier than my reading of it yesterday lead me to believe
asciilifeform: would also have some antifuse rom on-board, with option to run entirely from same.
asciilifeform: i'ma describe , for the l0gz : ideal cpu for crypto would be something quite like the schoolbook mips.v -- no cache, no branch prediction, no pipeline, no dram controller (run off sram strictly), a set of large regs for multiply-shift , and dedicated pipe to FG (i.e. have single-instruction that fills a register with entropy ) ☟︎
asciilifeform: if could afford asic with ~100k transistors -- could have 256x256 multiplier, have 4096bit constant-spacetime rsa in coupla millisecond...
diana_coman: I rather think we'll get there one day; not yet though
asciilifeform: what i'd really like is to bake an entire comp, a la rockchip, with FG on board. but this too is in same budgetary ballpark as asic .
diana_coman: so far the FGs are one of the relatively few things that I positively like having to deal with!
asciilifeform: ( plus i ~like~ that it gets made from off-the-shelf components, from strategic pov it is imho superior )
asciilifeform: if this were a bake-by-the-thousands product, we could bake asic. but currently this is not realistic imho ☟︎
diana_coman: myeah, that's about the main current pain from my pov
asciilifeform: aand there's the usb-ttl thing, which is gnarly
diana_coman: I can't say that I see a clear suggestion on how to solve that though
asciilifeform: right nao, 2 FG ~just barely~ fit in a 1u serv, and it takes adhesive fasteners
asciilifeform: diana_coman: the redesign
asciilifeform: diana_coman: given as you're the leading industrial FG user, perhaps share your pov on the above ?
asciilifeform: i wouldn't even be opposed to putting usb logic on FG -- but to this very day have not found a sane (i.e. not reflashable via usb) interface ic , aside from the chinese dongles ( which i outboarded, because if a piece can be outboarded -- it oughta, per specificity-of-diddling )
asciilifeform: or at the very least , >1 serial port ( the current pizarro boxen, do have rs232 header on mobo, but only one, and at the traditional +/- 12v signal levels, rather than ttl, and i eschew the converters, because they all work by oscillating capacitor pump, hence noisy )
asciilifeform: mircea_popescu: classical FG also fits very reluctantly in servers, but currently i dun have a good idea re what specifically to do about this ( the 'obvious' pill is to have a pci variant, but ice40 is too small for the necessary logic, which in itself is quite gnarly )
a111: Logged on 2018-10-23 06:05 bvt: hi, i have mp-wp set up now: http://bvt-trace.net/2018/10/instead-of-hello-world-fg-tests/ . I will publish writeup and updated vpatch for vpatch later today.
asciilifeform: the primary headache of old FG is imho the very modest output rate, which makes the thing take ridiculous length of time to test on my bench
a111: Logged on 2018-10-23 06:19 mircea_popescu: "While the FG shop has been closed for quite some time already," asciilifeform think we should bake a new set ?
asciilifeform: http://btcbase.org/log/2018-10-23#1865312 << ideally we oughta bake the new one, with ice40 & scintillator, imho ☝︎☟︎
lobbesbot: asciilifeform: The operation succeeded.
a111: Logged on 2018-10-23 13:19 deedbot: http://bimbo.club/?p=64 << Bimbo.Club - TMSR Log Summary - 10/19/2018
asciilifeform: !Q later tell nicoleci http://btcbase.org/log/2018-10-23#1865327 >> s/Their/There ☝︎
BingoBoingo: Enjoy the beach
diana_coman: not to mention that I think it is actually saner to have local names for types used
diana_coman: (I just don't want to carry about Interfaces.Unsigned_8 everywhere)
asciilifeform: nao possibly i never suffer from this because i very rarely refer to bits explicitly
diana_coman: asciilifeform, it's like a 1ms internal, perceptible interpreting-slowdown every time I meet bit/byte
asciilifeform: in own proggies, i like using explicitly-bitted types, e.g. Unsigned_8 in http://btcbase.org/patches/udp_genesis#L441
asciilifeform: diana_coman: i actually have 0 objections to 'octet', tho i confess i never suffered from 'bit'-'byte' conflation ( never worked on a box with 7 or 9 bit bytes, e.g. the CDC described in 1st ed k&r -- tho i did work on boxes with odd word lengths, e.g. pic16, where 14bit nonbreakable word... )
diana_coman: ahaha, that's the spirit: when C strikes, go to the beachz!
mircea_popescu: aaactually, ill tell you what i can do : im going to teh beach. back thurs or some shit!
diana_coman: yes; basically Ada makes it easy enough to not have to force anything; funny how Ada is in fact *very* accommodating - where it makes sense to be
mircea_popescu: diana_coman i can see it ; i like octet also, but yeah, can't start forcing this cultural issue on people. a one line define i guess only reasonable approach at this point.
deedbot: http://bimbo.club/?p=64 << Bimbo.Club - TMSR Log Summary - 10/19/2018 ☟︎
a111: Logged on 2018-10-19 21:27 asciilifeform: whatever happend to http://summaries.logs.esthlos.com btw
esthlos: http://btcbase.org/log/2018-10-19#1864316 << apologies alf, I'm running behind! trying to gather time to get caught up in the next week or two ☝︎
diana_coman: ftr I quite like the neat way in which asciilifeform defined those basic types in FFA; however, he went for the classical types so byte, nibble ; and I find octet SO much easier than I'm reluctant to give it up in my code (though all it takes is anyway a "subtype Octet is Byte" at top if Byte definition is to be adopted)
diana_coman: that being said, names are one thing, definition of the types another: i.e. every packet and project still needs to define/have defined somewhere the types it uses
diana_coman: hm, theoretically the byte is standard but there is the bit/byte confusion issue and moreover I really find octet easier on brain as it directly points at "it's eight bits!"
mircea_popescu: ie, have some tmsr-wide meta-types.
diana_coman: on one hand libs on their own should logically have their own types; on the other hand, when they are used as part of a bigger project, it makes sense I think to make their types subtypes - where they fit/are the same
diana_coman: mircea_popescu, what would the style be there?
a111: Logged on 2018-10-23 04:35 mircea_popescu: every time we notice same answer is given to repeated question, we note it down. before, what's the use ?
mircea_popescu: slowly but surely a republican ada style manual is shaping up (and through the exact http://btcbase.org/log/2018-10-23#1865304 process, at that!) ☝︎☟︎☟︎
mircea_popescu: diana_coman re http://ossasepia.com/2018/10/18/smg-comms-chapter-3-packing-serpent/#selection-85.346-85.466 wouldn't it be better to have a single style for this ?
mircea_popescu: "While the FG shop has been closed for quite some time already," asciilifeform think we should bake a new set ? ☟︎
bvt: hi, i have mp-wp set up now: http://bvt-trace.net/2018/10/instead-of-hello-world-fg-tests/ . I will publish writeup and updated vpatch for vpatch later today. ☟︎
a111: Logged on 2018-10-22 22:44 asciilifeform: relatedly, mod6 et al, i suggest abolition of '-verifyall' flag, it should really be permanently welded on, bypassing sig tests doesn't win ~anyffin in so far as i can tell
mircea_popescu: sit there try to come up with imaginatioins of future people seems a waste of your time.
mircea_popescu: every time we notice same answer is given to repeated question, we note it down. before, what's the use ? ☟︎
a111: Logged on 2018-10-23 01:51 mod6: Gotta catch up on l0gz and the rest. In particular, I'm just about nowhere on my task of creating answers to FAQs/Common Questions about the Foundation itself. I'll be working on that this week as a main priority - will post what I have for review/comments/corrections in #trilema by end of weekend.
mircea_popescu: http://btcbase.org/log/2018-10-23#1865276 << don't waste your time with that, let it emerge naturally. ☝︎☟︎
a111: Logged on 2018-10-23 01:48 asciilifeform: http://btcbase.org/log/2018-10-23#1865261 << incidentally i dun see how these are mechanically distinguishable from a node's pov
mircea_popescu: http://btcbase.org/log/2018-10-23#1865268 << they aren't ; but bad peer set can produce it also, and often enough does. ☝︎
asciilifeform: indeed. sorta why they're of interest, imho, as 'corner case'.
mircea_popescu: yeah, no, those don't really happen anymore. even 1s are rare(r).
a111: Logged on 2018-10-22 23:17 asciilifeform: thinking about it, i can actually conceive of 1 possible constructive use for programmable cements -- testing the reorg mechanism ( i.e. deliberately steer a node into a dead end chain, then restart uncemented and see whether it finds its way back properly )
mod6: http://btcbase.org/log/2018-10-22#1865239 << This would be a neat test. ☝︎
mod6: I can't disagree with that.
asciilifeform: mod6: afaik errybody already runs with the flag. and switching it off dun do anyffing useful, quite the contrary
a111: Logged on 2018-10-22 22:44 asciilifeform: relatedly, mod6 et al, i suggest abolition of '-verifyall' flag, it should really be permanently welded on, bypassing sig tests doesn't win ~anyffin in so far as i can tell
mod6: http://btcbase.org/log/2018-10-22#1865206 << There's a thought. ☝︎
mod6: Meanwhile... my node is happily eating blocks to catch back up. On block 64 of 85. Will be a few days yet, I'm certain.
mod6: I've got a pile of things, really. :D
mod6: The creation of a keccak trb tree is still on the to-do list; however, one thing kinda proceeds that item for me - a review / testing of keccak implementation. I've never had a chance to do that yet, and I think it's important.
asciilifeform: but thats all i had on ml in recent times
mod6: That one too.
mod6: Anyway, like I said, need to go back and rewind the logs a week.
asciilifeform: mod6: there was earlier one that prints who gave blox
mod6: Oh, my bad, there was just one. For some reason, I thought that I read there were two.
asciilifeform: simply dumps block hashes, without racking up ssd wear as dumpblock/hash/erase to do same job would
asciilifeform: mod6: dun hurry with that one, it's a somewhat exotic knob that isnt of great immediate consequence
mod6: asciilifeform: thanks for your recent submissions to the ML. I'll get to reviewing those as soon as I can.
mod6: Gotta catch up on l0gz and the rest. In particular, I'm just about nowhere on my task of creating answers to FAQs/Common Questions about the Foundation itself. I'll be working on that this week as a main priority - will post what I have for review/comments/corrections in #trilema by end of weekend. ☟︎☟︎
asciilifeform: i have not observed this on trb to date, but it is precisely the q i was posing, whether can happen ( i.e. reorg logic fails ) in some possible alignment of planets.
mod6: Happy 4th Anniversary to The Bitcoin Foundation!
asciilifeform: 'locked' implies that reorg logic failed ?
a111: Logged on 2018-10-23 01:37 mircea_popescu: asciilifeform to be clear, is the idea "node locked on alt chain while main chain goes on a lot of blocks" or "node on a lengthy orphan chain" ?
asciilifeform: http://btcbase.org/log/2018-10-23#1865261 << incidentally i dun see how these are mechanically distinguishable from a node's pov ☝︎☟︎
asciilifeform: but if anyone observed a longer one ( whether naturally occurring, that i slept through somehow, or artificial on testbed ) i'd like to know.
asciilifeform: afaik to date trb demonstrably did Right Thing on reorg of arity 6 ( july '15 incident )
asciilifeform: mircea_popescu: was asking specifically re events that trigger reorg logic ( as seen in http://btcbase.org/patches/asciilifeform_aggressive_pushgetblocks/tree/bitcoin/src/main.cpp#L1028 ), with arity defined as the length of the eventually discarded forklet chain
mircea_popescu: but the former happens all the time, cuz inexpensive relay failure
mircea_popescu: cuz the latter indeed doesn't happen, expensive mienr failuire
mircea_popescu: asciilifeform to be clear, is the idea "node locked on alt chain while main chain goes on a lot of blocks" or "node on a lengthy orphan chain" ? ☟︎
lobbes: BingoBoingo: ty sir
asciilifeform has been reading noad spew daily since early 2015, finds it difficult to picture having missed such a bomb
asciilifeform: mircea_popescu: if you still have the 100blox log spew on tape somewhere, would like to see..
a111: Logged on 2015-07-04 21:58 mircea_popescu: atm the situation is that block 363730 is forked. one chain, 6 blocks long, proceeds atop a v2 block. the current main chain proceeds from 363730 on v3 blocks.
a111: Logged on 2015-07-04 04:03 mircea_popescu: asciilifeform listen, seems the chain actually forked.
asciilifeform: there was the 2015 lulzfest, http://btcbase.org/log/2015-07-04#1186479 , but iirc that summed to sad chain ~dozen blox long ☝︎
asciilifeform: iirc it came from one of those idjit gavin cataclysms
asciilifeform: i definitely watched a 60 blox reorg, but this was in pre- trb era
asciilifeform: cuz i can't say that i have, on my watch
asciilifeform: mircea_popescu: observed on a trb node concretely ?
asciilifeform: afaik this is not a test that has actually happened in trb history ( longest naturally-occurring reorg since trb first saw use in the battlefield was, iirc, 8 blox or so ? )
asciilifeform: thinking about it, i can actually conceive of 1 possible constructive use for programmable cements -- testing the reorg mechanism ( i.e. deliberately steer a node into a dead end chain, then restart uncemented and see whether it finds its way back properly ) ☟︎