On Thu, Jun 18, 2015 at 4:54 AM, odinn wrote:
> Recently I saw the following video:
> https://www.youtube.com/watch?v=8JmvkyQyD8w&t=47m58s
For those loosely following the technical issues from outside development
circles, but who may be pressed into a voting/adoption type position (miners,
users,
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
Should there not be a 0.8.2 branch laid down at 09e437b (v0.8.2)
in which the like of release build stoppers or critfixes such as d315eb0
are included... for those tracking that level of defect without
wishing to track all the growing post release slush in HEAD?
---
> Bitcoins relative lack of privacy creates a problem with tainted coins
> risking becoming unspendable, or spendable only with some users, or at a
> discount. So while the policy coded says all coins are equally acceptable,
> the information exists so people can unilaterally reject them, dependin
> 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 everywh
> 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 cha
>> 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
>> Bitcoin version 0.8.0 is safe to use for everything EXCEPT creating blocks.
>>
>> So: safe for everybody except solo miners / pool operators.
>
> And even solo miners / pool operators can use it if connected to the network
> only through a 0.7 node.
I'll go ahead and use 0.8.x since it will be
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 broadcaste
> 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 test
Linux typically uses the FHS, which various distros often bastardize:
http://www.linuxfoundation.org/collaborate/workgroups/lsb/fhs
BSD typically uses the traditional hierarchy, for which admins
often add /home and /opt:
http://svnweb.freebsd.org/base/head/share/man/man7/hier.7?revision=HEAD&vi
> I like this idea, although I would say the blockchain should go in
> /var/lib/bitcoin
> by default, right? I'm just a longtime LInux guy, not a formal sysadmin,
> though.
Further, bitcoin doesn't allow easy separation of the files without
detachdb (off by default), nor does it supply a user ag
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 comman
> I'd love to know precisely what Bitcoin is doing thats making your
> machine so unhappy... but your configuration is uncommon for bitcoin
> nodes in many distinct ways so it's not clear where to start.
That's why I posted the details of the machine so interested people
could duplicate it if they
> You are however using a filesystem (ZFS)
I'm aware of the memory and i386 issues, and going shopping.
> The bdb backend Bitcoin uses
> does many I/O operations, and writes them synchronously to disk, killing
> whatever caching your filesystem provides.
Sync... yes, depending on the rate/sec an
> shopping.
Good thing I can still spend, even with an incomplete blockchain :)
> but why do you also need to encrypt 2+ GB of public record?
1) I'm not seeing an option to split the wallet, debug log and other
privates pathwise from the blockchain.
2) Because encrypt everything is reasonable st
> 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 be
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 an
> 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 dis
> 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.
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
Forward past automoderation...
> Reading https://github.com/bitcoin/bitcoin/blob/master/doc/Tor.txt
> Is bitcoin software going to incorporate tor binaries within the
> application standard application and automatically create a Tor Hidden
> Service on behalf of end-user?
>
> Are there any direc
GregM, wasn't sure how to answer your question, and as to
conflicts [1]. I think I grasped it in my reply to something on
tor-talk, which is on its way here pending moderation due to bcc.
I put that part below. The FYI referred to seednodes as
they exist on Tor / I2P today.
> You are going to want
> 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
I had previously commented on this.
My references to wallet ver were really to nFileVersion.
And I've since been able to make that, and the
real walletversion become current.
However it is still doing this every invocation...
Rescanning last 14xxx blocks (from block 170xxx)...
Which seems unneede
I think there may be an ideal order of ops bug around rescan,
wallet upgrades/import and last block markers.
I dropped an old wallet in a current blockchain.
First ran - in rescan mode.
It said old walletver.
Then rescanned whole chain.
AddToWallet some blockhash, blocks out of range, invalid/non
> This is the work model I use:
Will try all these things out this weekend. Thanks.
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and h
> Workflow is ...
Thanks very much, I think that helps me/others. I did not realize
there were release windows in master and thought it more as the
typical full time dev slush. That also explains the presence of all
the release tags in github repo. And even, in a divergent way, the
presence of git
> be sure to have good backups that never touched the new code...
> We have at various times had bugs in master that would corrupt
> wallets
Sorry, that's to be expected, I shouldn't have asked.
> It would be very helpful if anyone offering bitcoin services would
> setup parallel toy versions of
>> https://github.com/bitcoin/bitcoin
>> https://git.gitorious.org/bitcoin/bitcoind-stable
>
> The latter is Luke's backports of security and stability fixes to
> otherwise unmaintained old versions.
Ah ok, coming from cvs/svn, it's a bit different to find things.
There's something to be said for
> 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 fo
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
When bitcoind exits cleanly, it does not seem safe for the blockchain
to clean up the following hierarchy with rm -r ?
database/
db.log
.lock
debug.log
addr.dat
wallet.dat
And what about adding to the above list the following files when
bitcoind crashes:
__db.*
Is there an option to make bitcoi
While happily processing these:
received block ...
SetBestChain: new best=... height=... work=...
ProcessBlock: ACCEPTED
bitcoind very often refuses to answer rpc queries such as getinfo/stop,
or signals such as kill/ctrl-c. It even registers:
ThreadRPCServer method=getinfo/stop
in the debug lo
> "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 :)
-
> 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.
--
> 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,
> 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 fe
> Some time ago i started a googlegroup mailing list, bitcoin-discussion.
> It's been pretty low-volume... but it's something. :)
> http://groups.google.com/group/bitcoin-discussion
Unfortunately it appears to be just as dead as the one
on sourceforge.
> or we could try to revive the bitcoin-list
I'm a little unclear on which repo is which and
for what intended uses. And other than #1,
their descriptions on the hubs are minimal.
I'm not the best with git, but getting there.
Are these the right way to think of them?
And that #1 and #3 are what most builders
and hacks should be tracking?
#1
> I am trying to post on the bitcoin forums (bitcointalk.org)
I wish there were a bitcoin-user mailing list??? But the one on
sourceforge is dead. Forums are too full of avatars, smilies,
sigblocks and dead mass to be of much use. Not to mention
when they vanish, any content dies with it instead o
I've been playing with the tools in db 4.8.30, and bitcoin stable...
My blockchain is up to date. Bitcoin is not running.
# strings database/*
This will at times yield the addresses in your wallet.
So it's not exactly in compliance with 'only your wallet file matters'.
Bitcoin always leaves behi
>> Have any groups published proposals for distributing
>> a weekly precomputed bootstrap chain?
>> rsync? db_dump > git > db_load?
>> There is also 50% or more compression available in the index
>> and chain.
> I have proposed packaging part of the block chain (doesn't even have to be
> weekly, j
> I never did track down this exact issue but it's an artificial
> slowdown.. meaning compression and whatever else wouldn't help much.
I meant for anyone who wanted to distribute the dataset as a project.
> It has something to do with the database file locking and flushing..
> on some systems I'
A freshly deployed client on an old p4 has been idly crunching away
at building and verifying the initial chain for about a week now. It
should be done in a day or two. This seems rather untenable for
new users. Have any groups published proposals for distributing
a weekly precomputed bootstrap cha
> 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 see
> 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-censors
This is counted from the current git master on bsd.
The first two are of note and should probably be looked at.
A little more work after those and it might be possible to
use -Wall by default as addressing even some of these
would remove tons of lines from the output :)
1 net.cpp:141: warning:
48 matches
Mail list logo
