<unnamed>

Public Key

npub1rjzq78n467z9ugxvfq6cyxdk8n3rtn8h92yjnrtene4a52g847rsgvs23t

Profile Code

nprofile1qqspepq0re6a0pz7yrxysdvzrxmrec34enmj4zff34ueu6769yr6lpcpzpmhxue69uhkummnw3ezuamfdejsz9rhwden5te0wfjkccte9ejxzmt4wvhxjmcpp4mhxue69uhkummn9ekx7mqvtnvlw

Publishing to

nostr.wine

relay.damus.io

nos.lol

Last Notes

2023-06-07 17:41:02 CEST

- reply

📅 Original date posted:2015-06-27
📝 Original message:On Sun, Jun 21, 2015 at 9:14 PM, Frank Flores <frankf44 at gmail.com> wrote:
> If you're going to go through the trouble of signing your public emails ...
... then you should also demand that the official archives of your
favorite lists preserve them and their verifiability in the supposedly
canonical reference "mbox" format that they distribute.
On Wed, Jun 24, 2015 at 7:47 AM, Wladimir J. van der Laan
<laanwj at gmail.com> wrote:
> Subject: [bitcoin-dev] New GPG signing key for Bitcoin Core binary releases
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009045.html
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June.txt.gz
As you can clearly see, both the HTML archives and the "mbox"
archives have corrupted this message, it will not verify. Do not
try to say this case is trivial, the problem itself is not trivial,
it's gratuitous, and it applies to all matching messages... text,
code, binary inline... that's dangerous.
Do not try to say this corruption prevents spam, it does not.
Spammers simply subscribe to the list and harvest everything
efficiently in realtime... no webcrawling overhead, no stale
addresses. Obfuscation is futile.
This misfeature needs to be disabled.
On Fri, Jun 19, 2015 at 12:57 AM, Warren Togami Jr. <wtogami at gmail.com> wrote:
> archives will be exported
> and imported into the new list server
On Tue, Jun 23, 2015 at 2:45 PM, Andy Schroder <info at andyschroder.com> wrote:
> I'm not sure if anyone has submitted a request for gmane
On Sun, Jun 21, 2015 at 5:35 PM, s7r <s7r at sky-ip.org> wrote:
> Do we have all the archives imported? I run several full nodes and
> mirrors for open source projects, if you think it's useful, I can
> provide a mirror for the mail list archives.
Yes... these other mirrors, archives, analysis, journalism, and
interfaces are useful. However, as it is now, there are no useful
authoritative sources for them to seed from... they're all corrupt.
And any subscribed realtime sources, though nice, are subject to
downtime, administrative and other unrecoverable gaps. Your mirror
project is a fine idea, you should demand that the pristine historical
sources be made publicly available. Not just for you, but for everyone.
On Wed, Jun 17, 2015, grarpamp wrote:
> ...
As before, the current "mbox" archives are broken and not useful...
a) They corrupt message data, messages are unverifiable, another example...
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009132.html
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June.txt.gz
b) They are missing the minimum set of original headers necessary
for fully replyable, threadable, sortable, searchable, context
preserving and direct use by users MUA's in their local environment:
(Date, From, To, Cc, Subject, Message-ID, In-Reply-To, References)
c) They do not include attachments (patches, signatures, images, crypto,
data) that are absolutely necessary to the context and archives
of all lists. Instead they stupidly throw them away to "web links"
which results not only in uselessness of the so called "mbox"
version, but in many thousands of needless fetches by archive
users and indexers. And hours of wasted work attempting to
postprocess them into usable form.
Valuable content lost from the "mbox" files this June alone:
418 attachment.html
106 attachment.sig
6 attachment.jpe
4 attachment.png
2 attachment.bin
d) There appear to be at least 15 instances of unescaped '^From '
in the "mbox". Regeneration with current mailman may fix. One such
case is here:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-January/004245.html
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-January.txt.gz
Please fix all the above mentioned issues by providing the full raw
archives in regularly updated [gzip/7z] mbox format. The internet
thanks you :)
Example, compare the "Downloadable version"s here:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/
https://cpunks.org/pipermail/cypherpunks/
https://cpunks.org/pipermail/cypherpunks/2015-February/006820.html
On Tue, Jun 23, 2015 at 2:45 PM, Andy Schroder <info at andyschroder.com> wrote:
> Regarding message footers and the subject prefix
Yes, they're also corruptive and space wasting clutter, for and by
the clueless :( Both of them should be turned off.

2023-06-07 17:39:45 CEST

- reply

📅 Original date posted:2015-06-24
📝 Original message:On Tue, Jun 23, 2015 at 4:50 PM, Peter Todd <pete at petertodd.org> wrote:
> In particular, note how this bump is being proposed at a time when
> blockchain space demand is so low that transactions usually cost well
> under a penny each
Recent averages seem to be offering around $0.04...
https://tradeblock.com/blog/bitcoin-network-capacity-analysis-part-2-macro-transaction-trends
With various stress tests indicate needing 10x more...
http://www.reddit.com/r/Bitcoin/search?restrict_sr=on&q=stress+test+fees
> a insignificant amount of money for almost all
> use-cases.
Penny stocks? Voting? Notarizing?
There's a whole ecosystem of non-purchase cases
for which non-profit-mining fees are enabling.

2023-06-07 12:06:17 CEST

- reply

📅 Original date posted:2012-05-02
📝 Original message:> Try "Reply to All"
That puts the sender in 'to' and list in 'cc',
which dupes to the sender and eventually
blows out the to and cc lines as everyone
chimes in and doesn't trim. 'reply to' solves
most of that. assuming the list sw can do it.

2023-06-07 12:06:11 CEST

- reply

📅 Original date posted:2012-05-02
📝 Original message:> While Bitcoin-Qt is by far the best client
This is purely subjective. One's best is another's worst.
> These are both things which are particular
> suitable to clear objective enumeration.
Yes, so for the purposes of compiling a list of clients
and libraries, please just stick to a table of features.
On the subjective part, I'm finding the library+client
implementations to be nice, and indeed the future.
Afaik, there are two major pairs of these so far that
should be listed. Ymmv.
Can someone also please set the reply-to header
for these lists. It's really annoying to hit reply and
not have the list address show up. Thanks :)