--- Log opened Wed Jul 27 00:00:32 2022
00:12 < nmz787> fenn: personally I use klayout for most GDS viewing
00:13 < nmz787> fenn: your toolchain is interesting though, I am not sure if I've heard of or looked into GMSH
01:15 -!- L29Ah [~L29Ah@wikipedia/L29Ah] has joined #hplusroadmap
01:25 -!- darsie [~darsie@84-113-55-200.cable.dynamic.surfer.at] has joined #hplusroadmap
01:50 -!- Molly_Lucy [~Molly_Luc@user/Molly-Lucy/x-8688804] has quit [Quit: Textual IRC Client: www.textualapp.com]
06:12 -!- juri_ [~juri@84-19-175-179.pool.ovpn.com] has quit [Ping timeout: 252 seconds]
06:44 -!- juri_ [~juri@84-19-175-179.pool.ovpn.com] has joined #hplusroadmap
07:43 -!- catern [~sbaugh@2604:2000:8fc0:b:a9c7:866a:bf36:3407] has quit [Remote host closed the connection]
07:45 -!- catern [~sbaugh@2604:2000:8fc0:b:a9c7:866a:bf36:3407] has joined #hplusroadmap
07:56 < fenn> https://sourceforge.net/projects/gds3d/ tool for viewing chip layouts in 3D
07:58 < fenn> possibly newer https://github.com/skuep/GDS3D
09:33 -!- spaceangel [~spaceange@ip-78-102-216-202.bb.vodafone.cz] has joined #hplusroadmap
10:05 < nmz787> I tried out the GDS3D program last year, it was pretty cool
10:06 < nmz787> there's also this browser thing, but it doesn't allow you to disable perspective distortion, nor tilt the view: https://github.com/s-holst/GDS2WebGL
10:07 < nmz787> (perspective distortion makes it a non-starter for any real use, since designers and design rule-makers need to look at things in terms of their overlap, etc
10:08 < nmz787> I was playing with their demo HTML file last night, seeing if I could find the "fudge factor" for distortion (like this lesson shows https://webglfundamentals.org/webgl/lessons/webgl-3d-perspective.html), but did not
10:33 < kanzure> http://www.hashcash.org/docs/hashcash.html
10:50 < fenn> why are we linking to hashcash
10:51 < kanzure> wanted to know if this is still usable
10:51 < kanzure> do email servers still implement this or did it never get adopted?
10:54 < fenn> hashcash token: 1:30:220727:fenn was here::TMi70WpdoPmaENMS:0008nFDt
10:54 < fenn> it was not adopted
10:54 < fenn> ahh good old unix code that just works
10:56 < kanzure> i was half expecting "-------- Hashcash signed message --------(message)-------- Hashcash signature --------(PoW)-------- End of Hashcash signed message --------"
11:10 < fenn> i could have put a message hash instead of "fenn was here"
11:11 < fenn> the idea was that you can mint the hashcash "postage stamp" before writing the email message
11:11 < muurkha> can you?
11:11 < kanzure> bitcoin signmessage has a similar format (what do you call the ------- PGP signed message -------- formatting?) so that users can read the message, then paste the whole thing into a verifier
11:11 < fenn> if you ask me it makes more sense to add proof of work around the message, which gets rid of all the database and double spend verification stuff
11:12 < kanzure> wait why would you want to mint it before you write the .... wtf?
11:12 < fenn> because it takes time to mint
11:13 < kanzure> i was not aware that the original hashcash had an emphasis on a locally stored double spend database
11:17 < kanzure> could have used a trusted central server..
11:18 < kanzure> obligatory https://craphound.com/spamsolutions.txt
11:24 < fenn> yeah what could possibly go wrong with a trusted central server for all email on the entire internet
11:25 < fenn> ideally hashcash would just lower your spam classification score by some amount depending on the whims of the spam filter
11:25 < fenn> spammers can do PoW too
11:37 < kanzure> yes but theoretically spammer's capital is limited
11:38 < kanzure> and the server wouldn't hold emails just double spending database of hashcash
11:58 < fenn> servers would have to exchange double spend data instead of just the emails themselves (with PoW attached to the message)
11:58 < fenn> transforming an O(N) problem into an O(N^2) problem
11:58 < fenn> since every server has to send updated double spend data to every other server
11:59 < fenn> you could do supernodes or something
12:47 -!- codaraxis [~codaraxis@user/codaraxis] has joined #hplusroadmap
12:48 -!- L29Ah [~L29Ah@wikipedia/L29Ah] has quit [Read error: Connection reset by peer]
14:09 -!- L29Ah [~L29Ah@wikipedia/L29Ah] has joined #hplusroadmap
14:14 < L29Ah> https://tinystash.undef.im/il/2KRkTcr55RZDK8wZ79dNS9HACLTbg4JzM6G3xXVefTyk1vwWgGQZKJ1RwajTBtm245QURdu9aTGSLYTCMNxm4Diu.jpeg
14:40 < kanzure> evidently i had some misconceptions about bone marrow transplants https://en.wikipedia.org/wiki/Bone_marrow#Donation_and_transplantation
14:40 < kanzure> i thought the donation had to be delivered into the bone
14:45 < L29Ah> https://www.gwern.net/Longevity#metformin how not to calculate the utility of interventions
14:58 < muurkha> fenn: wouldn't including the recipient's email address in the data that hashcash is hashing eliminate double-spending spamming attacks?
14:59 < muurkha> I mean, in a distributed sense
14:59 < muurkha> you still might want your mail server to keep you from getting 10000 messages from the same spammer on the same day
15:00 < muurkha> but that doesn't require any more centralization than already exists
15:43 -!- spaceangel [~spaceange@ip-78-102-216-202.bb.vodafone.cz] has quit [Remote host closed the connection]
18:56 -!- juri_ [~juri@84-19-175-179.pool.ovpn.com] has quit [Ping timeout: 245 seconds]
18:56 -!- darsie [~darsie@84-113-55-200.cable.dynamic.surfer.at] has quit [Ping timeout: 268 seconds]
19:11 -!- juri_ [~juri@79.140.114.82] has joined #hplusroadmap
20:43 -!- juri_ [~juri@79.140.114.82] has quit [Read error: Connection reset by peer]
20:46 -!- juri_ [~juri@79.140.114.82] has joined #hplusroadmap
20:48 -!- juri_ [~juri@79.140.114.82] has quit [Read error: Connection reset by peer]
20:53 -!- juri_ [~juri@84-19-175-179.pool.ovpn.com] has joined #hplusroadmap
22:37 < fenn> yes i was saying it should have been like that, not like the thing that it is (a database of spent stamps)
22:38 < fenn> it shouldn't be difficult to configure a mail server to condense bit-for-bit duplicate messages into one digest
22:38 < fenn> i mean, if this were a problem, in the hypothetical world where people actually used hashcash
22:39  * fenn grumbles
22:43 < L29Ah> hashcash sux
22:43 < L29Ah> as it's cheaper for the attacker than for the layman
22:44 < L29Ah> layman: grumbles while one's iphone calculates the PoW
22:44 < L29Ah> attacker: rents a cheap VPS
22:45 < L29Ah> one could argue that a battery user can buy some hash-computing service so one wouldn't have to calculate them on the device
22:45 < fenn> currently spam comes from misconfigured bulletin boards and botnet PCs
22:46 < L29Ah> but then why don't you just pay the recipient some bitcoin for receiving your message? that would make more sense
22:46 < fenn> that's sort of the idea
22:46 < L29Ah> botnet PC = very cheap VPS
22:46 < fenn> hashcash was a precursor to bitcoin
22:46 < L29Ah> yes, but you're discussing it as if it still has merit on its own
22:47 < fenn> because it does still have merit
22:47 < fenn> it's a trivial inconvenience for anyone not sending millions of messages from one computer
22:47 < muurkha> L29Ah: I feel like your mail server could spend 60 seconds generating a hash before delivering a message?
22:48 < muurkha> also including the recipient address in the hash doesn't prevent you from precomputing most hashcash
22:48 < fenn> the amount of work could be variable depending on whether you've mailed someone before
22:48 < fenn> cold call = lots o work
22:48 < muurkha> yeah
22:48 < L29Ah> if a mailserver would have to spend a minute generating a hash, then the iphone would spend all its battery before generating one
22:48  * L29Ah hides
22:49 < muurkha> in general I think the solution to spam and DDoS is to privilege pre-existing relationships over new ones
22:49 < muurkha> L29Ah: right, but the iPhone only has to hand the message off to your own mailserver
22:49 < L29Ah> i like how it's done in Tox
22:49 < fenn> how do you precompute without including the email in the thing-to-be-hashed?
22:49 < muurkha> how does tox do it?
22:50 < muurkha> fenn: well, you could have a local double-spending database on the receiving mailserver
22:50 < muurkha> and precompute a hash for just the recipient name
22:50 < L29Ah> tox generates an address that can be used to add you to contacts, the address has an anti-spam portion; when you start getting spam, you change the portion and update it wherever necessary; the established contacts are preserved
22:50 < fenn> muurkha> also including the recipient address in the hash doesn't prevent you from precomputing most hashcash
22:50 < muurkha> L29Ah: I see
22:51 < fenn> ^ how do you precompute that
22:51 < muurkha> you mean, how does my mailserver's sender-smtp know which recipients I am going to send email to in the future?
22:52  * L29Ah is not sure if email is so basic that it should be dropped or so badass that it should be extended even more with even fancier kludges
22:52 < fenn> oh, you're proposing the thing-to-be-hashed is just the email address, not the email address + the message
22:52 < muurkha> yes
22:53 < muurkha> or maybe the recipient email address and a nonce, or the recipient email address, the sender's public key hash, and a serial number
22:54 < muurkha> in that last case you could put the serial number in the email message and sign it with the corresponding private key, so nobody could steal precomputed hashcash and spam your contacts with it unless they also stole your private key
22:55 < muurkha> maybe that's a dumb idea tho
22:57 < fenn> signing messages has upside and downside
22:57 < muurkha> oh?
22:57 < fenn> you might want plausible deniability
22:57 < muurkha> you can generate a fresh keypair for each message with that protocol
22:58 < fenn> i think it's past my bedtime
22:58 < muurkha> sleep well
--- Log closed Thu Jul 28 00:00:33 2022