<unnamed>

Public Key

npub1rjzq78n467z9ugxvfq6cyxdk8n3rtn8h92yjnrtene4a52g847rsgvs23t

Profile Code

nprofile1qqspepq0re6a0pz7yrxysdvzrxmrec34enmj4zff34ueu6769yr6lpcpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0ds8pc7hp

Publishing to

relay.snort.social

relay.damus.io

nos.lol

Last Notes

2023-06-07 15:41:02 UTC

- 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 15:39:45 UTC

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

- 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:07 UTC

- reply

📅 Original date posted:2013-04-03
📝 Original message:> Eliminate the "if you get a bad bitcoin-qt.exe somehow you're in big
> trouble" risk entirely
This isn't really possible. A trojaned client will spend your coin as
easily as the owner can, passphrases will be logged, windows box will
be owned, secondary remote spendauth sigs into the network chain
break similarly, securely hashcheck the trojaned client from cracked
userspace on a hacked dll/kernel with uefi backdoor and a trojaned
hasher, etc.
It's easier for a few developers to meet in person to init and sig
a new repo than to try fixing the world's userland and users :)
At least that way you get something verifiable back to the root.

2023-06-07 11:43:00 UTC

- 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:31:48 UTC

- 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:25:20 UTC

- reply

📅 Original date posted:2012-07-27
📝 Original message:> I now have an 1.8 ghz p3 celeron (128k cache) which should be
> substantially slower than your machine, running vintage 2.6.20 linux.
> Unfortunately I forgot to turn on timestamp logging so I don't know
> how long it took to sync the chain, but it was less than two days as
> that was the span between when I checked on it. It's staying current
Well, are you running bitcoin on, say, an FS with sha256 integrity
trees for all bits and AES-128-XTS/CBC disk encryption?
If not, we're not comparing the same apples, let alone the same OS.
> Again, I encourage you to investigate your software configuration.
Someone suggested I investigate turning off the above features.
Since I'd find their loss undesirable [1], and there's not much to be
tuned there anyways, I've given up and am investigating what more
GHz and cores will do.
[1] Keeping data both intact and private is a good thing. Does your
checkbook deserve any less?

2023-06-07 10:25:14 UTC

- reply

📅 Original date posted:2012-07-27
📝 Original message:Update: this class of machine just became useless for bitcoin.
When blk0002.dat was created to store more blocks, all forward
progress processing blocks turned into losing ground by 20 or so
a day. Guessing both datfiles were being accessed at once resulting
in disk based overload. I've not seen any other mentions of crypto
in this thread so I'm not sure how well new hardware would perform.
Going shopping I guess.

2023-06-07 10:25:11 UTC

- reply

📅 Original date posted:2012-07-23
📝 Original message:> You're seriously suggesting that I'm using a system
> which is 720x (one month vs one hour) faster than your
> P4 1.8GHz?
Don't know what you're using since you've not stated it.
> I find this doubtful, especially since bitcoin's sync is effectively
> single threaded.
Extra cores help with disk, crypto, net, etc...
> month
I've spent about two weeks crunching about the last month's
worth of new blocks.
> Your results are not expected and are not believed to be
> representative.
The config is reproducible, and not believed to be uncommon.
> try to isolate it
Mostly disk and crypto.
Shall everyone instead run in bitrot and no-privacy mode?
What do we do when we've got 10k trans a day coming in?
50k? 100k, 1M? When the chain gets 1M, 50M, 500M, 1B long?
Forget my swamped box, these numbers are coming to others.
> try to sync from a local node into tmpfs
I'd bet some people using 'tmpfs' probably have it unknowingly
[fall]backed to swap instead of core.
Bitcoin already takes up 3GiB of disk, how many have that much
free RAM? How many have 30GiB, 300GiB?
> If you're building against BDB later than the recommended 4.8
> be aware that there have been performance regressions with later
> versions
Yes, I left out that bit of platform so here are the remaining
bits... db4830, boost149, vm.kmem_size=650000000
I'm not bashing anything or anybody, just detailing a stock config
that is underwater. Anybody wishing to verify can get the hardware
from their junk pile and the software from freebsd.org. I'll certainly
be looking at both it and different setups too. If anyone's using
say Linux/BSD, BTRFS/ZFS, crypto, on i386/amd64, they could
chime in with their times too.
Disk is the cheapest, easiest thing for Joe to get. Think about
indexing and checkpointing into said disk. I don't know what
bitcoin's doing, but if it's verifying every transaction back to
the root, that would seem a bit ridiculous.
Joe probably won't be happy buying TiB's for bitcoind, so after that's
filled (assuming there's CPU to do it), the trust model has to change.
These scales are coming...

2023-06-07 10:24:44 UTC

- 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 10:24:32 UTC

- 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 UTC

- 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.

2023-06-07 10:16:33 UTC

- reply

📅 Original date posted:2012-06-17
📝 Original message:> It isn't inside the ifdef in bitcoin git master.
Oh, hmm, well then, what is the difference or usage
between these two repositories in regards to the project?
Which one are the formal releases tagged (tbz's cut) in?
Which one has the branches with the commits that will
make it into the next formal release? ie: tracking along
0.5.x, 0.6.x, HEAD/master (to be branched for 0.7.x).
https://github.com/bitcoin/bitcoin
https://git.gitorious.org/bitcoin/bitcoind-stable
I seem to be seeing more tags in the former, and
more maintained branches in the latter?

2023-06-07 10:16:27 UTC

- reply

📅 Original date posted:2012-06-17
📝 Original message:Well, detachdb doesn't appear in the -\? help
because it's stuffed under pnp, which is not set
in my build. please fix for people, tx :)
#ifdef USE_UPNP
#if USE_UPNP
" -upnp \t " + _("Use Universal Plug and
Play to map the listening port (default: 1)") + "\n" +
#else
" -upnp \t " + _("Use Universal Plug and
Play to map the listening port (default: 0)") + "\n" +
#endif
" -detachdb \t " + _("Detach block and address
databases. Increases shutdown time (default: 0)") + "\n" +
#endif

2023-06-07 10:06:17 UTC

- 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 10:06:11 UTC

- 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 03:03:19 UTC

- 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.