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 15: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 11:43:10

- reply

📅 Original date posted:2013-04-03
📝 Original message:> Users will have available multisig addresses which require
> transactions to be signed off by a wallet HSM. (E.g. a keyfob
Hardware is a good thing. But only if you do the crypto in the
hardware and trust the hardware and its attack models ;) For
instance, the fingerprint readers you see everywhere... many
of them just present the raw fingerprint scan to the host (and
host software), instead of hashing the fingerprint internally and
using that as primitive in crypto exchanges with the host. They
cheaped out and/or didn't think. So oops, there went both your
security (host replay) and your personal privacy (biometrics),
outside of your control. All with no protection against physical
fingerprint lifting.
> This doesn't remove the need to improve repository integrity. ... but
> repository integrity is a general problem that is applicable to many
> things (after all, what does it matter if you can't compromise Bitcoin
> if you can compromise boost, openssl, or gcc?)
Yes, that case would matter zero to the end product. However
having a strong repo permits better auditing of the BTC codebase.
That's a good thing, and eliminates the need to talk chicken and
egg.
> It's probably best
> that Bitcoin specalists stay focused on Bitcoin security measures, and
> other people interested in repository security come and help out
> improving it. An obvious area of improvement might be oddity
> detection and alerting: It's weird that I can rewrite history on
> github, so long as I do it quickly, without anyone noticing.
If no one is verifying the repo, sure, even entire repos could be
swapped out for seemingly identical ones.
Many repos do not have any strong internal verification structures
at all, and they run on filesystems that accept bitrot.
Take a look at some OS's... OpenBSD and FreeBSD, supposedly
the more secure ones out there... both use legacy repos on FFS.
Seems rather ironic in the lol department.
Thankfully some people out there are finally getting a clue on these
issues, making and learning the tools, converting and migrating
things, working on top down signed build and distribution chain, etc...
so maybe in ten years the opensource world will be much farther
ahead. Or at least have a strong audit trail.

2023-06-07 11:43:00

- reply

📅 Original date posted:2013-04-03
📝 Original message:>> gpg signing commits, like the Linux kernel
> Though, honestly, when I ACK that means I read the code, which is more
> important than the author really. github seems fine for that still,
> though I do wonder if there is a race possible,
>
> * just before I click "pull", sneak rebases the branch to something evil
You might want to look at http://www.monotone.ca/, it does a good job
of integrating crypto and review primitives into the workflow.
It also has some reliable network distribution models (netsync) that work
well over things like Tor, in case a new developer (or old Satoshi) doesn't
wish to be in the public light.
http://www.monotone.ca/monotone.html
Once you have the crypto, it always boils down to human risk factors,
rogue, password, cracks, etc which are harder.

2023-06-07 11: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 11: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 10:30:56

- reply

📅 Original date posted:2012-09-13
📝 Original message:I mentioned this somewhere a while ago.
It is enough of a sysadmin problem to warrant a feature ticket.
Open one on github for it.
XDGBDS is not canon. So don't hardcode said paths.
All paths should be specifiable in bitcoin the config file, whose
location should itself be specifiable on the command line.

2023-06-07 10: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 10:19:21

- reply

📅 Original date posted:2012-06-26
📝 Original message:> Additionally, such addresses are exchanged and relayed via the P2P network.
> To do so, we reused the fd87:d87e:eb43::/48 IPv6 range. Each address in this
> 80-bit range is mapped to an onion address, and treated as belonging to a
> separate network. This network range is the same as used by the OnionCat
> application (though we do not use OnionCat in any way), and is part of the
> RFC4193 Unique Local IPv6 range, which is normally not globally routable.
>
> Other clients that wish to implement similar functionality, can use this
> test case: 5wyqrzbvrdsumnok.onion == FD87:D87E:EB43:edb1:8e4:3588:e546:35ca.
> The conversion is simply decoding the base32 onion address, and storing the
> resulting 80 bits of data as low-order bits of an IPv6 address, prefixed by
> fd87:d87e:eb43:. As this range is not routable, there should be no
> compatibility problems: any unaware IPv6-capable code will immediately fail
> when trying to connect.
You are going to want to include the block of the Phatom project as well:
https://code.google.com/p/phantom/
fd00:2522:3493::/48
And the one for 'garlicat' for I2P, which might be more complex due
to I2P's addressing:
fd60:db4d:ddb5::/48
Note that while these blocks are not expected to be routable, that
people may in fact have interfaces, routing tables and packet filters
on their machines configured with up to all three of those networks
for the purposes therein.