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
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've
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, just until the
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
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
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,
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.
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 :)
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
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
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,
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
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
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,
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
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
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 and
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
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
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
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 just
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
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
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?
On Thu, Jun 18, 2015 at 4:54 AM, odinn odinn.cyberguerri...@riseup.net wrote:
Recently I saw the following video:
https://www.youtube.com/watch?v=8JmvkyQyD8wt=47m58s
For those loosely following the technical issues from outside development
circles, but who may be pressed into a voting/adoption
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
26 matches
Mail list logo
