Fixpoint

Day changed to 2024-06-01
[01:23] jfw: reviving this point from the otherwise dead thread, it looks not so promising because it's based on a C extension module linking the mysql client library.
[01:23] sourcerer: 2022-04-30 18:30:48 (#jwrd) jfw: for connecting to mysql from python, on CentOS I've used MySQLdb; unclear as yet if that's the best choice on Gales though.
[01:24] jfw: mysql.com itself publishes a MySQL Connector/Python which sports both a C and pure Python variant, boasting to be a "Self-contained driver. Connector/Python does not require the MySQL client library or any Python modules outside the standard library."
[01:25] jfw: but then somehow, "As pure Python; an implementation written in Python. Its dependencies are the Python Standard Library and Python Protobuf >= 4.21.1,<= 4.21.12."
[01:26] jfw: because everybody already uses everything from google so it doesn't even register for them as "not standard library" ?!
[01:27] jfw: fortunately it looks like the older versions still supporting python 2 and not caring about mysql 8 don't yet include the nonsense.
[01:43] jfw: on the mariadb side they have their own releases of it but information is hard to find, the download process doesn't work and the clues point to python3 support only
[02:02] jfw: with mysql connector/python, had to go back to early 2013 for a release where they hadn't replaced the documentation with a link to the web version, which they've meanwhile given the 'living document' treatment and no older versions are to be found.
[02:03] jfw: the mysql server itself has this problem too.
[02:03] jfw: I have the 5.6 docs archived only in .info format.
[02:06] jfw: while 5.7 is the oldest still online and there's still no downloadable html version.
[04:53] jfw: I've stashed mysql-connector-python-1.0.9, given a cursory skim of its full contents, installed on Gales using the setup.py, and run the suite of 352 unit tests with only 3 failing, due as usual to broken/stupid test code.
Day changed to 2024-06-02
[21:13] jfw: !w register
[21:13] wotbot_test: Usage error: provide a plain HTTP link to your public key (and nothing more).
[21:13] jfw: !w register /etc/passwd
[21:13] wotbot_test: Usage error: provide a plain HTTP link to your public key (and nothing more).
[21:13] jfw: !w register http://127.0.0.1:99/
[21:16] jfw: !w register http://127.0.0.1:99/
[21:17] jfw: !w register http://127.0.0.1:99/
[21:20] jfw: !w register http://127.0.0.1:99/
[21:20] wotbot_test: jfw: failed to connect to database.
[21:22] jfw: !w register http://127.0.0.1:99/
[21:25] jfw: that looks like a first mysql.connector bug, 'username' is supposed to be a valid synonym for 'user' as a connection argument
[21:25] jfw: !w register http://127.0.0.1:99/
[21:25] wotbot_test: jfw: failed to fetch key: <urlopen error [Errno 111] Connection refused>
[21:25] jfw: there we go.
[21:25] jfw: !w register http://jfxpt.com/nonexistent
[21:25] wotbot_test: jfw: failed to fetch key: HTTP Error 404: Not Found
[21:26] jfw: !w register http://jfxpt.com/
[21:28] jfw: gah, apparently x.get(index, default) works only for dict, not list.
[21:30] jfw: !w register http://jfxpt.com/
[21:30] wotbot_test: jfw: failed to register key: 1366 (HY000): Incorrect string value: '\xD1\x96\xC7\x83<b...' for column 'pubkey' at row 1
[21:31] jfw: ha, not the expected error.
[21:35] jfw: !w register http://jfxpt.com/paste/
[21:35] wotbot_test: jfw: failed to import key.
[21:36] jfw: I guess because there happened to be a pubkey within the html on the home page, gpg managed to import it despite the noise. which reminds me I'd intended to re-export to get a clean/minimized key version before saving. the mysql error I don't yet get though, how can a string be 'incorrect'? lol
[21:43] jfw: possibly because it's a TEXT field and so indeed, needs plain text.
[21:43] jfw: !w register http://jfxpt.com/
[21:43] wotbot_test: Registered jfw with key 0CBC05941D03FD95C3A47654AE0DF306025594B3
[21:43] jfw: not bad I guess.
[21:43] jfw: !w register http://jfxpt.com/jfw.asc
[21:43] wotbot_test: Error: jfw is already registered.
[21:43] jfw: and if I drop the polite pre-check?
[21:44] jfw: !w register http://jfxpt.com/jfw.asc
[21:44] wotbot_test: jfw: failed to register key: IntegrityError()
[21:45] jfw: a little light on details, hm.
[21:47] jfw: myeah, mysql shell manages to give details
[21:51] jfw: looks like its exception objects are a bit quirky, they show LESS detail when using repr() rather than str(), which I'd tried since that "1366" format was a bit decontextualized.
[22:21] jfw: !w register http://jfxpt.com/jfw.asc
[22:21] wotbot_test: jfw: failed to register key: IntegrityError: 1062 (23000): Duplicate entry 'jfw' for key 'name'
[22:22] jfw: better!
[22:22] jfw: !w register http://127.0.0.1:99/
[22:22] wotbot_test: jfw: failed to fetch key: URLError: <urlopen error [Errno 111] Connection refused>
[22:24] jfw: !w register http://jfxpt.com/nonexistent
[22:24] wotbot_test: jfw: failed to fetch key: HTTPError: HTTP Error 404: Not Found
[22:25] jfw: a little redundant there but I reckon it's fine, and it's closer to the python shell behavior. see, the great thing about python is it comes with so many existing features that almost work well enough to not have to reinvent or work around them!
[22:26] herpderp: !w register http://jfxpt.com/jfw.asc
[22:26] wotbot_test: herpderp: failed to register key: IntegrityError: 1062 (23000): Duplicate entry '0CBC05941D03FD95C3A47654AE0DF306025594B3' for key 'fingerprint'
[22:27] jfw: that's probably as it should be - one name per key and one key per name.
[22:48] jfw: otoh, relaxing that would be a natural way to allow name changes. not like it does me any harm for herpderp to re-register my key, since he won't be able to sign or decrypt anything, really all he's done is donated his name to me
[22:51] jfw: but he would be polluting the key-to-name lookup results. I guess the consistent approach would be to require rsa verification to accept any registration
[23:16] jfw: !w register http://jfxpt.com/jfw.asc
[23:16] wotbot: jfw: failed to connect to database.
[23:17] jfw: !w register http://jfxpt.com/jfw.asc
[23:17] wotbot: Registered jfw with key 0CBC05941D03FD95C3A47654AE0DF306025594B3
[23:17] jfw: !w register http://jfxpt.com/jfw.asc
[23:17] wotbot: jfw: failed to register key: IntegrityError: 1062 (23000): Duplicate entry 'jfw' for key 'name'
[23:17] jfw: !w register http://jfxpt.com/jfw.asc
[23:17] wotbot: Error: jfw is already registered.
[23:18] jfw: and a flawless move from Gales to CentOS 6.
[23:20] jfw: which is something considering the older versions of both mysql and python.
[23:22] jfw: I'm quite satisfied for today, feel free to play around with it, all; I'll consider it in a testing phase where mistakes/spills need not be permanent, I'll edit the database if needed.
[23:27] jfw: !w help
[23:27] wotbot: Available commands: hi, help, register
[23:28] jfw: ^ added to the bots list in sourcerer for dimming log lines.
Day changed to 2024-06-03
[03:20] jfw: ?w register http://127.0.0.1:99/
[03:20] wotbot_test: Error: jfw is already registered.
[03:21] jfw_yrctest: ?w register http://127.0.0.1:99/
[03:21] wotbot_test: jfw_yrctest: failed to fetch key: error: [Errno 111] Connection refused
[03:21] jfw_yrctest: ?w register http://jfxpt.com/non?existent
[03:38] jfw_yrctest: ?w register http://jfxpt.com/non?existent
[03:38] wotbot_test: jfw_yrctest: failed to fetch key: HTTPException: 404 Not Found
[03:41] jfw_yrctest: ?w register https://jfxpt.com/
[03:41] wotbot_test: Usage error: provide a plain HTTP link to your public key (and nothing more).
[03:41] jfw_yrctest: ?w register http://jfxpt.com/jfw.asc
[03:41] wotbot_test: jfw_yrctest: failed to register key: IntegrityError: 1062 (23000): Duplicate entry '0CBC05941D03FD95C3A47654AE0DF306025594B3' for key 'fingerprint'
[03:42] jfw: alright, that cleans up the error reports as a side effect of replacing that spaghetti-wrapper-layer urllib/urllib2.
[03:44] jfw: evidently I couldn't stay "satisfied for today", on realizing that my careful protocol whitelisting to work around urllib2's promiscuity was bypassed anyway by its automatic redirect following.
[03:46] jfw: the underlying httplib is still kind of spaghetti, just not stacked quite as high.
[14:24] dorion: http://jfxpt.com/2024/jwrd-logs-for-Jun-2024/#11329 -- makes sense to me.
[14:24] sourcerer: 2024-06-02 22:51:00 (#jwrd) jfw: but he would be polluting the key-to-name lookup results. I guess the consistent approach would be to require rsa verification to accept any registration
[14:25] dorion: !w register http://dorion-mode.com/dorion.asc
[14:25] wotbot: Registered dorion with key 54CCA1FC8C2E414C63BFB6CF0E48266E54D6B95A
[14:26] dorion_road: !w register http://dorion-mode.com/dorion_road.asc
[14:26] wotbot: Registered dorion_road with key 97F67F263AA40F88AAD55E07F42D90E5D4A556E4
[14:27] dorion_road: !w help
[14:27] wotbot: Available commands: hi, help, register
[14:27] dorion_road: !w hi yoyo
[14:27] wotbot: Hello there, dorion_road
[15:16] dorion: welcome back whaack.
[15:17] whaack: gm dorion
[15:21] dorion: what's new ?
[15:23] whaack: starting a biz here with billymg , constructed related
[15:24] dorion: cool. is it the gutters you mentioned ?
[16:02] whaack: dorion: atm we're going with insulation & sealing, but we'll adjust as the market needs
[16:07] jfw: is insulation even a thing in CR? I guess for improving AC efficiency in the guanacaste heat
[16:12] whaack: jfw: it's not, we want to make it a thing, and yes it's ac efficiency and humidity control
[16:22] whaack: also to help reduce critters
[16:53] jfw: yeah I figured that for the sealing, then once the air is in place it could make sense to insulate. I guess the target market would be foreigners or those looking to build for or rent to them
[16:55] jfw: at least that would seem the easier sale, people who know what it is or even expect it, not that you can't try educating the locals too
[16:58] whaack: we're going for wealthier expats that want their house built better than local construction standards offer
[17:00] jfw: right, since billymg has been there & had to learn about navigating it
[17:01] whaack: mhm
Day changed to 2024-06-04
[04:42] jfw: !w down jfw
[04:43] jfw: hm, I can down myself but the bot can't?
[04:44] jfw: oh I keep mixing up the prefix for the test vs production bot.
[04:44] jfw: ?w down jfw
[04:44] jfw: ?w up jfw
[04:44] jfw: ?w down jfw
[04:44] jfw: testing
[04:47] jfw: ok I guess my channel op status overrides my lack of voice, when moderation is enabled.
[04:48] jfw: ?w up jfw_yrctest
[04:48] jfw_yrctest: hear me?
[04:48] jfw: ?w down jfw_yrctest
[04:51] jfw: sweet. bot now responds to PMs and you can voice and devoice yourself on a channel (from PM), or someone else (from the channel). next up is to implement the gpg challenge and use that to authenticate the up-self-from-PM case.
[04:53] jfw: and I suppose I'll want to give it the seekrit coads to op itself sooner rather than later, or else I'll have to keep manually opping it on every redeploy.
[04:56] jfw: !w up jfw
Day changed to 2024-06-05
[04:39] jfw: seems I make a lot of basic variable name mistakes in python coding, which any static language would have caught up front. spoiled by c!!!
[04:41] jfw: using modules I didn't yet "import".
[04:46] jfw: sigh, looks like you can't just place an armored/exported gpg pubkey as pubring.gpg and have it work, must "import" every time.
[05:01] jfw: gpg refuses to encrypt ("encryption failed: unusable public key") because of its "trust model"; python refuses to read from a socket ('_socketobject' has no attribute 'read' even though at the unix level a connected socket can certainly be used with the read syscall)
[05:03] jfw: I have to call it "recv" because there's somehow a difference? meaning I can't use it with a generic reading routine?
[05:05] jfw: now I recall why my python stuff always ends up using os.read() level calls on file descriptors instead of the "friendly" file objects, ugh.
[05:20] jfw: thirteenth time's the charm: got my first bot-encrypted, fixpoint-pasted, mysql-stored one-time password for authenticating a bot command (up from PM).
[05:26] jfw: the database backing for commands pending authentication, besides adding resilience to network weather, is because lots of them can build up and I didn't see much way to limit it without inconveniencing users or becoming *more* easily DoS attackable
[05:28] jfw: I'm having them expire, currently after 24 hours. but there's no set limit on how many keys can be registered and thus how many different names can send a command like "up" which necessarily can't be predicated on already having channel voice.
[05:29] jfw: limiting number of pending commands per username would be possible but annoying and of limited help due to the low cost of names.
[05:31] jfw: in the event of abuse, I guess the easiest thing would be to require voice in a designated channel in order to register, i.e. you need a human to let you in.
[05:36] jfw: the OTPs are 128 bits, hex encoded, so will be less painful to type than deedbot's 256. they're pure entropy i.e. no internal structure. they're hashed prior to storing in the database, to foil timing attacks on the index lookup and for general paranoia.
[05:40] jfw: looking up the decrypted code returned by the user and resuming the attempted command is next up to implement, i.e. so far it doesn't actually do anything visible.
[05:47] jfw: !w up #a #b
[05:47] wotbot: Usage error: give at most one channel name.
[05:47] jfw: !w up #jwrd
[05:47] wotbot: Usage error: in a channel, you must give at least one nick to set voice for.
[05:48] jfw: !w up #jwrd jfw
[05:48] jfw: !w up #someone-elses-chan jfw
[05:48] wotbot: Access error: in a channel, you can only set voice on the same channel.
[05:48] jfw: !w up jfw dorion
[05:48] jfw: !w up jfw,dorion
[05:54] jfw: ah, the channel mode command for multiple users needs to be like "MODE #channel +v nick1 +v nick2 +v nick3", that's a bother
[05:55] jfw: especially because fewer names will fit in that command than will fit in a multi-name up command to the bot.
[05:55] jfw: I guess I won't allow it then.
[06:01] jfw: !w up jfw dorion
[06:01] wotbot: Usage error: give at most one nick.
[06:02] jfw: !w up jfw dorion
[06:02] wotbot: Usage error: give at most one nick.
[06:03] jfw: that's better. anyway the main change there was to allow both channel and nick to be specified, in any order, either from chan or PM, but with proper validation.
[06:03] jfw: !w up dorion #jwrd
[06:03] jfw: !w down dorion #jwrd
[06:03] jfw: !w down #jwrd jfw
[06:08] jfw: http://jfxpt.com/2024/jwrd-logs-for-Jun-2024/#11415 - likewise, from PM you can only set voice for your own nick, if you give one at all.
[06:08] sourcerer: 2024-06-05 05:48:10 (#jwrd) wotbot: Access error: in a channel, you can only set voice on the same channel.
[06:09] jfw: but allowing both channel and nick to be named then makes it consistent with how the saved command pending authentication looks, since that has to include both.
[06:14] jfw: hm, I wonder if a securitywise-equivalent model without having to store pending commands server side would work.
[06:16] jfw: you'd just ask the bot for an otp, which you can then include with any command you need to authenticate. i.e. the otp needn't be tied to a specific command up front.
[06:18] jfw: it doesn't save the server from having to save those passwords and possibly lots of them, though, and it perhaps complicates command syntax and eats into the irc message length limit
[06:18] jfw: but it's somewhat less stateful at least
[06:21] jfw: ah, it allows a MITM to alter the command in flight once you send the password. forget about it.
Day changed to 2024-06-06
[23:13] jfw_testing: !w register http://jfxpt.com/paste/sftdsh4ixr
[23:13] wotbot: Registered jfw_testing with key 050AE6DCF5380EA8ED3DB8C82EFF9DE8FE659231
[23:14] jfw_testing: !w up #jwrd
[23:14] wotbot: Usage error: in a channel, you must give at least one nick to set voice for.
[23:14] jfw_testing: !w up #jwrd jfw_testing
[23:16] jfw_testing: !w up #jwrd jfw_testing
[23:16] jfw_testing: !w down jfw_testing
[23:21] jfw: another 'unusable public key' error; this time because I forgot I made that test key signing-only with no subkey. thus, just because gpg successfully imported a key doesn't necessarily mean it'll be able to encrypt to it, ugh.
[23:44] jfw_testing: !w register http://jfxpt.com/paste/r8nrgqgmya
[23:44] wotbot: Registered jfw_testing with key 2929155C57F2141124C23BB9598F64D25ABA2C1D
[23:49] jfw_testing: !w v e1f5f633d75a1e78bc6457d016983fbf
[23:49] wotbot: jfw_testing: OTP not recognized.
[23:49] jfw_testing: !w v
[23:49] wotbot: Usage error: give the decrypted password to verify (and nothing more).
[23:49] jfw_testing: !w v x y
[23:49] wotbot: Usage error: give the decrypted password to verify (and nothing more).
[23:49] jfw_testing: !w v x
[23:49] wotbot: jfw_testing: wrong OTP length (1/32 digits).
[23:50] jfw_testing: !w v e1f5f633d75a1e78bc6457d016983fbz
[23:50] wotbot: jfw_testing: bad hex digit 'z' at position 32 in OTP.
[23:50] jfw_testing: !w v 467a16237ab7f3013ee143ced7c3ece7
[23:50] wotbot: jfw_testing: OTP not recognized.
[23:58] jfw_testing: !w v 467a16237ab7f3013ee143ced7c3ece7
[23:58] wotbot: jfw_testing: OTP not recognized (not found).
Day changed to 2024-06-07
[00:12] jfw_testing: !w v 467a16237ab7f3013ee143ced7c3ece7
[00:12] jfw_testing: yee.
[00:12] jfw_testing: !w v 467a16237ab7f3013ee143ced7c3ece7
[00:12] wotbot: jfw_testing: OTP not recognized.
[00:12] jfw_testing: !w v e1f5f633d75a1e78bc6457d016983fbf
[00:15] jfw: failed at first due to the good old "expires < CURRENT_TIMESTAMP" versus "CURRENT_TIMESTAMP < expires" mixup.
[00:20] jfw: so now that's working, still need a thread to clean up expired entries from the table.
[00:20] sourcerer: 2024-06-05 05:40:23 (#jwrd) jfw: looking up the decrypted code returned by the user and resuming the attempted command is next up to implement, i.e. so far it doesn't actually do anything visible.
[00:22] jfw: but - we have a working authenticated voice system! "party like it's 1999" or what was it.
[02:17] dorion: w00tie w00t ! well done jfw !
[02:17] dorion: !w help
[02:17] wotbot: Available commands: hi, help, register, up, down
[02:17] dorion: !w help up
[02:17] wotbot: Available commands: hi, help, register, up, down
[02:18] dorion: !w help hi
[02:18] wotbot: Available commands: hi, help, register, up, down
[02:18] dorion: !w down
[02:18] wotbot: Usage error: in a channel, you must give at least one nick to set voice for.
[02:18] dorion: !w down dorion
[02:19] dorion: !w down dorion #jwrd
[02:20] dorion: echo
[02:22] dorion: http://jfxpt.com/2024/jwrd-logs-for-Jun-2024/#11427 -- this one removed voice though..
[02:22] sourcerer: 2024-06-05 06:03:25 (#jwrd) jfw: !w down dorion #jwrd
[05:31] jfw: dorion: it's because you don't have voice to start with (mode +v), the bot sends the command but there's no change so the server doesn't show anything. voice mode isn't presently enforced because the channel isn't set to moderated (mode +m).
[05:33] jfw: I see that "at least one" hint needs to change since http://jfxpt.com/2024/jwrd-logs-for-Jun-2024/#11420
[05:33] sourcerer: 2024-06-05 05:55:32 (#jwrd) jfw: I guess I won't allow it then.
[05:34] jfw: dorion: the one you linked showed the effect because I'd upped just prior.
[05:37] jfw: and yeah, documenting the command details would be in order but once they're more stabilized I'd say.
[05:38] jfw: http://jfxpt.com/2024/jwrd-logs-for-Jun-2024/#11420 - thank you!
[05:38] sourcerer: 2024-06-05 05:55:32 (#jwrd) jfw: I guess I won't allow it then.
[05:38] jfw: gah. http://jfxpt.com/2024/jwrd-logs-for-Jun-2024/#11470 - thank you!
[05:38] sourcerer: 2024-06-07 02:17:23 (#jwrd) dorion: w00tie w00t ! well done jfw !
[05:39] jfw: got that database cleaner thread now.
[05:39] jfw: !w down
[05:39] wotbot: Usage error: in a channel, you must give the nick to set voice for.
Day changed to 2024-06-08
[00:18] jfw: !w hi
[00:18] wotbot: Hello there, jfw
[00:18] jfw: !w up jfw
[00:18] jfw: !w down jfw
[00:18] jfw: !w up jfw
[00:18] jfw: !w down jfw
[00:20] jfw: now what did I break, the bot is running all the code to respond with challenge to my "up" from PM, but the message isn't coming through
[00:35] jfw: I see what I broke, it was in the course of adding PM command filtering and changing how command arguments are passed down (rating is different as it includes a string that may contain whitespace)
[00:36] jfw: mixed up the sender vs. recipient in the PM case (because it's backward from the channel case) so the bot was replying to itself.
[00:37] jfw: anyway, indeed now the bot responds to only 'up' and 'v' from PM.
[00:38] jfw_testing: !w v c8ed15cfcacd31290c0366766159dc26
[00:39] jfw_testing: !w rate jfw_testing
[00:39] wotbot: Usage error: give a name, numeric rating, and (optional) comment.
[00:39] jfw_testing: !w rate jfw_testing x
[00:39] wotbot: Usage error: rating value x not an integer.
[00:39] jfw_testing: !w rate jfw_testing 3.14159
[00:39] wotbot: Usage error: rating value 3.14159 not an integer.
[00:39] jfw_testing: !w rate jfw_testing 11 off the charts cool.
[00:39] jfw_testing: l0l
[00:39] jfw_testing: (the bot quit, for the logs.)
[00:44] jfw_testing: !w rate jfw_testing 11 off the charts cool.
[00:44] wotbot: Usage error: rating value 11 not in range [-10, 10].
[00:44] jfw_testing: !w rate jfw_testing -999999999999999999999999999999 off the charts cool.
[00:44] wotbot: Usage error: rating value -999999999999999999999999999999 not in range [-10, 10].
[00:45] jfw_testing: !w rate jfw_testing 10 epicenter of the universe.
[00:45] wotbot: jfw_testing: get your OTP: http://jfxpt.com/paste/iq2cipi84y
[00:45] jfw_testing: !w v 8fc49fb98df3f3999c13a07cc9ebf211
[00:45] wotbot: jfw_testing: rated jfw_testing 10
[00:46] jfw_testing: hm, missed the comment.
[00:46] jfw_testing: !w unrate jfw_testing
[00:49] jfw_testing: !w unrate
[00:49] wotbot: Usage error: give a name to unrate (and nothing more).
[00:49] jfw_testing: !w unrate x y
[00:49] wotbot: Usage error: give a name to unrate (and nothing more).
[00:49] jfw_testing: !w unrate jfw_testing
[00:49] wotbot: jfw_testing: get your OTP: http://jfxpt.com/paste/dnjwbvnpbz
[00:49] jfw_testing: !w v 8fc49fb98df3f3999c13a07cc9ebf211
[00:49] wotbot: jfw_testing: OTP not recognized.
[00:52] jfw_testing: removed the rating via PM and it responded there. '!w v' has to be allowed there for '!w up' purposes, so now not sure if I need to filter also what pending commands can be authenticated there...
[00:54] jfw_testing: I guess it could track also what channel the original command came through, so it can reply there, in addition to just the original sender name
[00:55] jfw_testing: !w rate jfw 10 Me, I think.
[00:55] wotbot: jfw_testing: get your OTP: http://jfxpt.com/paste/g48mhta5w8
[00:55] jfw_testing: !w v 059e54037397c8fda6f298f5896f0784
[00:55] wotbot: jfw_testing: OTP not recognized.
[00:55] jfw_testing: !w v 055b0ad8a90c60f0a0abe7d096730014
[00:55] wotbot: jfw_testing: rated jfw 10
[00:58] jfw: http://jfxpt.com/2024/jwrd-logs-for-Jun-2024/#11524 << because split(..., 3) doesn't mean split into 3 parts but split on three separators ie up to 4 parts, d'oh.
[00:58] sourcerer: 2024-06-08 00:46:13 (#jwrd) jfw_testing: hm, missed the comment.
[00:59] jfw_testing: !w rate jfw 10 Me, I think.
[00:59] wotbot: jfw_testing: get your OTP: http://jfxpt.com/paste/hnjvme8ggj
[00:59] jfw_testing: !w v 8b4bac0623d97cb4a68bd709efb5d244
[00:59] wotbot: jfw_testing: rated jfw 10 with comment: Me, I think.
[01:00] jfw_testing: !w rate jfw_testing -1 Not sure about this one.
[01:00] wotbot: jfw_testing: get your OTP: http://jfxpt.com/paste/7piktu6ckb
[01:00] jfw_testing: !w v 48796397fa686838f6ca5c56d7bc1992
[01:00] wotbot: jfw_testing: rated jfw_testing -1 with comment: Not sure about this one.
[01:00] jfw_testing: !w rate jfw_testing 0 Fully ambivalent.
[01:01] wotbot: jfw_testing: get your OTP: http://jfxpt.com/paste/x3pitwtv54
[01:02] jfw: it doesn't matter who's the messenger of the OTP, since the effect is fixed:
[01:02] jfw: !w v 1850888154b68f213f048c4b406eb3de
[01:02] wotbot: jfw_testing: rated jfw_testing 0 with comment: Fully ambivalent.
[01:06] jfw: !w rate nobody 10
[01:06] wotbot: jfw: target nobody does not have a key registered.
[01:06] othertest: !rate jfw 10
[01:06] othertest: !w rate jfw 10
[01:06] wotbot: othertest: you do not have a key registered to this name.
[01:08] othertest: !w unrate dorion
[01:08] wotbot: othertest: you do not have a key registered to this name.
[01:08] jfw_testing: !w unrate dorion
[01:08] wotbot: jfw_testing: get your OTP: http://jfxpt.com/paste/9zy7yk77w9
[01:08] jfw_testing: !w v 69099b56b9344dd0cd983735742af4fb
[01:08] wotbot: jfw_testing: you have not rated dorion.
[01:09] jfw_testing: !w unrate nobody
[01:09] wotbot: jfw_testing: target nobody does not have a key registered.
[05:38] jfw: !w rate nobody
[05:38] wotbot: jfw: usage error: give a name, numeric rating, and (optional) comment.
[05:38] jfw: !w rate nobody 0
[05:38] wotbot: jfw: error: target 'nobody' does not have a key registered.
[05:40] jfw: various error messages have been tweaked, generally for more consistency, in the course of refactoring to make better use of exceptions.
[16:48] jfw: !w key ulysses
[16:48] wotbot: ulysses has no key registered.
[16:48] jfw: !w key jfw_testing
[16:49] jfw: !w key jfw_testing
[16:49] wotbot: jfw_testing has key 2929155C57F2141124C23BB9598F64D25ABA2C1D http://jfxpt.com/paste/2zn3pgq75v
[16:50] jfw: !w key jfw_testing spiderman jfw
[16:50] wotbot: jfw_testing has key 2929155C57F2141124C23BB9598F64D25ABA2C1D http://jfxpt.com/paste/7y2zrpjr9g
[16:50] wotbot: spiderman has no key registered.
[16:50] wotbot: jfw has key 0CBC05941D03FD95C3A47654AE0DF306025594B3 http://jfxpt.com/paste/5smiinxufa
[16:51] jfw: !w key
[16:51] wotbot: jfw: usage error: give at least one name to find the key for.
[16:53] jfw: !w key jfw
[16:53] wotbot: jfw: failed to connect to database.
[16:53] jfw: (good, that error is still handled correctly after the refactor.)
[17:34] jfw: !w key
[17:34] wotbot: jfw: usage error: give at least one name or key fingerprint to look up.
[17:35] jfw: !w key 0cbc05941d03fd95c3a47654ae0df306025594b3 0000000000000000000000000000000000000000 spiderman jfw_testing
[17:35] wotbot: jfw has key 0cbc05941d03fd95c3a47654ae0df306025594b3.
[17:35] wotbot: No key registered with fingerprint 0000000000000000000000000000000000000000.
[17:35] wotbot: No key registered for name spiderman.
[17:35] wotbot: jfw_testing has key 2929155C57F2141124C23BB9598F64D25ABA2C1D.
[17:36] jfw: nice, but I guess the hex should be normalized.
[17:38] jfw: !w key 0cbc05941d03fd95c3a47654ae0df306025594b3
[17:38] wotbot: jfw has key 0CBC05941D03FD95C3A47654AE0DF306025594B3.
[19:41] jfw: !w key jfw
[19:41] wotbot: jfw: error: failed to upload to paste service: socket error: [Errno 111] Connection refused
[19:42] jfw: !w key jfw
[19:43] jfw: !w key jfw
[19:43] wotbot: jfw has key 0CBC05941D03FD95C3A47654AE0DF306025594B3.
Day changed to 2024-06-09
[21:39] jfw: !w key jfw
[21:40] wotbot: jfw: error: failed to upload to paste service: empty response
[21:43] jfw: dammit netcat, never seems to behave quite as required. and there's so many different versions around.
[21:45] jfw: I'll just have to break the production paste briefly for this test.
[21:45] jfw: !w key jfw
[21:45] jfw: !w hi
[21:45] wotbot: Hello there, jfw
[21:48] jfw: !w key jfw
[22:02] jfw: http://jfxpt.com/2024/jwrd-logs-for-Jun-2024/#11401 - now I find this doesn't work with socket.settimeout, because under the covers that puts the socket in nonblocking mode. nor will it work using high-level pythonic wrapper file objects, as they point out "file objects returned by the makefile() method must only be used when the socket is in blocking mode; in timeout or non-blocking mode file
[22:02] sourcerer: 2024-06-05 05:05:43 (#jwrd) jfw: now I recall why my python stuff always ends up using os.read() level calls on file descriptors instead of the "friendly" file objects, ugh.
[22:02] jfw: operations that cannot be completed immediately will fail."
[22:05] jfw: so timeout can ONLY be used with the special socket.recv method, so I have to duplicate my really-read-everything input routine. or else use select() in which case why would I need python's timeouts. or go into OOP madness with subclassing sockets or something.
[22:06] jfw: "class CoolSocket(socket.socket)"
[22:09] jfw: !E help
[22:09] nzbtcexplorer: jfw: my valid commands are: src, uptime, version, help, view-height, view-address, view-utxos, view-balance, view-block, view-raw-block, view-tx, view-raw-tx, push
[22:09] jfw: !E uptime
[22:09] nzbtcexplorer: jfw: time since my last reconnect : 16d 7h 46m
[22:09] jfw: !E view-height
[22:09] nzbtcexplorer: block_height: 846917
[22:09] nzbtcexplorer: mins_since_last_block: 3176
[22:10] jfw: hm, a bit behind the times.
[22:10] jfw: !E view-block 846917
[22:10] jfw: !E uptime
[22:15] jfw: !E uptime
[22:17] jfw: thought so. just a lil' fire drill for paste service misbehavior :)
[22:17] jfw: !E uptime
[22:17] nzbtcexplorer: jfw: time since my last reconnect : 0d 0h 1m
[22:26] jfw: !w key jfw
[22:27] wotbot: jfw: error: failed to upload to paste service: socket error: timed out
[22:28] jfw: I went with duplicating the read routine for the file.read versus socket.recv cases, as it's pretty small in any case.
[22:29] jfw: !w key jfw
[22:29] wotbot: jfw has key 0CBC05941D03FD95C3A47654AE0DF306025594B3.
Day changed to 2024-06-10
[02:55] jfw: !whi
[02:56] jfw: !whi
[02:56] wotbot: Hello there, jfw
[02:56] jfw: !w hi
[02:56] wotbot: Hello there, jfw
[02:57] jfw: so either style can be allowed by simply not including the space in the configured callsign.
[02:57] jfw: !w rated nobody
[02:58] jfw: !w rated nobody
[02:58] wotbot: jfw: error: target 'nobody' does not have a key registered.
[02:58] jfw: (helps to actually deploy the changed code.)
[02:58] jfw: !w rated jfw
[02:58] wotbot: jfw has not rated jfw.
[02:58] jfw: !w rated jfw_testing jfw
[03:00] jfw: !w rated jfw_testing jfw
[03:00] wotbot: jfw_testing rated 10 jfw at None << Me, I think.
[03:00] jfw: lol
[03:01] jfw: !w rated jfw_testing jfw
[03:01] wotbot: jfw_testing rated jfw 10 at None << Me, I think.
[03:01] jfw: better but wtf is 'None' on a NOT NULL column ?!
[03:23] jfw: ugh, so by default mysql allows inserting without giving a value for the DATETIME NOT NULL field - or what I actually did here, ALTER TABLE to add the field later; either way it populates it with an invalid datetime, 0000-00-00 00:00:00, which python fails to load into a datetime object for multiple reasons (year out of range, invalid month & day values).
[03:24] jfw: connector/python then does perhaps the most reasonable thing under the circumstances and returns None.
[03:46] jfw: it's sql mode dependent and to some extent the inconsistency is reduced with newer mysql and/or by using innodb i.e. transactional tables.
[03:47] jfw: but even with server 5.6 and innodb and the default "STRICT_TRANS_TABLES" mode, the ALTER TABLE case still populates invalid values.
[03:51] jfw: !w rated jfw_testing jfw
[03:51] wotbot: jfw_testing rated jfw 10 at 2024-06-10 03:51:45 << Me, I think.
[03:53] jfw: !w rated jfw_testing jfw_testing
[03:53] wotbot: jfw_testing rated jfw_testing 0 at 2024-06-10 03:51:45 << Fully ambivalent.
[04:05] jfw_testing: !rate jfw 10 fresh new testing
[04:05] jfw_testing: !wrate jfw 10 fresh new testing
[04:05] wotbot: jfw_testing: get your OTP: http://jfxpt.com/paste/m5s8s48iwq
[04:06] jfw_testing: !wv 4e0e38a47a3b16457ed22926005773fd
[04:06] wotbot: jfw_testing rated jfw 10 with comment: fresh new testing
[04:06] jfw_testing: !w rated jfw
[04:06] wotbot: jfw_testing rated jfw 10 at 2024-06-10 04:06:33 << fresh new testing
[04:08] jfw: only quirk from that change is the instructions in the encrypted message now say to reply "!wv ...", which IMO obscures the difference between the callsign and the command
[04:08] sourcerer: 2024-06-10 02:57:17 (#jwrd) jfw: so either style can be allowed by simply not including the space in the configured callsign.
[04:11] jfw: whether the confusion is worth the brevity I can't say, at least it's easily configurable by the bot operator so I guess time will tell.
[04:15] jfw_travel: !w register http://jfxpt.com/paste/5g6ynkggig
[04:15] wotbot: jfw_travel registered with key 373A34FDAA556A3EB38C2AE7384B63C575D6E637
[04:17] xissburg: !w register http://jfxpt.com/paste/k8p7wce25t
[04:17] wotbot: xissburg registered with key 7A5F3BB4FF5D52A92C516C4CFFFC84B9B85D5CD1
[04:27] jfw: that's all the keys registered from who participated in the premine, such as it was; except for blakeeus whose nick I couldn't grab, guessing he's still connected from a ghost tmux somewhere. We'll reserve the nick for him.
[04:40] blakeeus_: !w register http://jfxpt.com/paste/tk4gfptqn9
[04:40] wotbot: blakeeus_ registered with key 35B99193B3EC26A6564B891E831E897AE54BD064
[04:42] jfw: nevermind re blakeeus - found the expedient hack, to register another name and then edit in db.
[04:42] jfw: !w key blakeeus
[04:42] wotbot: blakeeus has key 35B99193B3EC26A6564B891E831E897AE54BD064.
[07:05] lru: The world keeps ending, but noobs keep showing up as if the fun just started.
[07:05] lru: - http://ossasepia.com/2022/06/23/all-tattoos-are-temporary/
[07:06] lru: trilema.com is down... I've been poking around at old sites and haunts to see if anybody cared
[14:55] jfw: hello lru, and who or what might you be?
[14:56] jfw: would you begrudge the noobs their fun? what else would you have them do, drop dead? not everyone can be romantic enough for that
[15:01] jfw: as far as trilema.com, yes it's down, it's noticed and some people care, there's just not as many hands on deck now. I do expect it'll be back but can't say when.
[15:24] jfw: ah there is http://ossasepia.com/2020/04/22/ossasepia-logs-for-18-Apr-2020/#1024490 perhaps
[20:33] dorion_road: http://jfxpt.com/2024/jwrd-logs-for-Jun-2024/#11683 -- some are wise, others are otherwise.
[20:33] sourcerer: 2024-06-10 07:05:04 (#jwrd) lru: The world keeps ending, but noobs keep showing up as if the fun just started.
[22:46] lru: hi jfw... I considered myself a noob, although one that's been around for a long time in the shadows... I only posted that quote since I was reading ossasepia.com and found it funny in relation to the fact that trilema was down (end of the world) and noobs showing up asking about it (me)... perhaps that was a stretch at humour too far
[22:46] lru: but I'm glad to hear that people care about trilema.com and that it will be back
[23:12] jfw: lru: I see, I read it the wrong way, perhaps because for some reason I still see myself in general as a noob, thank you for clarifying. but yeah, we don't have the shared history whereby I might better guess what you meant or extend more credit
[23:12] jfw: I have to run but should be back in a couple hrs.
Day changed to 2024-06-11
[01:31] lru: no worries
[02:43] jfw: lru: so what happened after your short visit to #ossasepia I linked earlier? you got a bunch to read and so you happily returned to read-only mode?
[04:56] lru: jfw: yeah, pretty much, and I suspect a mental clash with V also had something to do with it. A software system of distributed patches across multiple servers doesn't seem like a very stable foundation to build on. Especially with sites going down from time to time, or forever.
[05:00] lru: I tend to favour git, where every user downloads a copy of every version that ever existed in that repo, whether they realize it or not, and it's easy. As opposed to leaving it hard to do the same thing manually.
[05:03] lru: of course, making things easy has its own risks, but making many copies of good software and making that process easy and default seems to me to be a good thing, even if that same tool is used to do the same for bad software, because, well, why handicap yourself?
[05:09] lru: I also prefer the git method of storing full files and comparing them later with diff, instead of V's (and possibly mercurials? and CVS's) method of storing diffs and later trying to cobble them together into full working files
[05:34] lru: http://btcbase.org/log/2018-09-18#1851362 <--- that view also shows a hint of wisdom, in my opinion... "eternal cauldron of bubbling liquishit" indeed... but "making changes expensive" will fly about as well as my theory that giving developers 486's will improve code speed... even if I'm right (and I suspect I would be) nobody wants to pay for that
[15:28] whaack: !e view-height
[15:28] btcexplorer: block_height: 847499
[15:28] btcexplorer: mins_since_last_block: -26
[15:28] whaack: !E view-height
[15:29] nzbtcexplorer: block_height: 846917
[15:29] nzbtcexplorer: mins_since_last_block: 5655
[15:29] whaack: looks like i'll have to give the nz box a kick
[16:14] jfw: http://jfxpt.com/2024/jwrd-logs-for-Jun-2024/#11698 - you should have said something, so the people around could have helped you find out where your mental processes went wrong; or else I suppose confirm themselves to be full of it in your evaluation, either way it'd be a win for you
[16:14] sourcerer: 2024-06-11 04:56:27 (#jwrd) lru: jfw: yeah, pretty much, and I suspect a mental clash with V also had something to do with it. A software system of distributed patches across multiple servers doesn't seem like a very stable foundation to build on. Especially with sites going down from time to time, or forever.
[16:18] jfw: in particular, nowhere in V is it required that downloading stuff be hard; the early versions had plenty of such practical difficulties, due to the fact of being early; many were improved over time, more could have been but for lack of functioning people to do it
[16:26] jfw: there was eventually a rift exposed between those who figured the prototypes were plenty good enough already, who tended to "use" them in the manner one uses a painting on the wall; and those who tried to use them for serious work and ended up doing a lot more to firm up the foundations
[16:34] whaack: jfw: i have 1 or 2 qs about how u disconnected nz bot i'll have to ask later as i'm doing some saltmines work atm
[16:34] whaack: cool stuff with wotbot
[16:34] jfw: differences over just which parts should be easy vs. hard, perhaps. but you can't look at those incentives just in terms of a tool in a vacuum, it's deeply linked to cryptographic identity, the WoT, the Republic at the time, or in other words the effort to build an actual functioning economy.
[16:34] jfw: whaack: sounds fine
[16:40] jfw: http://jfxpt.com/2024/jwrd-logs-for-Jun-2024/#11701 - heh, "trying to cobble together" is very much NOT what it is and really sounds a lot more like the git approach in practice. "the internet magically sends us pull requests and the tools make it so easy to slurp them all up"
[16:40] sourcerer: 2024-06-11 05:09:58 (#jwrd) lru: I also prefer the git method of storing full files and comparing them later with diff, instead of V's (and possibly mercurials? and CVS's) method of storing diffs and later trying to cobble them together into full working files
Day changed to 2024-06-12
[10:07] lru: well, speaking of asking questions, and its encouragement, here's a noob question: for those of you who live in the bitcoin economy, and I presume make a living there, selling goods and services for bitcoin, do you then repeatedly sell that bitcoin into whatever local currency you need to buy food, pay taxes, etc?
[10:32] lru: also, thanks to the nebulous people who brought trilema back
[13:19] dorion_road: lru, in general, you're likely to need local currency for dealing with people who don't speak Bitcoin. how you get the local currency is up to you, but in most places a cash dealer can be found who takes btc.
[21:59] jfw: !w gettrust
[21:59] wotbot: jfw: usage error: give the target name.
[21:59] jfw: !w gettrust jfw
[21:59] wotbot: Trust from jfw to jfw: Level 1: 0, Level 2: +0 via 0 / -0 via 0
[21:59] jfw: !w gettrust jfw_testing
[21:59] wotbot: Trust from jfw to jfw_testing: Level 1: 0, Level 2: +0 via 0 / -0 via 0
[21:59] jfw: !w gettrust jfw_testing jfw_testing
[21:59] wotbot: Trust from jfw_testing to jfw_testing: Level 1: 0, Level 2: +0 via 0 / -0 via 0
[22:00] jfw: !w rated jfw_testing jfw_testing
[22:00] wotbot: jfw_testing rated jfw_testing 0 at 2024-06-10 03:51:45 << Fully ambivalent.
[22:00] jfw: !w gettrust jfw_testing jfw
[22:00] wotbot: Trust from jfw_testing to jfw: Level 1: 10, Level 2: +0 via 0 / -0 via 0
[22:01] jfw_testing: !w gettrust jfw
[22:01] wotbot: Trust from jfw_testing to jfw: Level 1: 10, Level 2: +0 via 0 / -0 via 0
[22:02] jfw: looks good so far, now we just need some more ratings!
[22:04] jfw_testing: !w rate jfw_testing 10 sneaky self-rating
[22:04] wotbot: jfw_testing: get your OTP: http://jfxpt.com/paste/3uz9f6kzxt
[22:04] jfw_testing: !wv f3ede995ddfa5402b2dab833bff2fa3a
[22:04] wotbot: jfw_testing rated jfw_testing 10 with comment: sneaky self-rating
[22:04] jfw_testing: !w gettrust jfw_testing
[22:04] wotbot: Trust from jfw_testing to jfw_testing: Level 1: 10, Level 2: +0 via 0 / -0 via 0
[22:05] jfw: !w gettrust jfw_testing jfw
[22:05] wotbot: Trust from jfw_testing to jfw: Level 1: 10, Level 2: +0 via 0 / -0 via 0
[22:06] jfw: there's no foolin' the l2.
[22:13] jfw: http://jfxpt.com/2024/jwrd-logs-for-Jun-2024/#11720 - personally I prefer holding the bitcoins and selling body parts for food & tax money but sure, that's the idea
[22:13] sourcerer: 2024-06-12 10:07:13 (#jwrd) lru: well, speaking of asking questions, and its encouragement, here's a noob question: for those of you who live in the bitcoin economy, and I presume make a living there, selling goods and services for bitcoin, do you then repeatedly sell that bitcoin into whatever local currency you need to buy food, pay taxes, etc?
[22:19] jfw: (that's me making a joak, ftr.)
[22:21] jfw: what do you sell for your bread, lru?
[23:32] lru: lol, that was funny!
[23:32] lru: I sell computer services, admin, programming, and also physical labour where appropriate
Day changed to 2024-06-13
[14:57] whaack: !E view-height
[14:58] whaack: !e view-height
[14:58] btcexplorer: block_height: 847771
[14:58] btcexplorer: mins_since_last_block: 18
[14:58] whaack: !E uptime
[14:58] nzbtcexplorer: whaack: time since my last reconnect : 3d 16h 42m
[14:58] whaack: !E help
[14:58] nzbtcexplorer: whaack: my valid commands are: src, uptime, version, help, view-height, view-address, view-utxos, view-balance, view-block, view-raw-block, view-tx, view-raw-tx, push
[14:58] whaack: !E view-height
[14:58] nzbtcexplorer: block_height: 846917
[14:58] nzbtcexplorer: mins_since_last_block: 8504
[14:58] whaack: hm, never seen it drop a command, or was the response from the previous command, and there's another response coming?
[16:33] whaack: !E view-height
[16:33] nzbtcexplorer: block_height: 846919
[16:33] nzbtcexplorer: mins_since_last_block: 8588
[17:02] whaack: !E view-height
[17:02] nzbtcexplorer: block_height: 846939
[17:02] nzbtcexplorer: mins_since_last_block: 8391
[17:02] whaack: !e view-height
[17:02] btcexplorer: block_height: 847784
[17:02] btcexplorer: mins_since_last_block: -18
[17:23] jfw: whaack: there's a spurious control character in your http://jfxpt.com/2024/jwrd-logs-for-Jun-2024/#11753 , it displays here as ^P!E view-height
[17:23] sourcerer: 2024-06-13 14:57:49 (#jwrd) whaack: !E view-height
[17:34] jfw: whaack, any ideas on the puzzle? I'd think there are pretty big clues in the log from what I was talking about & testing on mine at the time
[17:34] sourcerer: 2024-06-11 16:34:23 (#jwrd) whaack: jfw: i have 1 or 2 qs about how u disconnected nz bot i'll have to ask later as i'm doing some saltmines work atm
Day changed to 2024-06-15
[04:01] lru: bitcoin question... if there existed an alternative to proof-of-work that had all the features except the high cpu requirement, would you switch to it? why or why not?
[04:46] jfw: lru, I don't think that question is really answerable as a vague hypothetical like that. you'd have to clarify at least what would make it a true alternative in your view
[04:49] jfw: to answer exactly as posed, no, because the requirement of consuming some earthly resource in order to modify the chain is *the* feature of proof-of-work, something that didn't do that wouldn't be a replacement at all
[04:56] jfw: thus, 'proof of stake' or any other such bitcoin-on-the-cheap scheme is, until proven otherwise, highly suspect because basically the author is saying they want it to be cheaper (for them, their masters or who knows) to tamper with
[06:29] lru: jfw: interesting... so in my view, a true alternative would have all the security features as proof-of-work, so that there would be no tampering with the new system either.... I just don't see how CPU usage has to be involved for that security guarantee, yet
[06:58] lru: the security guarantees should come from the protocol and the math, not who has the most powerful machine... if there should be a block every 10 minutes, then the protocol could say that a hash of time+blockchain_head = the target hash, and perhaps the wallet ID that most closely matches has the right to create the next block of the chain... the time, the blockchain_head, and the wallet IDs are all well-known
[06:58] lru: can be easily computed, but not easily forged or tampered with, nor easily guessed, since the transactions within that 10 minute period are random
[07:13] lru: using wallet IDs as the comparison may be the wrong pick... perhaps online node IDs are better, encouraging more nodes... but my point is that I suspect this is possible without proof-of-work
Day changed to 2024-06-16
[17:00] jfw: lru: what are these node/wallet IDs or how are they generated such that they're well known?
[17:03] jfw: or more to the point, such that I can't just regenerate a new set that's more favorable to me for the known blocks and thereby rewrite the chain?
[17:19] jfw: it's a "history books are written by the winners" problem, if you will; how's a newcomer to evaluate who was "in the right" at the time?
Day changed to 2024-06-17
[09:27] lru: jfw: my first idea, when thinking "wallet ID", was that all data to make the decision would be in the blockchain, and therefore unable to forge or manipulate in advance to get extra powers, so you'd have to have coin at some point in the past before you could participate in maintaining the blockchain... but you're right with the nodeID... there would need to be some record of service as a node to qualify
[15:32] jfw: lru: that sounds like "we'll make it impossible to manipulate by assuming it's already impossible to manipulate", then
[15:35] jfw: absent proof of work or similar, there is no "the blockchain" but an infinity of possible blockchains, all equally mathematically valid
[15:37] jfw: although something to compensate nodes for their service of maintaining the history rather than just miners for their service of finding the next block could be an improvement
[20:08] lru: jfw: ok, this is getting to the heart of the matter for me, which is good... what is it that makes proof of work special in this regard? if everyone can calculate easily who the next "winner" is based on the existing blockchain and some rules, how is that different than everyone being able to easily calculate that block "X" does indeed solve the current difficulty of the proof-of-work problem?
[20:11] lru: my goal when switching to "Node ID" was dual purpose, in that I wanted to avoid the incentive to add spurious wallet IDs to the blockchain, and reward actual nodes... so that is still a problem to be solved, but if a "pure calculation" method resolves all the incentives properly, I don't see how proof-of-work is still better, yet.
[20:13] lru: and then there's the whole "Hashgraph" idea (hedera.com) which I haven't wrapped my head around yet, but promises to solve the byzantine generals problem too
[21:38] jfw: lru: ok, to clarify this a bit:
[21:38] sourcerer: 2024-06-17 15:35:10 (#jwrd) jfw: absent proof of work or similar, there is no "the blockchain" but an infinity of possible blockchains, all equally mathematically valid
[21:39] jfw: with PoW, there is technically also that same infinity of possible blockchains. the difference is that it costs money to discover them!
[21:42] jfw: 'if everyone can calculate easily who the next "winner" is based on the existing blockchain and some rules' - but lacking an authority to say which is the "existing blockchain", they cannot come to an agreement. because everyone has their own blockchain based on their own (actual or preferred) view of events.
[21:45] jfw: if it's an authority based on earthly force, you have yourself a state currency; while if it's based on proven computational power, you have bitcoin.
[21:54] jfw: http://trilema.com/2020/forum-logs-for-31-oct-2017/#2356179 is all that comes up re 'hashgraph', doesn't look like it found anyone serious to advocate for it in the forum
Day changed to 2024-06-18
[22:58] jfw: http://jfxpt.com/2024/jwrd-logs-for-Jun-2024/#11795 - looking a bit into how these byzantine generals and their problems are used, it seems that Bitcoin solves the significantly more general problem; thus, while there can certainly be improvements made in the field of byzantine fault tolerant systems, these do not amount to an improved Bitcoin.
[22:58] sourcerer: 2024-06-17 20:13:53 (#jwrd) lru: and then there's the whole "Hashgraph" idea (hedera.com) which I haven't wrapped my head around yet, but promises to solve the byzantine generals problem too
[23:04] jfw: I also looked briefly into that hedera/hashgraph thing since indeed it's not the first time I hear of it; one could dissect it from the technical side and notice the total lack of consideration for the Sybil attack; on the other hand, this bit from the governance side says it all, really, on their idea of decentralization:
[23:04] jfw: "Second, the hashgraph technology makes it possible for the Hedera Council to specify the software changes to be made to network nodes, precisely when those changes are to be adopted, and to confirm that they have been adopted. When the Hedera Council releases a software update, network nodes will have their software automatically updated at exactly the same moment. Any node with invalid software
[23:04] jfw: (i.e., one that didn?t install the software update) will no longer be able to modify the ledger or have the world accept their version of the ledger as legitimate."
[23:07] jfw: replace "Hedera Council" with "Federal Open Market Committee" as you see fit.
[23:10] jfw: lru: did you ever try running a btc node, by the way?
[23:18] jfw: oh this shit is just too good, "Hedera will make the code publicly available for anyone to review it (at Version 1.0), while ensuring stability by using hashgraph software patents defensively to prevent forks."
[23:20] jfw: so not only is it a closed network where only the annointed ones may operate nodes, but don't even think of running your own version of the network because they'll sue you. defensively.
[23:22] jfw: pretty clear now why they didn't want in to bitcoin's web of trust; which is why that's such a darn good heuristic just by itself.
Day changed to 2024-06-19
[04:19] lru: jfw: lol, good find... suing defensively indeed, thanks
[04:23] lru: I have not run a btc node yet... I once tried to run a monero node, as my hardware is slow and small, and the monero blockchain was smaller at the time. I'm encouraged to read, on your blog and elsewhere, that a 1T drive and a 4G RAM machine is enough to handle a full BTC node
[04:24] lru: the largest disks I have are about 500G
[04:24] lru: if I really want to just get a feel for it, I suppose I can run my own mini-multi-node btc network from the start
[04:25] lru: start mining my own at block 1 :-)
[04:36] lru: jfw: thanks for http://jfxpt.com/2024/jwrd-logs-for-Jun-2024/#11798 I certainly don't want to base it on earthly force, but math... same as PoW, but more efficient. I'm starting to think I need to write a blog post and hope someone carefully critiques it
[04:36] sourcerer: 2024-06-17 21:39:47 (#jwrd) jfw: with PoW, there is technically also that same infinity of possible blockchains. the difference is that it costs money to discover them!
[06:08] lru: jfw: your kind responses have inspired me to finally put this in document form, assembled from my notes over the years, thank you... if you have time and interest, I'd be grateful for any points and criticisms I may have overlooked. http://digon.foursquare.net/bitcoin/TaC.html
[15:39] jfw: even 4G RAM is likely overkill after my last round of work but yeah the storage is what it is
[15:43] jfw: http://jfxpt.com/2024/jwrd-logs-for-Jun-2024/#11816 - actually that'd be an idea for testing out the mining code in the reference implementation since afaik nobody's touched it in a good decade. you'd just need to remove the builtin checkpoint at block 195000
[15:43] sourcerer: 2024-06-19 04:25:06 (#jwrd) lru: start mining my own at block 1 :-)
[16:29] jfw: lru: you're welcome, but it seems unlikely I'll be swayed by your proposal if you haven't yet appreciated the problem that PoW solves
[16:30] jfw: why do you care about this sort of "inefficiency" anyway, how is it a problem for you?
[19:56] lru: jfw: that's what I'm trying to do... appreciate, or even understand the problem that PoW solves... it's been a problem for me ever since the beginning, and made the system and design seem wrong to me, but in a way that I couldn't fully explain... I haven't participated in nor trusted bitcoin because of it. Sure, I've lost out in untold millions, probably... I was technical enough to be a miner at the beginning.
[19:57] lru: but I didn't want to sink my time, effort, or finances into a system that did not make sense... many aspects made amazing senese, but PoW did not
[20:04] lru: it also puzzles me why bitcoin fans seem married to PoW to such an extent that they *like* it... it is almost a cherished aspect of the system, to be able to burn megawatts of power on a digital racetrack... I do appreciate that there have been many crooks who have wanted to undermine bitcoin's security, anonimity, and sovereignty by trying to suggest alternatives to PoW, and maybe bitcoiners have been burned
[20:04] lru: so often, their ears have grown deaf to any alternatives... I do not want to weaken bitcoin.
[20:06] lru: if anyone manages to poke a hole in my theories, I will thank them and abandon that version of the idea... but I am not yet convinced that PoW is the only way to solve the problems it solves
[20:08] lru: which is why I come to irc channels like this instead of the main bitcoin development lists, but maybe I'm mistaken
[20:09] lru: I found it very interesting to find on your blogs (yours and dorion's I think) the idea that miners will someday defect and kick start a new round of bitcoin
[20:09] lru: that sounds to me like a giant sign that PoW is a liability that needs to be fixed someday
[20:14] lru: bitcoin-without-PoW or bitcoin 2.0, will likely have to start as a brand new coin, to avoid the problems of hardforking... if you are right, then this defection is an opportunity that I should be working on now
[20:15] lru: anyway, at least I have a document to share with anyone who wishes to read it
[20:17] lru: I very much like what I've read on your blogs, how the Intel Management system has inadvertently put downward pressure on hardware requirements, so that bitcoin can run on old, slower, smaller, hardware... that is a precious feature, and something that PoW is completely against... if the world goes to hell in a handbasket like many predict, that low-resource nature of bitcoin, combined with a low-resource form
[20:17] lru: of "anti-mining" (for lack of a better word) could be a very useful thing
[22:22] jfw: lru: is the objection coming from an environmentalist standpoint, like consuming energy is bad per se because it's hurting mother earth or something?
[22:23] jfw: do physical racetracks seem wasteful to you, too?
[22:24] jfw: anyways, if you say it just seems wrong and you can't say why, I don't have to pursue the point
[22:25] jfw: http://jfxpt.com/2024/jwrd-logs-for-Jun-2024/#11827 - not like anyone has an unchosen responsibility to fix your head; but I can keep poking if it's helpful
[22:25] sourcerer: 2024-06-19 20:04:46 (#jwrd) lru: it also puzzles me why bitcoin fans seem married to PoW to such an extent that they *like* it... it is almost a cherished aspect of the system, to be able to burn megawatts of power on a digital racetrack... I do appreciate that there have been many crooks who have wanted to undermine bitcoin's security, anonimity, and sovereignty by trying to suggest alternatives
[22:33] jfw: http://dorion-mode.com/2023/04/the-ownership-of-bitcoin-custody-transactions-and-dispute-resolution/#footnote_17_1621 is one place the miner defection point came up; hard to say how far off that is but seems like a while yet.
[22:37] jfw: so the grail you seek is a way to secure the chain without having to pay for it. sounds rather like the perpetuum mobile to me, though I can't as yet disprove the possibility. perhaps we haven't yet invented the calculus to come up with notions like conservation of energy.
[22:40] jfw: "so that bitcoin can run on old, slower, smaller, hardware... that is a precious feature, and something that PoW is completely against" - um, you do realize that nobody is CPU mining anymore?
[22:49] jfw: but generally the only security that miners give two shits about is their own physical capital; the need to trust the hardware is mostly a concern for those running nodes, holding & transacting coin
[22:50] jfw: now as to your 'time and chain', if I'm following, it sounds like it comes down to mostly... proof of IP address, of all things.
[22:53] jfw: which rather makes me suspect you don't know much about how IP addresses work, lolz. but for starters consider that it favors spammers & botnets that are good at dodging such obstacles, plus large ISPs or other institutions that control large blocks, and inconveniences everyone else
[22:55] jfw: moreover, you don't even seriously consider how to prove it, but handwave it as an afterthought
[22:56] jfw: to try to get a little closer to the root of it: do you know what the sybil attack is?
[23:18] jfw: also we don't have to get into it now but ftr I can't let this political point slide: dorion & I don't recognize any such "main development lists" as legitimate, it's all been quite hijacked by softforkers of various descriptions.
[23:18] sourcerer: 2024-06-19 20:08:22 (#jwrd) lru: which is why I come to irc channels like this instead of the main bitcoin development lists, but maybe I'm mistaken
Day changed to 2024-06-20
[00:31] lru: physical racetracks are wasteful, yes, but I at least see the point to them, and don't object, and often enjoy them... PoW on the other hand, spends a lot of energy, but doesn't *do* anything... I mean, yes, it solves the problems right now, but is not viewed as a problem of its own
[00:32] lru: regarding sybil attack, yes, I was thinking about them under a different name... let's take a university with a giant IP address space... at least that "attack" places a full node on all those IP addresses... what does PoW give us in a similar practical vein?
[00:34] lru: I'm of course not married to IP addresses... if I can figure out a proof of node knowledge instead, that might be better
[00:38] lru: http://jfxpt.com/2024/jwrd-logs-for-Jun-2024/#11843 << "without having to pay for it" sounds like mockery, and it would be well placed if PoW actually paid for anything, but I don't believe it does... I believe there exists a formula X that achieves all the security that PoW does, without the empty repeated calculations... ideally, with as few calculations as possible
[00:38] sourcerer: 2024-06-19 22:37:58 (#jwrd) jfw: so the grail you seek is a way to secure the chain without having to pay for it. sounds rather like the perpetuum mobile to me, though I can't as yet disprove the possibility. perhaps we haven't yet invented the calculus to come up with notions like conservation of energy.
[00:39] lru: and you may be right that the calculus doesn't yet exit
[00:39] lru: exist*
[00:42] lru: regarding "main development lists", I was gathering that... I assume you run a full node yourself, and use your own bitcoind, and a number of others use the same bitcoind? I'm slightly impressed that all these different bitcoind's are still working together, even after all the attacks.
[00:43] lru: the potential unravelling of bc3 and sigwig (sp?) addresses in the future made for some fascinating reading
[00:43] lru: anyways, thanks for the pokes :-)
[00:44] lru: time to think about non-IP ways of identifying full, functioning nodes
[00:56] jfw: http://jfxpt.com/2024/jwrd-logs-for-Jun-2024/#11852 - they both do the same thing: tell you who wins!
[00:56] sourcerer: 2024-06-20 00:31:08 (#jwrd) lru: physical racetracks are wasteful, yes, but I at least see the point to them, and don't object, and often enjoy them... PoW on the other hand, spends a lot of energy, but doesn't *do* anything... I mean, yes, it solves the problems right now, but is not viewed as a problem of its own
[01:01] jfw: http://jfxpt.com/2024/jwrd-logs-for-Jun-2024/#11855 - mockery not intended, it seems exactly what you're looking for, "as few calculations as possible" even; perhaps it sounds to you less virtuous in those terms, dunno. coin holders pay miners via inflation and transaction fees. what they get for that could be debated but the payment is clear
[01:01] sourcerer: 2024-06-20 00:38:50 (#jwrd) lru: http://jfxpt.com/2024/jwrd-logs-for-Jun-2024/#11843 << "without having to pay for it" sounds like mockery, and it would be well placed if PoW actually paid for anything, but I don't believe it does... I believe there exists a formula X that achieves all the security that PoW does, without the empty repeated calculations... ideally, with as few calculations as possi
[01:07] jfw: what they get for it in theory, which you don't seem to grasp, is that an attacker will have to expend even more real value, and increasingly so over time. that's the only security there can ever really be: economic.
[01:08] jfw: it's like having a gold vault, "what use are all these armed guards I'm paying for? all they do is sit around"
[01:09] jfw: http://jfxpt.com/2024/jwrd-logs-for-Jun-2024/#11860 - segwit, but sigwig is a pretty great misspelling.
[01:09] sourcerer: 2024-06-20 00:43:12 (#jwrd) lru: the potential unravelling of bc3 and sigwig (sp?) addresses in the future made for some fascinating reading
[01:22] jfw: http://jfxpt.com/2024/jwrd-logs-for-Jun-2024/#11853 - so they put all the IPs on one box. costs ~nothing. and costs the same ~nothing to hold onto the IPs as long as they like, eternal king of the network that you've handed them. hashes on the other hand cost something to produce, every single time.
[01:22] sourcerer: 2024-06-20 00:32:27 (#jwrd) lru: regarding sybil attack, yes, I was thinking about them under a different name... let's take a university with a giant IP address space... at least that "attack" places a full node on all those IP addresses... what does PoW give us in a similar practical vein?
[01:25] jfw: and I'll annoyingly predict that any other 'node ID' scheme you come up with will fail in the same way - it will be cheap at least for certain players to print all the IDs they want. because that's what you're optimizing for. or else they're not cheap, in which case you're just reinventing some more complicated PoW.
[01:33] lru: http://jfxpt.com/2024/jwrd-logs-for-Jun-2024/#11867 << that could be tha I'm missing something there, but I view the security of the blockchain itself, that is, all those chained sha256 checksums, as providing that security... each block added increases the security of the chain. I never viewed the PoW as adding much security to that chain, because the security of the sha256 checksum itself is already so high
[01:33] sourcerer: 2024-06-20 01:07:28 (#jwrd) jfw: what they get for it in theory, which you don't seem to grasp, is that an attacker will have to expend even more real value, and increasingly so over time. that's the only security there can ever really be: economic.
[01:34] jfw: ever done a "git rebase"? you make your change at whatever depth and then just recompute all the checksums, what
[01:45] lru: true, and if the university sybil attack could guarantee a large enough match field, they could rebase the blockchain regularly... similar to the 51% attack I suppose... my goal was to have the forward pointing decisions spread out randomly, and sybil defeats that if it's high enough
[01:47] jfw: what's a "forward pointing decision" I wonder?
[01:50] lru: it's how I want to use the blockchain itself, plus current time, to decide the winner... nothing outside the blockchain except the timestamp is used, limiting attacks. If Node A won at blockchain block #5000, he will always win at #5000, because the history itself determines it
[01:50] lru: each new block should scatter the winner randomly through the blockchain history
[01:51] lru: I originally thought wallet ID, but trying to limit it to useful nodes to kill two birds with one stone
[01:52] jfw: unless owner of node A also owns node B (or bribes its owner) which won at block 5000-N, who tweaks the hash until A is the winner of 5000 in the revised history.
[01:54] lru: sure, but then they would be duplicating a PoW attack within the 10 minute window, but instead of matching a minimum set of bits, they need to match the maximum set of bits for Node A to win
[01:57] jfw: only more bits than anyone else. which won't be hard since you suppose nobody else is 'mining'.
[01:59] jfw: and they're not constrained to 10 minutes to do it, if they miss the deadline they'll simply switch to targetting 5001, it's a series of random guesses so there's no "progress" lost
[02:00] lru: doesn't your idea of attack call into question the security of sha256 itself though?
[02:00] lru: if 5001 is the new base, any progress made in 5000 is lose
[02:00] lru: lost*
[02:01] lru: although it's all shooting in the dark, you're right, but the target in the dark does keep moving
[02:02] jfw: mno, you don't make "progress" buying lottery tickets. and no it doesn't require reversing sha.
[02:03] jfw: I have to sign off but maybe give it a reread and some more mullig
[02:03] jfw: *mulling
[02:03] jfw: should be back tomorrow
[02:05] lru: thanks for the pokes! :-)
[02:08] jfw: ah, I'd just suggest, do try thinking more from the attacker's perspective, it's essential in cryptography.
[02:09] jfw: or I suppose in any other game, for that matter.
[09:57] lru: http://trilema.com/2014/the-woes-of-altcoin-or-why-there-is-no-such-thing-as-cryptocurrencies/#comment-155626
[09:57] lru: http://trilema.com/2014/the-woes-of-altcoin-or-why-there-is-no-such-thing-as-cryptocurrencies/#comment-155630
[09:57] lru: Wish I could ask why
[09:58] lru: ntp is one of the basic services I install on servers, about as basic as wget or ls, so to me that's a surprise
[16:44] jfw: he's not talking about the size or availability of the code or something like that. what is the topology of ntp, the protocol? otherwise put, what does it do?
[16:52] jfw: (iirc it was discussed a bunch in the logs too in the earlier days, partly in context of the desire for fully-hands-free nodes using the Pogo and such, which never materialized)
[17:24] jfw: http://jfxpt.com/2024/jwrd-logs-for-Jun-2024/#11882 - I see I overcomplicated things here to emphasize the sybil point. if the claim is that the winner of block N will always be its winner because history says so, it's readily contradicted: the winner of block N-1 can put out any number of different versions of his block, favoring who he pleases to win the next; the cost is low because no PoW is
[17:24] sourcerer: 2024-06-20 01:52:20 (#jwrd) jfw: unless owner of node A also owns node B (or bribes its owner) which won at block 5000-N, who tweaks the hash until A is the winner of 5000 in the revised history.
[17:24] jfw: required. Then it extends to the winner of an older block too, by adding a linear amount of 'mining' work per block to ensure they win each step. the guesses required is on the order of the number of live node IDs, so no terahashes required.
[17:24] jfw: http://jfxpt.com/2024/jwrd-logs-for-Jun-2024/#11788 <<<<<<<
[17:24] sourcerer: 2024-06-16 17:19:06 (#jwrd) jfw: it's a "history books are written by the winners" problem, if you will; how's a newcomer to evaluate who was "in the right" at the time?
[22:36] lru: ok, so a new idea has emerged for me given that response: one could almost say that bitcoin uses PoW to soak up all possible CPU resources for its own security, as opposed to the non-PoW mechanism which leaves everyone's CPU's free to invent a possible attack (slightly tongue in cheek analysis, but still interesting idea) :-)
[22:43] lru: there *is* supposed to be a time limit in TaC, but perhaps 10 minutes is not enough of a challenge anymore to prevent creating blocks that favour your friends
[22:45] lru: jfw: re ntp: what does it do? it synchronizes time across a network of machines... if trust is a concern, you run your own NTP server on your own private network, with your own clock source
[22:48] lru: I don't believe that time needs to be millisecond precise for something like TaC, but having the network agree on the current time, within a few 10s of seconds, seems to be a small ask to me
[23:10] lru: jfw: I'm understanding your history books winner problem now, and added the attack to my TaC document, thanks!
[23:31] jfw: NTP operates as a star topology, receiving the time from a trusted central authority, traditionally the USG. kinda the opposite of p2p. and if you say each node can be his own time source, then great but NTP is no longer relevant to your protocol and you can't assume agreement on the current time across the public network.
[23:35] jfw: http://jfxpt.com/2024/jwrd-logs-for-Jun-2024/#11908 - sounds like a somewhat confused formulation but getting warmer perhaps.
[23:35] sourcerer: 2024-06-20 22:36:16 (#jwrd) lru: ok, so a new idea has emerged for me given that response: one could almost say that bitcoin uses PoW to soak up all possible CPU resources for its own security, as opposed to the non-PoW mechanism which leaves everyone's CPU's free to invent a possible attack (slightly tongue in cheek analysis, but still interesting idea) :-)
[23:41] jfw: I mean, it's not "all possible cpu", and cpus aren't likely to be inventing anything, current "AI" buzz notwithstanding
[23:43] lru: PoW is almost a misnomer, when I think about it now... a better name might be proof of power, because there is a time element involved, even in PoW
[23:43] lru: if I use the terms as physics uses them
[23:44] lru: as for my tongue-in-cheek analysis, yes, I realize not all cpu, or even fpgas :-)
[23:46] jfw: the term seems fine to me, it proves execution of a certain expected number of hashes, no time component. power then would be the rate at which you can solve blocks.
[23:47] lru: right, but given how PoW works, the required power increases over time, as more computing power comes online, thereby guaranteeing time without a clock
[23:49] jfw: I really can't tell what you're saying now. maybe stop thinking in terms of "almosts"s, lol. would you like to earn almost-money so you can put almost-food on the table in your almost-house?
[23:49] lru: lol
[23:51] lru: yeah, I hadn't realized all the problems of determining time and history, and so I couldn't fully appreciate what PoW was doing... but now I see a glimmer of it.
[23:52] lru: since I'm seeing a glimmer of it, I'm not surprised you're having trouble understanding what I'm saying just yet :-) this is more of a thank you for the pokes as I'm learning
[23:52] jfw: cheers then.
[23:52] lru: anyway, gotta go afk for a while, cheers
Day changed to 2024-06-21
[02:25] jfw: http://jfxpt.com/2024/blockchain-kindergarten-why-proof-of-work/
[06:54] lru: heh... next title "The Wallpaper Edition" :-)
Day changed to 2024-06-24
[17:48] Barbarian: Hello! Lost access to my discords a while ago due to dropping my PC in a move. Can I get a contact for Whaack?
[17:51] Barbarian: Ideally an email and a discord @ handle
[18:12] jfw: welcome back Barbarian
[18:15] jfw: try sticking around though so he can send you something, or better yet, get a gpg key and register it with the new bot, then we can encrypt things to you here
[18:15] sourcerer: 2024-06-06 23:13:49 (#jwrd) jfw_testing: !w register http://jfxpt.com/paste/sftdsh4ixr
[18:18] jfw: (and do back up the key, lest it too be dropped in the next move!)
[18:19] jfw: but how's it going otherwise?
[18:25] Barbarian: Will do, all is good with myself. All serious keys with bitcoins on them are stored safely away. I would store a GPG key in the same fashion. How is everything with you?
[18:28] Barbarian: * all is well
[18:31] Barbarian: By the way, haven't kept up. Does Gales linux support desktop managers/envs at all? I currently mainly use Arch for main PC and debian on laptops. Considering going for something a bit more barebones while still being usable as a daily workstation.
[19:41] Barbarian: Been an exciting year for myself. Initially via a bittensor subnet I've gotten into Been building quantitative systems for the prediction of BTC and Forex on the 1 hour timeframe. Been printing money with this and throwing it into BTC forlong term holdings. TAO The token of Bittensor moved up in price by about 12X sold a bunch. Also got a job offer from the team developing the prediction subnet for 300K a year, we ended up declining as the
[19:41] Barbarian: profits from privately trading with the systems were
[19:41] Barbarian: 2 about an OOM larger.
[22:37] Barbarian: do you guys have any suggestion for a trustworthy costa rican offramp? Needs to be in cash.
Day changed to 2024-06-25
[05:19] jfw: http://jfxpt.com/2024/jwrd-logs-for-Jun-2024/#11939 - no, though there is tmux for terminal management.
[05:19] sourcerer: 2024-06-24 18:31:43 (#jwrd) Barbarian: By the way, haven't kept up. Does Gales linux support desktop managers/envs at all? I currently mainly use Arch for main PC and debian on laptops. Considering going for something a bit more barebones while still being usable as a daily workstation.
[05:20] jfw: http://jfxpt.com/2024/jwrd-logs-for-Jun-2024/#11940 - damn, I'm a little jealous.
[05:20] sourcerer: 2024-06-24 19:41:53 (#jwrd) Barbarian: Been an exciting year for myself. Initially via a bittensor subnet I've gotten into Been building quantitative systems for the prediction of BTC and Forex on the 1 hour timeframe. Been printing money with this and throwing it into BTC forlong term holdings. TAO The token of Bittensor moved up in price by about 12X sold a bunch. Also got a job offer from the t
[05:22] jfw: http://jfxpt.com/2024/jwrd-logs-for-Jun-2024/#11937 - pardon me for having doubted.
[05:22] sourcerer: 2024-06-24 18:25:12 (#jwrd) Barbarian: Will do, all is good with myself. All serious keys with bitcoins on them are stored safely away. I would store a GPG key in the same fashion. How is everything with you?
[05:29] jfw: I'm alright; business grinds along, I've fixed a bunch of broken code, got a hosting service in the works, implemented a new WoT with IRC interface, and been moving to take better care of myself in a coupla ways.
[15:14] Barbarian: Was using a different text editor. Meant a few times more in trading than offer. OOM was for price of token. Good to hear that things are going well for you as well. What code are you primarily working on? Last I heard it was primarily focused on the RGB based data transmission hardware.
[16:01] jfw: Barbarian: ah, the old paste accident I suppose. perhaps you're thinking of the red-light fiber transceivers for air gapping? there hasn't been much active work on those, they're not perfect but they work and the supplier still delivers so it's not their turn for optimization yet
[16:04] jfw: I made a bunch of fixes for busybox tar for gales, for bitcoind, and assorted other work, see http://jfxpt.com/category/software/
[16:29] whaack: Hey Barbarian: I'm around, leave me a message here and i'll get back to you. And yes gpg is the way to go if you want to send a priv message.
[16:30] whaack: jfw: I did figure out the puzzle, i now know why the bot crashed, idk when i'll get to fixing that tho
[16:30] whaack: !E view-height
[16:30] nzbtcexplorer: block_height: 849456
[16:30] nzbtcexplorer: mins_since_last_block: 3
[16:30] whaack: !e view-height
[16:30] btcexplorer: block_height: 848833
[16:30] btcexplorer: mins_since_last_block: 6579
[16:30] whaack sighs
[16:38] jfw: didn't crash exactly as far as I knew, just got disconnected for ping timeout because it waited indefinitely for a response from the paste connection
[16:41] jfw: whether that's a problem or not is up to you I guess, you could say the paste service is simply a requirement for the bot to do anything useful anyway. in my case I'm building it to support multiple functions so I want the irc connection 'gateway' to stay solid no matter what happens to other components
[16:43] whaack: it did crash, not just d/c, if it were just a d/c it would be even less of a priority
[16:45] jfw: I see
[16:47] jfw: http://jfxpt.com/2024/jwrd-logs-for-Jun-2024/#11953 - also behind the scenes been implementing a mysql-php company database & customer portal application for a client, and consulting on a postgres-python-tkinter company db for another
[16:47] sourcerer: 2024-06-25 16:04:54 (#jwrd) jfw: I made a bunch of fixes for busybox tar for gales, for bitcoind, and assorted other work, see http://jfxpt.com/category/software/
[16:51] whaack: http://jfxpt.com/2024/jwrd-logs-for-Jun-2024/#11943 << I am that connection, but given your ph@t l00t idk if i can handle your volume lol
[16:51] sourcerer: 2024-06-24 22:37:03 (#jwrd) Barbarian: do you guys have any suggestion for a trustworthy costa rican offramp? Needs to be in cash.
[16:51] whaack: congrats on that
[17:26] jfw: Barbarian, what size trade are you looking for?
[17:53] Barbarian: Hey Will, Not looking to offramp much yet, just 50K to start. USD is highly preferable to CRC. How are things going for you?
[17:54] Barbarian: Btw, how do I get the indice of message? To use sourcerer bot.
[17:54] Barbarian: jfw: Barbarian: ah, the old paste accident I suppose. perhaps you're thinking of the red-light fiber transceivers for air gapping? there hasn't been much active work on those, they're not perfect but they work and the supplier still delivers so it's not their turn for optimization yet
[17:55] Barbarian: Responding to that: Just thought about it, wouldn't it be more efficient to use a QR based system? Since it's already established? Maybe just a custom data interpreter
[19:16] jfw: Barbarian: the channel logs are linked from the topic; sourcerer updates the current month's page in real time so you can get the unique URL for any line by clicking there.
[19:21] jfw: 'why not qr codes' would make a good FAQ entry actually. nothing wrong with them in principle, but they make for rather more complex hardware requirements (either webcam + associated driver headaches, or dedicated qr gun), more complex software to decode them (compared to just 'cat /dev/ttyUSB0' for example), and then you need to work out how to sequence/recombine packets if you need to send more
[19:21] jfw: than fits in one code
[19:30] jfw: and bear in mind that where security is concerned, 'more complex' means more time required to audit & more places for bugs or even vulnerabilities to lurk
[19:39] jfw: say... if you have a backup comms link that can't stay up, would that make it a... backdown connection?
Day changed to 2024-06-26
[14:14] whaack: Barbarian: Let me look into finding someone who is willing to sell 50k USD
[14:23] whaack: Barbarian: I am pretty sure I can connect you with someone, please get back to me asap. It may be easier to do 5 10k txs then 1 50k tx, jsyk
[14:32] whaack: also, make an offer for the price
[14:37] Barbarian: ls
[14:37] Barbarian: nvm the "ls" mistype.
[14:37] Barbarian: Thank you, that would be much appreciated. Will, are you down in the south? If so and if possible we would love to offramp 5K ASAP (Today if possible)
[14:50] whaack: Barbarian: No I am in Guana, i can ask contacts there if you'd like tho
[15:04] whaack: contacts in the south, to be clear
[15:07] whaack: Barbarian: plz make a price offer as well, i have ppl interested
[15:17] whaack: !e view-height
[15:17] btcexplorer: block_height: 848833
[15:17] btcexplorer: mins_since_last_block: 7946
[15:20] whaack kicks btcexplorer's bitcoind
[15:25] whaack: !e view-height
[15:25] btcexplorer: block_height: 848833
[15:25] btcexplorer: mins_since_last_block: 7954
[15:25] whaack kicks harder
[15:25] whaack: !e view-height
[15:25] btcexplorer: block_height: 848834
[15:25] btcexplorer: mins_since_last_block: 7934
[15:26] whaack smiles
[15:26] whaack: !E view-height
[15:26] nzbtcexplorer: block_height: 849575
[15:26] nzbtcexplorer: mins_since_last_block: 19
[15:46] Barbarian: Perfect, Re: Make a price offer: Has to be within 5% of BTC's market price. Ideally within 3%
[15:49] Barbarian: The most important thing for us is that these are trustworthy, discrete individuals.
[15:49] Barbarian: Also, we'd love to get your Whatsapp number.
[15:50] Barbarian: We are down in the south yes.
[15:56] Barbarian: you can get my email at Barbarian7676@proton.me and my Mother's at moxiegritandspit@proton.me.
[16:41] jfw: mom's got quite the email address
[17:12] whaack: Barbarian: alright msg'd you through heathen comms
[22:06] whaack: Barbarian: you interested in working on any btc projects? or focused on making more phat stax?
[22:07] whaack: bitcoindexplorer.com could use some paint and cleaning up for example
Day changed to 2024-06-27
[00:27] Barbarian: http://jfxpt.com/2024/jwrd-logs-for-Jun-2024/#12014 << depends. In any case I don't work on frontend at all. I've been doing some implementations of cryptographic algos in C, but that's about it. Maybe would be interested to work on a basic BTC implementation in C from scratch.
[00:27] sourcerer: 2024-06-26 22:07:20 (#jwrd) whaack: bitcoindexplorer.com could use some paint and cleaning up for example
[01:19] Barbarian: also would be interesting to work on some projects related to blockchain analytics. Find wallets that move a given amount to an exchange at a consistent time frequency.
[02:22] lru: that sounds like a problem for SQL :-)
[15:31] jfw: Barbarian: where are you looking to go with those projects & project ideas? like, is there a larger goal in mind yet?
[15:43] Barbarian: http://jfxpt.com/2024/jwrd-logs-for-Jun-2024/#12019 << For a basic BTC implementation in C I think it would be a good learning opportunity/side project. For the blockchain analytics project it could provide data that could be used within a trading system.
[15:43] sourcerer: 2024-06-27 15:31:25 (#jwrd) jfw: Barbarian: where are you looking to go with those projects & project ideas? like, is there a larger goal in mind yet?
Day changed to 2024-06-28
[02:36] jfw: Barbarian: ah good, you figured out the links. I could see that regarding the analytics - like if you can see lots of coin flowing into an exchange, you might bet that it's soon going to be sold. or some other less direct relationship, perhaps not readily rationalized but that a model might be able to pattern-match
[02:41] jfw: when you say btc implementation, does that mean a node basically? and you're seeing it as a solo project, for the fun & learning the workings of it?
[02:47] jfw: fwiw, my experience there has been that the best reference is unfortunately the code itself, and the code is rather a mess, such that I've had to work on cleaning it up bit by bit just in order to follow it; and by the time that happens, the code and my understanding both improve to the point where it's working pretty well and there's not much appeal left in rewriting it just because I could.
[02:47] jfw: present tense there because it's an ongoing process, hardly finished
[14:18] whaack: Barbarian: what do you think about starting a blog, to document these various projects you may be working on
[14:51] whaack: feels good to be back in CR
[20:24] Barbarian: Maybe for side projects I could start a blog. re: Back in CR >> Was recently in Europe. Felt good to be back in CR when we came back.
[20:44] Barbarian_: Wanted to add. Looked through JWRD logs. Whaack, what made you decide to get into the construction industry? Specifically insulation/sealing.
Day changed to 2024-06-29
[17:44] whaack: NY Barbarian: there's a need for it, and it's nice to do something totally different.
[17:44] whaack: Barbarian: * , not sure NY sneaked in there
[17:44] whaack: !e view-height
[17:44] btcexplorer: block_height: 849988
[17:44] btcexplorer: mins_since_last_block: -17
[17:44] whaack: !E view-height
[17:44] nzbtcexplorer: block_height: 849988
[17:44] nzbtcexplorer: mins_since_last_block: 12
[18:24] whaack: Barbarian: Where did you go in Europe?
[18:24] whaack: i hope to do a nice Euro tour soon
[18:24] whaack: may do so in 2025