Day changed to 2021-10-04
[19:46] dorion: apparently fartbook, whatscrapp and instascam are all shitting the bed today thanks to dns.
[19:54] dorion: apparently, making it phree to use in Panama isn't so free afterall and not only on the front that they're buying the data by paying the telecoms to make it "free" for the end lusers.
[21:33] jfw: "employees unable to enter buildings this morning to begin to evaluate the extent of outage because their badges weren't working to access doors" - but making everything dependent on the cloud was so convenient!
[21:34] jfw: dorion: I don't quite see a DNS angle though. If your routes are unpublished, neither that nor anything else will go through.
[21:36] jfw: presently facebook.com loads to a server-generated error page - well, "something went wrong" page since that's all anyone gets these days - suggesting loss of routes not the only fire burning over there. possibly internal failures cascading from it though.
[21:45] dorion: jfw, the linked article said they couldn't resolve facebook.com ; zone hedge article says DNS records were deleted.
[21:54] jfw: it said they couldn't resolve it but painted that as the effect not the cause.
[21:55] jfw: the zerohedge includes such gems as "The DNS records that tell systems how to find Facebook.com or Instagram.com got withdrawn this morning from the global routing tables", just in case we didn't know Krebs was a charlatan.
[22:02] dorion: I've "Ben Franklin's Almanac" here by the editors of "The Old Farmer's Almanac", it has a page for each day. Today there's a quote that goes, "Start by doing what's necessary ; then do what's poassible ; and suddenly you're doing the impossible." Attributed to St. Francis of Assisi, apparently today's his feast day.
[22:06] jfw: hm, that guy
[22:08] dorion: ah, nice.
Day changed to 2021-10-08
[14:31] dorion: jfw, so how was the miami bitcoinerz meet up ? I went to The Wallace last night for a short notice meetup. About 10 people, but pretty high quality for Panama at least.
[14:32] dorion: manual feedbot : http://dorion-mode.com/2021/10/sober-october/
[16:30] jfw: dorion: it was alright; informal conversations in an outdoor food trucks & park area (complete with parking, wouldn't have known any of it existed from the road).
[16:32] jfw: this one had a "no shitcoins" theme which was pretty well followed, though lots seemed to think "Layer 2/3" by which they mean p2sh/segwit based retail payment channel schemes were part of bitcoin.
[16:32] jfw: got a couple contacts to follow up with at least.
[16:33] jfw: LOT of people recently arrived from places north & west to take advantage of the freedom arbitrage.
[16:41] jfw: (not sure how it amounts to an arbitrage or what closes the loop - sending naked-face pics to scared friends back home I guess)
[17:25] dorion: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-Oct-2021/#2916 -- food trucks, eh ? those pretty prevalent there ?
[17:25] sourcerer: 2021-10-08 16:30:44 (#jwrd) jfw: dorion: it was alright; informal conversations in an outdoor food trucks & park area (complete with parking, wouldn't have known any of it existed from the road).
[17:27] dorion: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-Oct-2021/#2917 -- nice theme. myeah, by now the scalability sybil is pretty standard by now. any idea what percentage runs nodes ?
[17:27] sourcerer: 2021-10-08 16:32:07 (#jwrd) jfw: this one had a "no shitcoins" theme which was pretty well followed, though lots seemed to think "Layer 2/3" by which they mean p2sh/segwit based retail payment channel schemes were part of bitcoin.
[17:29] dorion: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-Oct-2021/#2920 -- well perhaps they're getting paid the higher wages of their lands of origin ? though with the wave of new blood, rising rents are probably mitigating the margins.
[17:29] sourcerer: 2021-10-08 16:41:28 (#jwrd) jfw: (not sure how it amounts to an arbitrage or what closes the loop - sending naked-face pics to scared friends back home I guess)
[18:11] jfw: dorion: I've only been to the city twice now and exploration on foot doesn't exceed maybe a two-block diameter, so I really can't say re food truck prevalence. There were maybe 4 in a semipermanent parking lot setup at this spot, prior to that I hadn't encountered any but it's a high-density neighborhood so I wouldn't really expect them to find parking.
[18:14] jfw: there were maybe 15 people all told over the interval. current guess as to running nodes would be 10% if we're to consider prb a node.
[18:15] jfw: and yeah it would be something like that, make the money from A but get the local upsides of B; don't know how many are doing that specifically though.
Day changed to 2021-10-21
[20:22] dorion: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-Apr-2021/#1834 -- jfw, no rush, but when you get a chance, would you mind teasing out the details a bit, i.e. how p2sh has always and necessarily been anyone can spend ? I see reading BIP 16 there is an attack explained, which seems to be narrowly classified as a 1 confirmation attack. narrow in the sense
[20:22] sourcerer: 2021-04-27 21:50:09 (#jwrd) jfw: addresses beginning with "3" have always worked on the basis of "anyone can spend", this being required for transactions spending them to make it into the actual Bitcoin network at all. I'd conjecture that a notion that "multisig" is somehow safer comes about because the "ANYONECANSPEND" term itself apparently
[20:22] dorion: that it doesn't consider the majority of the hashing power unwinding the softfork and collecting the booty.
[20:48] jfw: well I did at the time but perhaps it got lost amid the parallel thread? http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-Apr-2021/#1848 , http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-Apr-2021/#1855
[20:48] sourcerer: 2021-04-28 19:00:01 (#jwrd) jfw: 3-addresses, also known as "pay to script hash" or p2sh, were introduced by Gavin in 2012, in the linked BIP16 and related; in his own words : "Old implementations will validate that the {serialize script}'s hash value matches when they validate blocks created by software that fully support this BIP, but will do no other validation."
[20:48] sourcerer: 2021-04-28 19:10:25 (#jwrd) jfw: so to expand a bit re 3-addresses, all a non-gavinist node requires to accept a transaction spending away the coins in them, is any string that hashes to that address (after some other minor encoding transformations) - which is kindly provided by the "owner" of the coins when they broadcast their own unconfirmed transaction.
[20:50] jfw: this can be seen in the transaction template: OP_HASH160 [20-byte-hash-value] OP_EQUAL
[20:51] jfw: this is the so-called "script" of bitcoin, basically like pushing buttons on a calculator and seeing if it comes up true or false to decide whether the transaction is valid.
[20:51] jfw: the "buttons" however include stack operations and signature verification rather than just arithmetic.
[20:53] jfw: but it evaluates left-to-right, after concatenating the "signature" script in the spending input with the "pubkey" script in the output being spent. So the complete script will look like:
[20:53] jfw: ...signatures... [serialized script] OP_HASH160 [20-byte-hash-value] OP_EQUAL
[20:53] jfw: the [] there mean an implicit PUSH of a byte string.
[20:55] jfw: so when you get to the OP_HASH160, first the sigs and serialized (quoted) script have been pushed onto the stack. OP_HASH160 pops the first thing off the top, i.e. the quoted script, and hashes it.
[20:55] jfw: pushing the result back onto the stack.
[20:56] jfw: then the 20-byte (160-bit) target hash is pushed, and OP_EQUAL compares the top two things on the stack.
[20:56] jfw: if they're equal, the script has returned true. no checking of signatures has been done.
[20:59] jfw: the bip16 fork was that the core workings of the script machinery were twisted such that it will then additionally look inside that serialized script for further conditions (I haven't studied exactly how).
[21:20] jfw: dorion: so from the technical perspective, it's an ugly and totally pointless hack. the stated purpose at the time was to push multisig harder by lubing it up to make it fit easier into existing software and/or human protocols. then there's the political angle - might want to check the early threads leading to the TRB project though that could be a long dig.
[21:22] dorion: jfw, thanks for laying it out. yeah, I had primarily focused on the political angle so far, but wanted to round it out with a better understanding of the technical.
[21:23] jfw: I'm recalling something about 0.5.3 being the red line in the sand, unless I'm mixing my deserts.
[21:37] dorion: right, that was the furthest back they found they could go without breaking compatibility at the time (2014).
[21:38] jfw: did you find much from the time of the p2sh business itself (2012)?
[21:40] jfw: http://trilema.com/2012/the-politics-of-bitcoin/ perhaps
[21:57] jfw: (connection being that it was the Obsequious Party aligned institutions that were eager adopters of any and all forks)
[22:40] jfw: dorion: what do you think of the approach of using physical bullion as an intermediate hop in conversion of btc to/from fiat notes?
[22:41] dorion: ask in sell the btc for gold and then sell the gold for cash ?
[22:42] dorion: s/ask in/as in/
[22:43] jfw: like for example, you order gold bars in the mail, paid in btc; there's no "money transmission" involved since neither side of the transaction is money, it would seem to me. Or even viewing btc as money, it's a purchase of a physical product just like jewelry or whatever.
[22:43] jfw: then you just need to find a local bullion dealer.
[22:44] jfw: obviously it'd be better to have friends with piles of bank notes as well as their very own bitcoin nodes with sufficient balance to trade with - but these seem quite rare at least around here where people are a bit too comfortable using conbase et al.
[22:45] dorion: alright, what are the mark ups you're looking at ? I've heard anecdotally there's severe shortages of physical bullion.
[22:46] jfw: presumably a premium on the buy side there would wash out on the sell side?
[22:46] dorion: jfw, what about contacting all those atm operators in s. fla ? best canditates for raising cash would be those who operate machines that only accept cash and send btc.
[22:47] jfw: psh, addressing my root problem instead of the question I asked :P
[22:50] dorion: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-Oct-2021/#2961 -- well, do the calculations and then you'll know. it might not wash out. e.g. apmex will charge you a premium when you buy bullion. coin shop might only buy back bullion at discount. maybe it's still worth it if you're that desperate for the paper, but have to do the calculations.
[22:50] sourcerer: 2021-10-21 22:46:22 (#jwrd) jfw: presumably a premium on the buy side there would wash out on the sell side?
[22:51] jfw: at this stage I'm not that concerned about the margins, within reason, just exploring whether it's a viable approach at all.
[23:03] dorion: I hear you, I'd still start with looking for the atm operators who have cash that they need to turn into btc since their machines are only one way. don't know what percentage of the machines this represents, but it has the dual advantage of cutting out the extra person and making the relationship with local btc people rather than using a pm website operated from afar.
[23:03] dorion: granted, some of these machines are probably owned from afar, but they have to have people on the ground.
[23:04] jfw: yup. I don't recall spotting any BTMs so far but then I haven't sought them out.
[23:10] dorion: https://coinatmradar.com/city/473/bitcoin-atm-fort/lauderdale -- this reports dozen, for instance.
[23:16] jfw: supposedly 700 though the usual endless clicking required to get the list or details.
[23:20] jfw: perhaps worth doing an actual data liberation on it since everyone seems to point to the same site.
[23:21] jfw: one downside that stands out is btm operators are more likely to have signed whatever papers.
[23:29] jfw: there's still the MP prescription of going door to door around the nicer real estate armed with gift baskets and calling cards. seems mad time consuming.
[23:30] dorion: making relationships takes time, yeah.
[23:35] jfw: especially if you're bad at figuring out who's worth that time in advance.
[23:51] jfw: identifying the losers, or at least greater or lesser degrees of loserness which might be all you can ask for these days.
Day changed to 2021-10-23
[05:31] jfw: A particularly mind-boggling example from the trenches of the fractal insanity that is CMake: the CheckIncludeFiles directive doesn't honor the CMAKE_PREFIX_PATH or even CMAKE_INCLUDE_PATH
[05:31] jfw: variables, i.e. supposedly the normal & proper ways of telling it ...where to find include files. No, apparently it has a separate CMAKE_REQUIRED_INCLUDES variable for that, which you'd never find in looking for docs or even raw listings of the available knobs.
[05:34] jfw: ...and that would perhaps be because it doesn't work either.
[05:38] jfw: but why should I complain, after all the whole point of the thing is to be a multifaceted misdirection layer.
[05:53] jfw: but aaaanyway - MySQL 5.6 is now up and running on Gales, with datadir initialization nicely automated, and the mysql shell no longer segfaulting now that it's linked against the proper system readline library rather than its broken copy-n-pasted 'libedit' (snoracle tried to pull that switcheroo to escape GPL implications, but turns out a pretty weak effort - they didn't salt the earth)
[05:57] jfw: there is still a server segfault at startup when myisam_use_mmap is enabled - this was the most significant find from working the test suite, but it had got too hard to trace from amid the intricacies of that test environment, should be straightforward gdb'ing now.
[05:59] jfw: as far as older branches, 5.5 didn't seem to be of much interest as it was already fully CMake infected, and otherwise there didn't seem to be much categorical difference between the two, just a long list of tweaks & optimizations and such.
[06:09] jfw: fulltext indexing for innodb tables was new in 5.6 which is possibly of interest.
Day changed to 2021-10-24
[06:00] jfw: An' the mmaptronics bug is squashed too. It was a faulty CMake probe that broke down in the specific case of 64bit musl with _GNU_SOURCE mode disabled.
[06:04] jfw: that last part was what made me special enough to be the only one to hit this; perhaps I stepped on a rake, but having it enabled had caused a different fault and there was no clearly correct choice - a damned if you do & damned if you don't situation, so I went the route of disabling it to stick as much as possible to the "standards" path, esp. since mysql supports other non-GNU platforms fine.
[06:07] jfw: (the different fault: strerror_r, a particularly sore example where GNU and POSIX have mutually incompatible ideas of the same function, and glibc naturally provides both depending on the ifdef cocktail.)
[06:09] jfw: (no sufficient authority around to demand that everybody drive on the right already ffs.)
[16:55] jfw: https://bugs.mysql.com/bug.php?id=96027 - short and sweet summary of why 5.6 is the last true mysql; to quote for the record:
[16:55] jfw: "The cmake option DISABLE_SHARED was originally implemented to enable building of only static libraries. It has not been maintained since MySQL 5.6
[16:55] jfw: "With the current plethora of plugins and components, and dynamic linking of SSL and protobuf, the option no longer makes any sense. Remove it."
[16:56] jfw: GoogSQL.
Day changed to 2021-10-31
[05:15] jfw: http://fixpoint.welshcomputing.com/2021/muzzling-mysql-into-gales-shape-part-1-groundwork/
[17:38] jfw: among the wtfs still in the trb jalopy, the MIN_TX_FEE business whereby no matter what you set via settxfee, it applies a minimum of .0005 under some conditions - now well above the market rate
[17:44] jfw: and fancy that, the whole "blockchain congestion" thing disappeared once the fiat spam economy lost its purchasing power in btc.
[19:46] dorion: apparently fartbook, whatscrapp and instascam are all shitting the bed today thanks to dns.
[19:54] dorion: apparently, making it phree to use in Panama isn't so free afterall and not only on the front that they're buying the data by paying the telecoms to make it "free" for the end lusers.
[21:33] jfw: "employees unable to enter buildings this morning to begin to evaluate the extent of outage because their badges weren't working to access doors" - but making everything dependent on the cloud was so convenient!
[21:34] jfw: dorion: I don't quite see a DNS angle though. If your routes are unpublished, neither that nor anything else will go through.
[21:36] jfw: presently facebook.com loads to a server-generated error page - well, "something went wrong" page since that's all anyone gets these days - suggesting loss of routes not the only fire burning over there. possibly internal failures cascading from it though.
[21:45] dorion: jfw, the linked article said they couldn't resolve facebook.com ; zone hedge article says DNS records were deleted.
[21:54] jfw: it said they couldn't resolve it but painted that as the effect not the cause.
[21:55] jfw: the zerohedge includes such gems as "The DNS records that tell systems how to find Facebook.com or Instagram.com got withdrawn this morning from the global routing tables", just in case we didn't know Krebs was a charlatan.
[22:02] dorion: I've "Ben Franklin's Almanac" here by the editors of "The Old Farmer's Almanac", it has a page for each day. Today there's a quote that goes, "Start by doing what's necessary ; then do what's poassible ; and suddenly you're doing the impossible." Attributed to St. Francis of Assisi, apparently today's his feast day.
[22:06] jfw: hm, that guy
[22:08] dorion: ah, nice.
Day changed to 2021-10-08
[14:31] dorion: jfw, so how was the miami bitcoinerz meet up ? I went to The Wallace last night for a short notice meetup. About 10 people, but pretty high quality for Panama at least.
[14:32] dorion: manual feedbot : http://dorion-mode.com/2021/10/sober-october/
[16:30] jfw: dorion: it was alright; informal conversations in an outdoor food trucks & park area (complete with parking, wouldn't have known any of it existed from the road).
[16:32] jfw: this one had a "no shitcoins" theme which was pretty well followed, though lots seemed to think "Layer 2/3" by which they mean p2sh/segwit based retail payment channel schemes were part of bitcoin.
[16:32] jfw: got a couple contacts to follow up with at least.
[16:33] jfw: LOT of people recently arrived from places north & west to take advantage of the freedom arbitrage.
[16:41] jfw: (not sure how it amounts to an arbitrage or what closes the loop - sending naked-face pics to scared friends back home I guess)
[17:25] dorion: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-Oct-2021/#2916 -- food trucks, eh ? those pretty prevalent there ?
[17:25] sourcerer: 2021-10-08 16:30:44 (#jwrd) jfw: dorion: it was alright; informal conversations in an outdoor food trucks & park area (complete with parking, wouldn't have known any of it existed from the road).
[17:27] dorion: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-Oct-2021/#2917 -- nice theme. myeah, by now the scalability sybil is pretty standard by now. any idea what percentage runs nodes ?
[17:27] sourcerer: 2021-10-08 16:32:07 (#jwrd) jfw: this one had a "no shitcoins" theme which was pretty well followed, though lots seemed to think "Layer 2/3" by which they mean p2sh/segwit based retail payment channel schemes were part of bitcoin.
[17:29] dorion: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-Oct-2021/#2920 -- well perhaps they're getting paid the higher wages of their lands of origin ? though with the wave of new blood, rising rents are probably mitigating the margins.
[17:29] sourcerer: 2021-10-08 16:41:28 (#jwrd) jfw: (not sure how it amounts to an arbitrage or what closes the loop - sending naked-face pics to scared friends back home I guess)
[18:11] jfw: dorion: I've only been to the city twice now and exploration on foot doesn't exceed maybe a two-block diameter, so I really can't say re food truck prevalence. There were maybe 4 in a semipermanent parking lot setup at this spot, prior to that I hadn't encountered any but it's a high-density neighborhood so I wouldn't really expect them to find parking.
[18:14] jfw: there were maybe 15 people all told over the interval. current guess as to running nodes would be 10% if we're to consider prb a node.
[18:15] jfw: and yeah it would be something like that, make the money from A but get the local upsides of B; don't know how many are doing that specifically though.
Day changed to 2021-10-21
[20:22] dorion: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-Apr-2021/#1834 -- jfw, no rush, but when you get a chance, would you mind teasing out the details a bit, i.e. how p2sh has always and necessarily been anyone can spend ? I see reading BIP 16 there is an attack explained, which seems to be narrowly classified as a 1 confirmation attack. narrow in the sense
[20:22] sourcerer: 2021-04-27 21:50:09 (#jwrd) jfw: addresses beginning with "3" have always worked on the basis of "anyone can spend", this being required for transactions spending them to make it into the actual Bitcoin network at all. I'd conjecture that a notion that "multisig" is somehow safer comes about because the "ANYONECANSPEND" term itself apparently
[20:22] dorion: that it doesn't consider the majority of the hashing power unwinding the softfork and collecting the booty.
[20:48] jfw: well I did at the time but perhaps it got lost amid the parallel thread? http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-Apr-2021/#1848 , http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-Apr-2021/#1855
[20:48] sourcerer: 2021-04-28 19:00:01 (#jwrd) jfw: 3-addresses, also known as "pay to script hash" or p2sh, were introduced by Gavin in 2012, in the linked BIP16 and related; in his own words : "Old implementations will validate that the {serialize script}'s hash value matches when they validate blocks created by software that fully support this BIP, but will do no other validation."
[20:48] sourcerer: 2021-04-28 19:10:25 (#jwrd) jfw: so to expand a bit re 3-addresses, all a non-gavinist node requires to accept a transaction spending away the coins in them, is any string that hashes to that address (after some other minor encoding transformations) - which is kindly provided by the "owner" of the coins when they broadcast their own unconfirmed transaction.
[20:50] jfw: this can be seen in the transaction template: OP_HASH160 [20-byte-hash-value] OP_EQUAL
[20:51] jfw: this is the so-called "script" of bitcoin, basically like pushing buttons on a calculator and seeing if it comes up true or false to decide whether the transaction is valid.
[20:51] jfw: the "buttons" however include stack operations and signature verification rather than just arithmetic.
[20:53] jfw: but it evaluates left-to-right, after concatenating the "signature" script in the spending input with the "pubkey" script in the output being spent. So the complete script will look like:
[20:53] jfw: ...signatures... [serialized script] OP_HASH160 [20-byte-hash-value] OP_EQUAL
[20:53] jfw: the [] there mean an implicit PUSH of a byte string.
[20:55] jfw: so when you get to the OP_HASH160, first the sigs and serialized (quoted) script have been pushed onto the stack. OP_HASH160 pops the first thing off the top, i.e. the quoted script, and hashes it.
[20:55] jfw: pushing the result back onto the stack.
[20:56] jfw: then the 20-byte (160-bit) target hash is pushed, and OP_EQUAL compares the top two things on the stack.
[20:56] jfw: if they're equal, the script has returned true. no checking of signatures has been done.
[20:59] jfw: the bip16 fork was that the core workings of the script machinery were twisted such that it will then additionally look inside that serialized script for further conditions (I haven't studied exactly how).
[21:20] jfw: dorion: so from the technical perspective, it's an ugly and totally pointless hack. the stated purpose at the time was to push multisig harder by lubing it up to make it fit easier into existing software and/or human protocols. then there's the political angle - might want to check the early threads leading to the TRB project though that could be a long dig.
[21:22] dorion: jfw, thanks for laying it out. yeah, I had primarily focused on the political angle so far, but wanted to round it out with a better understanding of the technical.
[21:23] jfw: I'm recalling something about 0.5.3 being the red line in the sand, unless I'm mixing my deserts.
[21:37] dorion: right, that was the furthest back they found they could go without breaking compatibility at the time (2014).
[21:38] jfw: did you find much from the time of the p2sh business itself (2012)?
[21:40] jfw: http://trilema.com/2012/the-politics-of-bitcoin/ perhaps
[21:57] jfw: (connection being that it was the Obsequious Party aligned institutions that were eager adopters of any and all forks)
[22:40] jfw: dorion: what do you think of the approach of using physical bullion as an intermediate hop in conversion of btc to/from fiat notes?
[22:41] dorion: ask in sell the btc for gold and then sell the gold for cash ?
[22:42] dorion: s/ask in/as in/
[22:43] jfw: like for example, you order gold bars in the mail, paid in btc; there's no "money transmission" involved since neither side of the transaction is money, it would seem to me. Or even viewing btc as money, it's a purchase of a physical product just like jewelry or whatever.
[22:43] jfw: then you just need to find a local bullion dealer.
[22:44] jfw: obviously it'd be better to have friends with piles of bank notes as well as their very own bitcoin nodes with sufficient balance to trade with - but these seem quite rare at least around here where people are a bit too comfortable using conbase et al.
[22:45] dorion: alright, what are the mark ups you're looking at ? I've heard anecdotally there's severe shortages of physical bullion.
[22:46] jfw: presumably a premium on the buy side there would wash out on the sell side?
[22:46] dorion: jfw, what about contacting all those atm operators in s. fla ? best canditates for raising cash would be those who operate machines that only accept cash and send btc.
[22:47] jfw: psh, addressing my root problem instead of the question I asked :P
[22:50] dorion: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-Oct-2021/#2961 -- well, do the calculations and then you'll know. it might not wash out. e.g. apmex will charge you a premium when you buy bullion. coin shop might only buy back bullion at discount. maybe it's still worth it if you're that desperate for the paper, but have to do the calculations.
[22:50] sourcerer: 2021-10-21 22:46:22 (#jwrd) jfw: presumably a premium on the buy side there would wash out on the sell side?
[22:51] jfw: at this stage I'm not that concerned about the margins, within reason, just exploring whether it's a viable approach at all.
[23:03] dorion: I hear you, I'd still start with looking for the atm operators who have cash that they need to turn into btc since their machines are only one way. don't know what percentage of the machines this represents, but it has the dual advantage of cutting out the extra person and making the relationship with local btc people rather than using a pm website operated from afar.
[23:03] dorion: granted, some of these machines are probably owned from afar, but they have to have people on the ground.
[23:04] jfw: yup. I don't recall spotting any BTMs so far but then I haven't sought them out.
[23:10] dorion: https://coinatmradar.com/city/473/bitcoin-atm-fort/lauderdale -- this reports dozen, for instance.
[23:16] jfw: supposedly 700 though the usual endless clicking required to get the list or details.
[23:20] jfw: perhaps worth doing an actual data liberation on it since everyone seems to point to the same site.
[23:21] jfw: one downside that stands out is btm operators are more likely to have signed whatever papers.
[23:29] jfw: there's still the MP prescription of going door to door around the nicer real estate armed with gift baskets and calling cards. seems mad time consuming.
[23:30] dorion: making relationships takes time, yeah.
[23:35] jfw: especially if you're bad at figuring out who's worth that time in advance.
[23:51] jfw: identifying the losers, or at least greater or lesser degrees of loserness which might be all you can ask for these days.
Day changed to 2021-10-23
[05:31] jfw: A particularly mind-boggling example from the trenches of the fractal insanity that is CMake: the CheckIncludeFiles directive doesn't honor the CMAKE_PREFIX_PATH or even CMAKE_INCLUDE_PATH
[05:31] jfw: variables, i.e. supposedly the normal & proper ways of telling it ...where to find include files. No, apparently it has a separate CMAKE_REQUIRED_INCLUDES variable for that, which you'd never find in looking for docs or even raw listings of the available knobs.
[05:34] jfw: ...and that would perhaps be because it doesn't work either.
[05:38] jfw: but why should I complain, after all the whole point of the thing is to be a multifaceted misdirection layer.
[05:53] jfw: but aaaanyway - MySQL 5.6 is now up and running on Gales, with datadir initialization nicely automated, and the mysql shell no longer segfaulting now that it's linked against the proper system readline library rather than its broken copy-n-pasted 'libedit' (snoracle tried to pull that switcheroo to escape GPL implications, but turns out a pretty weak effort - they didn't salt the earth)
[05:57] jfw: there is still a server segfault at startup when myisam_use_mmap is enabled - this was the most significant find from working the test suite, but it had got too hard to trace from amid the intricacies of that test environment, should be straightforward gdb'ing now.
[05:59] jfw: as far as older branches, 5.5 didn't seem to be of much interest as it was already fully CMake infected, and otherwise there didn't seem to be much categorical difference between the two, just a long list of tweaks & optimizations and such.
[06:09] jfw: fulltext indexing for innodb tables was new in 5.6 which is possibly of interest.
Day changed to 2021-10-24
[06:00] jfw: An' the mmaptronics bug is squashed too. It was a faulty CMake probe that broke down in the specific case of 64bit musl with _GNU_SOURCE mode disabled.
[06:04] jfw: that last part was what made me special enough to be the only one to hit this; perhaps I stepped on a rake, but having it enabled had caused a different fault and there was no clearly correct choice - a damned if you do & damned if you don't situation, so I went the route of disabling it to stick as much as possible to the "standards" path, esp. since mysql supports other non-GNU platforms fine.
[06:07] jfw: (the different fault: strerror_r, a particularly sore example where GNU and POSIX have mutually incompatible ideas of the same function, and glibc naturally provides both depending on the ifdef cocktail.)
[06:09] jfw: (no sufficient authority around to demand that everybody drive on the right already ffs.)
[16:55] jfw: https://bugs.mysql.com/bug.php?id=96027 - short and sweet summary of why 5.6 is the last true mysql; to quote for the record:
[16:55] jfw: "The cmake option DISABLE_SHARED was originally implemented to enable building of only static libraries. It has not been maintained since MySQL 5.6
[16:55] jfw: "With the current plethora of plugins and components, and dynamic linking of SSL and protobuf, the option no longer makes any sense. Remove it."
[16:56] jfw: GoogSQL.
Day changed to 2021-10-31
[05:15] jfw: http://fixpoint.welshcomputing.com/2021/muzzling-mysql-into-gales-shape-part-1-groundwork/
[17:38] jfw: among the wtfs still in the trb jalopy, the MIN_TX_FEE business whereby no matter what you set via settxfee, it applies a minimum of .0005 under some conditions - now well above the market rate
[17:44] jfw: and fancy that, the whole "blockchain congestion" thing disappeared once the fiat spam economy lost its purchasing power in btc.