grarpamp [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2012-01-30 to 2015-07-24
💬 Posted a total of 54 messages
📚 Participated in the following categories: Bitcoin-development, coredump backtrace, tor-talk, bitcoin-dev, drifted from: txrate, forking, etc
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 17:41:02

- 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

- 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 17:37:52

- reply

📅 Original date posted:2015-06-16
📝 Original message:Please no GoogleGroups. Stick with mailman or some other open
source thing you can move around from place to place as needed.
Also, online third party archives die, their web interfaces suck
ass, they're bloated, don't export, aren't offline capable or
authoritative, etc.
You need to make the raw archives (past and future) downloadable
in mbox format and updated daily, with full unobfuscated headers
for threading and replying, with signatures and attachments.
Commonly for newcomers wishing to seed their own MUA's and archives,
mirrors, search, and so on.
One such breakage of archives by mailman defaults was discussed and
corrected here:
https://cpunks.org/pipermail/cypherpunks/
You also need to get rid of the tag in the subject, it wastes
valuable space and mail filters work just the same without it.
Please no "forums" (see suck above). Unless they have bidirectional
realtime message copying between list and forum. Or at least make
available exports of their message database.
Further, when will the crypto P2P communities develop and use
distributed messaging systems... bitmessage, blockchain, etc as
rough examples... to avoid old centralized issues. At some point you
have to start eating your own dog food and make people run the
clients and come to you instead. Disruptive tech is the new good.

2023-06-07 13:40:04

- reply

📅 Original date posted:2013-03-14
📝 Original message:Assuming a new install and first time connection to the net,
is using 0.8.x [1] safe to use, for all (or select?) purposes,
regarding the current fork issue?
If not, is there a recommended branch, tag, or commit, for
all such (or select?) purposes, until such time as an upgrade
alert is broadcasted?
Thanks.
[1] Regarding possible 0.8.x flavors...
There are only 'branch master' and 'tag v0.8.0' here:
https://github.com/bitcoin/bitcoin
There are no 0.8.x branch or tags here yet:
https://git.gitorious.org/bitcoin/bitcoind-stable

2023-06-07 13:31:48

- reply

📅 Original date posted:2013-02-09
📝 Original message:> Linux builds of 0.8.0rc1 are in good shape; easily gitian-reproduceable.
> Windows builds are varying with every compile, and I think I finally
> The OSX build is in pretty good shape, but needs
> So: I think the path forward is to announce 0.8.0rc1 with the binaries
> we've got, to get more testing.
With this new minor bump, I'd like to encourage the project to perform
a build check on FreeBSD 8.3 (gcc), and 9.1 (should be clang/llvm).
I'll try to get to 8.x but may not be able to in time.

2023-06-07 12:24:44

- reply

📅 Original date posted:2012-07-23
📝 Original message:> Please fix your software stack. Something is wrong
> with your system
Nothing wrong, it's all default install. I documented the platform
for anyone who wants to confirm it.
> A full sync here takes something like an hour.
And what, similarly, is your platform?
It takes 5 seconds... on my Cray.
> I would guess that you are running the blockchain download
> through the tor-proxy
Use of Tor was stated. Tor is fast enough. I can copy the entire
3GiB of the .bitcoin dir in 7 days... off a slow hidden service.
And 0.5 days via exit.
> encrypting your disk (aes stuff) will not help you much either
Encryption is a perfectly reasonable thing to expect users of
bitcoin to be interested in doing. In fact, those not encrypting
their disks should probably rethink that plan.
> encrypting a the storage of a public blockchain seems to me a bit odd ?
Well, without detachdb, it's somehow tied to the wallet, whether
while processing or offline. And the wallet and debug.log are
not relocatable from the data. And encrypting everything is perfectly
reasonable anyways. As is storing your valuable data on filesystems
that verify the integrity of their data on disk, such as ZFS/BTRFS.
These days, crypto, Tor, and ZFS are common and non-arguments.
> I get a full blockchain from scratch in 45 minutes on my laptop
Again, timings with no CPU/OS/disk specs are useless infos.

2023-06-07 12:24:32

- reply

📅 Original date posted:2012-07-22
📝 Original message:Given a testbed: Pentium 4 1.8GHz single core, 2GB ram, FreeBSD 8,
disk is geli aes-128 + zfs sha-256, bitcoin 0.6.3, Tor proxy,
An estimate is made that by the end of the year bitcoin will
completely overrun the capabilities of this reasonable class of
machines.
It already takes a month to build a new blockchain, let alone keep up
with new incoming blocks.
Yes, it also has workstation duties, yet even if those were removed,
it would probably choke by mid 2013.
It would appear bitcoin has some *serious* scalability hurdles coming
down the road.
Most certainly if the user expects to independantly build, manage, and
trust their own blockchain.

2023-06-07 12:07:14

- reply

📅 Original date posted:2012-05-02
📝 Original message:> it's unclear how best to run this page. It's clear we need one though.
> the right path is probably the middle one - have some descriptions that try to be neutral
Do it in two parts...
- overview, history, architecture model, 'whys'.
- agnostic table of features, platforms, stats, protocols, etc
Last, resolve whether or not bitcoin.org is independant.
It cannot be if it does not accept all lib/client under it's umbrella
or has a lib/client project of it's own. You will hit up against this,
just saying.
> Bitcoin-Qt
> This application is a peer-to-peer client that builds the backbone of the Bitcoin network.
No, they all do this and build it, subject to their feature set.
> It is suited for enthusiasts, merchants, miners, developers
No, all implementations are suited for whoever, subject to their feature set.
> and people who want to help support the project.
Which project, the given client or the bitcoin meme.
> People who run Bitcoin-Qt are first class network citizens and have the highest levels of security, privacy and stability.
Right, anyone who doesn't is unwashed rebel scum, running default
installs of xp, on systems with bad ram, who post their home address,
transaction logs, and pink bits on facebook.
> leave it running in the background so other computers can connect to yours.
Again, a feature set / usage model thing.
> MultiBit
> fast and easy to use, even for people with no technical knowledge.
Hey, we're fast, easy and for noobs, me too.
> It has a...
But at least the backing specifics to that claim are stated.
> Armory
> Armory was partly funded by a community donation drive which raised over $4000.
Yeah, every lib/client will have a donation thing on their own site,
and the developers own real world wallet.
> Electrum
> the privacy level is lower than for other clients.
Not sure of this claim. It's all in the usage. Run your own remote,
use anonymizers, etc. Right?

2023-06-07 12:07:01

- reply

📅 Original date posted:2012-05-03
📝 Original message:> "Reply-To" Munging Considered Harmful
> http://www.unicom.com/pw/reply-to-harmful.html
Ok, ok. but only because this reminds me of the
top-posting and formatting advice page that
I can't seem to find right now.
But I'm not munging what my client decides to
put in to/cc on a g reply either :)

2023-06-07 12:06:17

- 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

- 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 :)

2023-06-07 05:03:19

- reply

📅 Original date posted:2012-02-01
📝 Original message:> However, I think perhaps the bitcoin project should be split into a library, with a prototype client and the actual clients. This library facilitates this.
I'll be trying your implementation soon. And libbitcoin/subvertx too.
Partly because they're also non-interpreted, and partly to what seems
better architected...
To the minimal extent of my understanding... I'd like to see wallet
ops completely separated from background chain ops. ie: have
a chain daemon doing it's thing, updating, verifying, etc. The
generator doing it's thing. And a wallet app that can independently
manage separate wallets in parallel, referencing the live chain files
as needed. It seems a library would allow quality focus on the separate
functions and let apps/ui's use the fn's as desired on top. Right now, it
seems I have to run bitcoind and can only deal with one wallet at a time,
having to stop it, deal with state issues, swap in a new wallet, start
it, and repeat till illness ensues :( And when the chain is being processed
hard by the daemon cpuwise, bitcoin RPC takes minutes to respond, if ever
or errors out. If wallet ops or statistical queries on the chain need it for
integrity or reading, a db checkpoint/lock/logroll could be implemented into
the chain demon processes with a client lib api to trigger it as needed.
Don't know, just saying.
fyi... boost 1.48 and db 4.8.30 work fine with 0.5.2, 0.5.x, and master,
you just need to compile and include it by hand if you want it and
your package manager doesn't have it.

2023-06-07 05:00:43

- reply

📅 Original date posted:2012-01-31
📝 Original message:> I think it's important that we have more mechanisms then just DNS and
> hardcoded seednodes.
> This is important because the mechanisms we have are all pretty
> subject to blocking. Now— before you say it— Bitcoin isn't intended to
> be blocking resistant (combine it with Tor and Tor anti-censorship
> tools)
> Is the fact that users can addnodes / addr.txt enough of an
> alternative to address this?
Perhaps not worry about removing it too much. As above, if blocking
or other issues arise, people will be hosting manual lists and nodes
on hidden sites... Tor/I2P/etc. The nodes are already there.
For that matter, since the nodes are talking once seeded, why not
deploy a DHT and be done. All you'd need is one friendly node and
the list comes in and maintains itself through node expiry rules.
Your node publishes its hello for others to discover, etc.
IRC, DNS, etc would go away in favor of autonomy. It wouldn't
be any more resistant. But if people wanted that, some form of
signatures from the hidden nodes would do... if you trusted them.
Booting and running is easy, trust isn't (ask the Tor/I2P people).