[Bitcoin-development] Video summarizations of blocksize issues?

2015-06-18 Thread grarpamp
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

Re: [Bitcoin-development] Proposal: Move Bitcoin Dev List to a Neutral Competent Entity

2015-06-16 Thread grarpamp
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

[Bitcoin-development] 0.8.2 branch

2013-05-29 Thread grarpamp
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?

Re: [Bitcoin-development] bitcoin pull requests

2013-04-03 Thread grarpamp
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

Re: [Bitcoin-development] bitcoin pull requests

2013-04-03 Thread grarpamp
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

Re: [Bitcoin-development] Ok to use 0.8.x?

2013-03-16 Thread grarpamp
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

Re: [Bitcoin-development] 0.8.0rc1 status

2013-02-08 Thread grarpamp
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.

Re: [Bitcoin-development] separate out blockchain db and wallet to two dirs?

2012-09-13 Thread grarpamp
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

Re: [Bitcoin-development] separate out blockchain db and wallet to two dirs?

2012-09-13 Thread grarpamp
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

Re: [Bitcoin-development] Scalability issues

2012-07-27 Thread grarpamp
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

Re: [Bitcoin-development] Scalability issues

2012-07-27 Thread grarpamp
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

Re: [Bitcoin-development] Scalability issues

2012-07-26 Thread grarpamp
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

Re: [Bitcoin-development] Scalability issues

2012-07-26 Thread grarpamp
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

Re: [Bitcoin-development] Scalability issues

2012-07-23 Thread grarpamp
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,

Re: [Bitcoin-development] [tor-talk] Tor hidden service support

2012-06-27 Thread grarpamp
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

Re: [Bitcoin-development] Tor hidden service support

2012-06-26 Thread grarpamp
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

[Bitcoin-development] Wallet related bug?

2012-06-22 Thread grarpamp
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,

[Bitcoin-development] Wallet related bug?

2012-06-22 Thread grarpamp
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

[Bitcoin-development] 0.6.x - detachdb in wrong place

2012-06-17 Thread grarpamp
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

Re: [Bitcoin-development] 0.6.x - detachdb in wrong place

2012-06-17 Thread grarpamp
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

Re: [Bitcoin-development] new bitcoin.org clients page

2012-05-03 Thread grarpamp
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 :)

Re: [Bitcoin-development] new bitcoin.org clients page

2012-05-02 Thread grarpamp
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

Re: [Bitcoin-development] new bitcoin.org clients page

2012-05-02 Thread grarpamp
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,

Re: [Bitcoin-development] new bitcoin.org clients page

2012-05-02 Thread grarpamp
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.

[Bitcoin-development] Git repo choices

2012-02-19 Thread grarpamp
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

[Bitcoin-development] Some state/data file info

2012-02-09 Thread grarpamp
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

Re: [Bitcoin-development] Scaling at the end user level

2012-02-08 Thread grarpamp
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

[Bitcoin-development] Scaling at the end user level

2012-02-07 Thread grarpamp
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

Re: [Bitcoin-development] Scaling at the end user level

2012-02-07 Thread grarpamp
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

Re: [Bitcoin-development] Announcement: libcoin

2012-02-01 Thread grarpamp
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