Day changed to 2021-11-01
[00:37] dorion: http://dorion-mode.com/2021/11/the-bitcoin-address-as-a-sign-of-intelligence/
[14:14] dorion: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-Oct-2021/#2996 -- I managed to get a txn confirmed pretty quick with a 1000 sat fee the other day.
[14:14] sourcerer: 2021-10-31 17:44:49 (#jwrd) jfw: and fancy that, the whole "blockchain congestion" thing disappeared once the fiat spam economy lost its purchasing power in btc.
[14:17] dorion: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-Oct-2021/#2986 -- sweet.
[14:17] sourcerer: 2021-10-24 06:00:44 (#jwrd) 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.
[14:17] dorion: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-Oct-2021/#2990 -- good find.
[14:17] sourcerer: 2021-10-24 16:55:06 (#jwrd) 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:
Day changed to 2021-11-02
[00:14] jfw: dorion: to capture & expand on this morning's chat re how to fix MIN_TX_FEE / MIN_RELAY_TX_FEE :
[00:15] jfw: 1. some sort of anti-dust measure should obviously stay, because machine resources aren't free
[00:19] jfw: 2. current code fails to differentiate the operator's own transactions from any others coming in. Rather, it tries to in case of the builtin wallet but can't for "sendrawtransaction" as used by GBW - and that situation actually sits on good philosophical ground.
[00:20] jfw: i.e. the identity & motives of the operator are none of its business.
[00:22] jfw: thus there should be *one* threshold; and since market conditions will vary, it needs to be a user accessible knob.
[00:23] jfw: conceivably it could be some dynamic thing, though I suspect that would lead to more confusion than good. A dynamic *suggestion* of what fee the operator might want to use, based on the weather, would make sense though.
[00:24] jfw: saving the need to visit shitty websites to do the same thing.
[00:25] jfw: 3. the working of the threshold can be the simple & obvious way: direct comparison with the transaction fee.
[00:26] jfw: eg there's no reason to care that "this transaction is over .01 so therefore it's important enough to be a special case" - if it's so all fired important, let it pay.
[00:29] jfw: possibly it should be fee per byte, or some other metric, rather than absolute.
[00:31] jfw: as a 999kB transaction paying 10k satoshi may not fit the image of 'dust' as the stuff floating in the air, but more like the kind of filth that comes out from between the fins of the CPU heatsink on its 5-year cleaning.
[00:34] jfw: one such metric coming to mind is 'sigops' i.e. signature verifications because that's the most computationally intensive part. then again, there's the noted O(n^2) recomputation of transaction hash for each input signature that led to limits on tx size early on for DoS reasons - perhaps that could be properly weighed.
[00:36] jfw: however I suspect a simple solution eg per byte is the way to go for now rather than do nothing while waiting to come up with a definitive one, if such is even possible.
[00:42] jfw: actually, I recall an old idea I had - and surely not just me - for a dynamic way: you specify a mempool (or rather 'unconfirmed tx hopper' - no reason it needs to live in RAM only except satoshi's special cases for everything)
[00:42] jfw: once full, it evicts transactions cheapest first.
[00:43] jfw: completely solves the unpredictable RAM usage, theoretically at least.
[00:43] jfw: *specify a mempool size limit.
[00:51] jfw: a refinement of the current de facto behavior: the limit is your free space and once hit it evicts *all* transactions by process death.
[01:02] jfw: 4. as far as the legacy builtin wallet goes, it needn't have anything to do with fee thresholds and should simply do as it's told via -paytxfee / settxfee.
[01:05] jfw: the interface for these runtime tunable variables could be straightened out too. -paytxfee and settxfee refer to the same thing, just one's a cli or config file option while the other's an rpc command
[01:06] jfw: so let it be a variable called 'paytxfee' as far as the user's concerned, and the rpc would be 'set paytxfee <amount>'
[01:14] jfw: 'settxfee' preserved for compatibility. then the new one we're adding could be -minrelaytxfee and 'set minrelaytxfee <amount>'
[01:16] jfw: before long we'd be surpassing prb in usability rather than catching up, what a concept!
[16:15] dorion: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-Nov-2021/#3007 -- right.
[16:15] sourcerer: 2021-11-02 00:20:45 (#jwrd) jfw: i.e. the identity & motives of the operator are none of its business.
[16:17] dorion: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-Nov-2021/#3009 -- you mean operator has a way to query directly where the fee market is and then can manually set the threshold ? that sounds like it strikes a good balance.
[16:17] sourcerer: 2021-11-02 00:23:35 (#jwrd) jfw: conceivably it could be some dynamic thing, though I suspect that would lead to more confusion than good. A dynamic *suggestion* of what fee the operator might want to use, based on the weather, would make sense though.
[16:20] dorion: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-Nov-2021/#3012 -- yeah, that makes sense to me, no magic numbers.
[16:20] sourcerer: 2021-11-02 00:26:42 (#jwrd) jfw: eg there's no reason to care that "this transaction is over .01 so therefore it's important enough to be a special case" - if it's so all fired important, let it pay.
[16:26] dorion: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-Nov-2021/#3016 -- word.
[16:26] sourcerer: 2021-11-02 00:36:14 (#jwrd) jfw: however I suspect a simple solution eg per byte is the way to go for now rather than do nothing while waiting to come up with a definitive one, if such is even possible.
[16:29] dorion: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-Nov-2021/#3017 -- hmm, that's interesting. instead of mempool, you make it a swappool.
[16:29] sourcerer: 2021-11-02 00:42:21 (#jwrd) jfw: actually, I recall an old idea I had - and surely not just me - for a dynamic way: you specify a mempool (or rather 'unconfirmed tx hopper' - no reason it needs to live in RAM only except satoshi's special cases for everything)
[16:33] dorion: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-Nov-2021/#3022 -- makes sense.
[16:33] sourcerer: 2021-11-02 01:02:28 (#jwrd) jfw: 4. as far as the legacy builtin wallet goes, it needn't have anything to do with fee thresholds and should simply do as it's told via -paytxfee / settxfee.
[16:34] dorion: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-Nov-2021/#3023 -- pretty crazy.
[16:34] sourcerer: 2021-11-02 01:05:07 (#jwrd) jfw: the interface for these runtime tunable variables could be straightened out too. -paytxfee and settxfee refer to the same thing, just one's a cli or config file option while the other's an rpc command
[16:35] dorion: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-Nov-2021/#3024 -- sounds good.
[16:35] sourcerer: 2021-11-02 01:06:21 (#jwrd) jfw: so let it be a variable called 'paytxfee' as far as the user's concerned, and the rpc would be 'set paytxfee <amount>'
[16:39] dorion: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-Nov-2021/#3025 -- sounds good. to broadcast a recent txn with a fee at current market rates, I had to adjust MIN_RELAY_TX_FEE and recompile...
[16:39] sourcerer: 2021-11-02 01:14:59 (#jwrd) jfw: 'settxfee' preserved for compatibility. then the new one we're adding could be -minrelaytxfee and 'set minrelaytxfee <amount>'
[16:39] dorion: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-Nov-2021/#3026 -- imaginate.
[16:39] sourcerer: 2021-11-02 01:16:53 (#jwrd) jfw: before long we'd be surpassing prb in usability rather than catching up, what a concept!
[18:28] jfw: I expect the low hanging fruits there would be unifying the two minimum fees, making it tunable and adding that "set" rpc.
[18:36] jfw: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-Nov-2021/#3029 - I guess there's two things in there - figuring out what to use for the relay threshold and for one's own transaction fees. Mempool stats especially in combination with a less fragile mempool would serve both needs pretty well I think.
[18:36] sourcerer: 2021-11-02 16:17:48 (#jwrd) dorion: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-Nov-2021/#3009 -- you mean operator has a way to query directly where the fee market is and then can manually set the threshold ? that sounds like it strikes a good balance.
[18:38] jfw: but with the approach of setting a mempool size limit and evicting lowest-value first, a relay threshold becomes unnecessary afaics.
[18:41] jfw: but as the first doesn't interfere with the second, the next lowest hanging fruit would be those mempool stats.
Day changed to 2021-11-06
[05:29] jfw: http://fixpoint.welshcomputing.com/2021/mysql-in-gales-2-bundles-of-joy/
Day changed to 2021-11-07
[01:24] jfw: in tidbits of seemingly good news from the outside, GCC finally finished a long and bloody subversion to git conversion, meaning my archives no longer need be burdened with 45GB of svn data that I can't even use because I haven't maintained a working svn client in that system. The packed git repo is a featherlight 1.1G by comparison and at least appears to go back to 1988.
[01:26] jfw: I'll probably hang onto the svn data in cold storage though because you never know.
[08:42] jfw: http://fixpoint.welshcomputing.com/2021/mysql-in-gales-3-debug-rebug/
[08:43] jfw: seems writing is now harder on my sleep patterns than coding even.
Day changed to 2021-11-09
[21:26] jfw: something I can't deal with right now but want to set down: it comes up again that I can't use "pre" tags in my blog comments which strikes me as broken; digging back up the comment tag whitelisting in mp-wp brought up $allowedtags in "kses.php", but now I'm confounded by http://fixpoint.welshcomputing.com/codeview/tree/mp-wp/mp-wp_genesis/mp-wp/wp-comments-post.php#L42 which seems to be some
[21:26] jfw: other kind of ad-hoc filter and the "kses" business doesn't even apply unless current_user_can('unfiltered_html'), whatever that means (apparently not actually "unfiltered")
Day changed to 2021-11-10
[13:46] dorion: http://fixpoint.welshcomputing.com/2021/muzzling-mysql-into-gales-shape-part-1-groundwork/#comment-1401 -- jfw, relatedly, I wonder why strike is not an accepted html tag in comments.
[16:47] jfw: at least it seems to be 'enumerating goodness' rather than badness, but doesn't look like anyone's taken a systematic look at what tags are actually safe.
[22:00] jfw: from $fiat_institution, "The U.S. Postal Service began changing first-class mail delivery time frames in October. This change may result in mailed statements, new or replacement cards and payments you mail taking longer to arrive." This is amusing because the pantsuit press was talking about all sorts of delays *last* year and blaming Trump's guy.
[22:30] dorion: betchya they didn't buy oil futures or any other inflartion hedge with all those phreedom stamps proceeds.
[22:34] jfw: and why should they after all; constitutionally granted monopoly, captive market & too big to fail.
[22:46] dorion: don't forget that inflation is a good thing too, makes people consume and consumption is the engine of the economy too.
[23:24] jfw: also quite true, for mycobacteria
Day changed to 2021-11-13
[15:55] jfw: http://fixpoint.welshcomputing.com/2021/a-tetrad-of-tuneups-for-bitcoind/
Day changed to 2021-11-23
[14:26] dorion: jfw, I'm looking for the discussion on the potential risk of paying too high a mining fee that came up in the wallet development, but no luck finding it yet. no rush, but please link me if you know where it was discussed.
[16:18] jfw: dorion: iirc it was in #o and #t, let me see.
[16:23] jfw: the culmination was around http://trilema.com/2020/forum-logs-for-12-mar-2020/#2576618
[16:34] dorion: jfw, that's mention of it, yup, thanks. though I thought you had reasoned this yourself and in more detail prior.
[16:40] jfw: dorion: http://ossasepia.com/2020/04/21/ossasepia-logs-for-08-Mar-2020/#1020343
[16:50] dorion: exactly, thanks.
[16:53] jfw: I see diana_coman told me essentially the same thing MP did later - offline wallet has no business 'verifying its inputs', because it can't, by definition. yet it still sucks that bad input can indeed lead to 'loses all your money' and not just losing the transacted amount, when that possibility could have been avoided by less lazy accounting in the tx validation logic.
Day changed to 2021-11-24
[04:18] jfw: A quick search for "wait, why did linux patch releases on kernel.org (as in the patch-XYZ.gz files) quietly stop being signed as of 4.9.116 ?!" yields no ready answers but does turn up a lengthy PGP guide almost entirely full of bad recommendations
[04:26] jfw: I'll admit I was contemplating "see if it's fixed in the latest version" as an approach to a troublesome hardware-related error I'm chasing, but am pretty well put off the idea.
[04:27] jfw: more like "see if it's unbroken in the last 2.6 release" now; that'll probably take some config massaging though.
Day changed to 2021-11-30
[05:18] jfw: http://fixpoint.welshcomputing.com/2021/healing-my-old-ossasepia-log-links/
[05:32] jfw: also realized there's no reason for a blog like mine with variable width layout - or quite possibly any blog at all - not to have pre { white-space: pre-wrap; } in its global stylesheet.
[05:33] jfw: previously I'd been inlining it into the <blockquote><pre> for each code snippet, perhaps based on some notion that "maybe the browser default is that way for a reason".
[05:37] jfw: now for instance my plain-txt outline doesn't run off the screen edge.
[00:37] dorion: http://dorion-mode.com/2021/11/the-bitcoin-address-as-a-sign-of-intelligence/
[14:14] dorion: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-Oct-2021/#2996 -- I managed to get a txn confirmed pretty quick with a 1000 sat fee the other day.
[14:14] sourcerer: 2021-10-31 17:44:49 (#jwrd) jfw: and fancy that, the whole "blockchain congestion" thing disappeared once the fiat spam economy lost its purchasing power in btc.
[14:17] dorion: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-Oct-2021/#2986 -- sweet.
[14:17] sourcerer: 2021-10-24 06:00:44 (#jwrd) 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.
[14:17] dorion: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-Oct-2021/#2990 -- good find.
[14:17] sourcerer: 2021-10-24 16:55:06 (#jwrd) 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:
Day changed to 2021-11-02
[00:14] jfw: dorion: to capture & expand on this morning's chat re how to fix MIN_TX_FEE / MIN_RELAY_TX_FEE :
[00:15] jfw: 1. some sort of anti-dust measure should obviously stay, because machine resources aren't free
[00:19] jfw: 2. current code fails to differentiate the operator's own transactions from any others coming in. Rather, it tries to in case of the builtin wallet but can't for "sendrawtransaction" as used by GBW - and that situation actually sits on good philosophical ground.
[00:20] jfw: i.e. the identity & motives of the operator are none of its business.
[00:22] jfw: thus there should be *one* threshold; and since market conditions will vary, it needs to be a user accessible knob.
[00:23] jfw: conceivably it could be some dynamic thing, though I suspect that would lead to more confusion than good. A dynamic *suggestion* of what fee the operator might want to use, based on the weather, would make sense though.
[00:24] jfw: saving the need to visit shitty websites to do the same thing.
[00:25] jfw: 3. the working of the threshold can be the simple & obvious way: direct comparison with the transaction fee.
[00:26] jfw: eg there's no reason to care that "this transaction is over .01 so therefore it's important enough to be a special case" - if it's so all fired important, let it pay.
[00:29] jfw: possibly it should be fee per byte, or some other metric, rather than absolute.
[00:31] jfw: as a 999kB transaction paying 10k satoshi may not fit the image of 'dust' as the stuff floating in the air, but more like the kind of filth that comes out from between the fins of the CPU heatsink on its 5-year cleaning.
[00:34] jfw: one such metric coming to mind is 'sigops' i.e. signature verifications because that's the most computationally intensive part. then again, there's the noted O(n^2) recomputation of transaction hash for each input signature that led to limits on tx size early on for DoS reasons - perhaps that could be properly weighed.
[00:36] jfw: however I suspect a simple solution eg per byte is the way to go for now rather than do nothing while waiting to come up with a definitive one, if such is even possible.
[00:42] jfw: actually, I recall an old idea I had - and surely not just me - for a dynamic way: you specify a mempool (or rather 'unconfirmed tx hopper' - no reason it needs to live in RAM only except satoshi's special cases for everything)
[00:42] jfw: once full, it evicts transactions cheapest first.
[00:43] jfw: completely solves the unpredictable RAM usage, theoretically at least.
[00:43] jfw: *specify a mempool size limit.
[00:51] jfw: a refinement of the current de facto behavior: the limit is your free space and once hit it evicts *all* transactions by process death.
[01:02] jfw: 4. as far as the legacy builtin wallet goes, it needn't have anything to do with fee thresholds and should simply do as it's told via -paytxfee / settxfee.
[01:05] jfw: the interface for these runtime tunable variables could be straightened out too. -paytxfee and settxfee refer to the same thing, just one's a cli or config file option while the other's an rpc command
[01:06] jfw: so let it be a variable called 'paytxfee' as far as the user's concerned, and the rpc would be 'set paytxfee <amount>'
[01:14] jfw: 'settxfee' preserved for compatibility. then the new one we're adding could be -minrelaytxfee and 'set minrelaytxfee <amount>'
[01:16] jfw: before long we'd be surpassing prb in usability rather than catching up, what a concept!
[16:15] dorion: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-Nov-2021/#3007 -- right.
[16:15] sourcerer: 2021-11-02 00:20:45 (#jwrd) jfw: i.e. the identity & motives of the operator are none of its business.
[16:17] dorion: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-Nov-2021/#3009 -- you mean operator has a way to query directly where the fee market is and then can manually set the threshold ? that sounds like it strikes a good balance.
[16:17] sourcerer: 2021-11-02 00:23:35 (#jwrd) jfw: conceivably it could be some dynamic thing, though I suspect that would lead to more confusion than good. A dynamic *suggestion* of what fee the operator might want to use, based on the weather, would make sense though.
[16:20] dorion: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-Nov-2021/#3012 -- yeah, that makes sense to me, no magic numbers.
[16:20] sourcerer: 2021-11-02 00:26:42 (#jwrd) jfw: eg there's no reason to care that "this transaction is over .01 so therefore it's important enough to be a special case" - if it's so all fired important, let it pay.
[16:26] dorion: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-Nov-2021/#3016 -- word.
[16:26] sourcerer: 2021-11-02 00:36:14 (#jwrd) jfw: however I suspect a simple solution eg per byte is the way to go for now rather than do nothing while waiting to come up with a definitive one, if such is even possible.
[16:29] dorion: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-Nov-2021/#3017 -- hmm, that's interesting. instead of mempool, you make it a swappool.
[16:29] sourcerer: 2021-11-02 00:42:21 (#jwrd) jfw: actually, I recall an old idea I had - and surely not just me - for a dynamic way: you specify a mempool (or rather 'unconfirmed tx hopper' - no reason it needs to live in RAM only except satoshi's special cases for everything)
[16:33] dorion: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-Nov-2021/#3022 -- makes sense.
[16:33] sourcerer: 2021-11-02 01:02:28 (#jwrd) jfw: 4. as far as the legacy builtin wallet goes, it needn't have anything to do with fee thresholds and should simply do as it's told via -paytxfee / settxfee.
[16:34] dorion: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-Nov-2021/#3023 -- pretty crazy.
[16:34] sourcerer: 2021-11-02 01:05:07 (#jwrd) jfw: the interface for these runtime tunable variables could be straightened out too. -paytxfee and settxfee refer to the same thing, just one's a cli or config file option while the other's an rpc command
[16:35] dorion: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-Nov-2021/#3024 -- sounds good.
[16:35] sourcerer: 2021-11-02 01:06:21 (#jwrd) jfw: so let it be a variable called 'paytxfee' as far as the user's concerned, and the rpc would be 'set paytxfee <amount>'
[16:39] dorion: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-Nov-2021/#3025 -- sounds good. to broadcast a recent txn with a fee at current market rates, I had to adjust MIN_RELAY_TX_FEE and recompile...
[16:39] sourcerer: 2021-11-02 01:14:59 (#jwrd) jfw: 'settxfee' preserved for compatibility. then the new one we're adding could be -minrelaytxfee and 'set minrelaytxfee <amount>'
[16:39] dorion: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-Nov-2021/#3026 -- imaginate.
[16:39] sourcerer: 2021-11-02 01:16:53 (#jwrd) jfw: before long we'd be surpassing prb in usability rather than catching up, what a concept!
[18:28] jfw: I expect the low hanging fruits there would be unifying the two minimum fees, making it tunable and adding that "set" rpc.
[18:36] jfw: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-Nov-2021/#3029 - I guess there's two things in there - figuring out what to use for the relay threshold and for one's own transaction fees. Mempool stats especially in combination with a less fragile mempool would serve both needs pretty well I think.
[18:36] sourcerer: 2021-11-02 16:17:48 (#jwrd) dorion: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-Nov-2021/#3009 -- you mean operator has a way to query directly where the fee market is and then can manually set the threshold ? that sounds like it strikes a good balance.
[18:38] jfw: but with the approach of setting a mempool size limit and evicting lowest-value first, a relay threshold becomes unnecessary afaics.
[18:41] jfw: but as the first doesn't interfere with the second, the next lowest hanging fruit would be those mempool stats.
Day changed to 2021-11-06
[05:29] jfw: http://fixpoint.welshcomputing.com/2021/mysql-in-gales-2-bundles-of-joy/
Day changed to 2021-11-07
[01:24] jfw: in tidbits of seemingly good news from the outside, GCC finally finished a long and bloody subversion to git conversion, meaning my archives no longer need be burdened with 45GB of svn data that I can't even use because I haven't maintained a working svn client in that system. The packed git repo is a featherlight 1.1G by comparison and at least appears to go back to 1988.
[01:26] jfw: I'll probably hang onto the svn data in cold storage though because you never know.
[08:42] jfw: http://fixpoint.welshcomputing.com/2021/mysql-in-gales-3-debug-rebug/
[08:43] jfw: seems writing is now harder on my sleep patterns than coding even.
Day changed to 2021-11-09
[21:26] jfw: something I can't deal with right now but want to set down: it comes up again that I can't use "pre" tags in my blog comments which strikes me as broken; digging back up the comment tag whitelisting in mp-wp brought up $allowedtags in "kses.php", but now I'm confounded by http://fixpoint.welshcomputing.com/codeview/tree/mp-wp/mp-wp_genesis/mp-wp/wp-comments-post.php#L42 which seems to be some
[21:26] jfw: other kind of ad-hoc filter and the "kses" business doesn't even apply unless current_user_can('unfiltered_html'), whatever that means (apparently not actually "unfiltered")
Day changed to 2021-11-10
[13:46] dorion: http://fixpoint.welshcomputing.com/2021/muzzling-mysql-into-gales-shape-part-1-groundwork/#comment-1401 -- jfw, relatedly, I wonder why strike is not an accepted html tag in comments.
[16:47] jfw: at least it seems to be 'enumerating goodness' rather than badness, but doesn't look like anyone's taken a systematic look at what tags are actually safe.
[22:00] jfw: from $fiat_institution, "The U.S. Postal Service began changing first-class mail delivery time frames in October. This change may result in mailed statements, new or replacement cards and payments you mail taking longer to arrive." This is amusing because the pantsuit press was talking about all sorts of delays *last* year and blaming Trump's guy.
[22:30] dorion: betchya they didn't buy oil futures or any other inflartion hedge with all those phreedom stamps proceeds.
[22:34] jfw: and why should they after all; constitutionally granted monopoly, captive market & too big to fail.
[22:46] dorion: don't forget that inflation is a good thing too, makes people consume and consumption is the engine of the economy too.
[23:24] jfw: also quite true, for mycobacteria
Day changed to 2021-11-13
[15:55] jfw: http://fixpoint.welshcomputing.com/2021/a-tetrad-of-tuneups-for-bitcoind/
Day changed to 2021-11-23
[14:26] dorion: jfw, I'm looking for the discussion on the potential risk of paying too high a mining fee that came up in the wallet development, but no luck finding it yet. no rush, but please link me if you know where it was discussed.
[16:18] jfw: dorion: iirc it was in #o and #t, let me see.
[16:23] jfw: the culmination was around http://trilema.com/2020/forum-logs-for-12-mar-2020/#2576618
[16:34] dorion: jfw, that's mention of it, yup, thanks. though I thought you had reasoned this yourself and in more detail prior.
[16:40] jfw: dorion: http://ossasepia.com/2020/04/21/ossasepia-logs-for-08-Mar-2020/#1020343
[16:50] dorion: exactly, thanks.
[16:53] jfw: I see diana_coman told me essentially the same thing MP did later - offline wallet has no business 'verifying its inputs', because it can't, by definition. yet it still sucks that bad input can indeed lead to 'loses all your money' and not just losing the transacted amount, when that possibility could have been avoided by less lazy accounting in the tx validation logic.
Day changed to 2021-11-24
[04:18] jfw: A quick search for "wait, why did linux patch releases on kernel.org (as in the patch-XYZ.gz files) quietly stop being signed as of 4.9.116 ?!" yields no ready answers but does turn up a lengthy PGP guide almost entirely full of bad recommendations
[04:26] jfw: I'll admit I was contemplating "see if it's fixed in the latest version" as an approach to a troublesome hardware-related error I'm chasing, but am pretty well put off the idea.
[04:27] jfw: more like "see if it's unbroken in the last 2.6 release" now; that'll probably take some config massaging though.
Day changed to 2021-11-30
[05:18] jfw: http://fixpoint.welshcomputing.com/2021/healing-my-old-ossasepia-log-links/
[05:32] jfw: also realized there's no reason for a blog like mine with variable width layout - or quite possibly any blog at all - not to have pre { white-space: pre-wrap; } in its global stylesheet.
[05:33] jfw: previously I'd been inlining it into the <blockquote><pre> for each code snippet, perhaps based on some notion that "maybe the browser default is that way for a reason".
[05:37] jfw: now for instance my plain-txt outline doesn't run off the screen edge.