[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 type position (miners,
users, investors)... is there a parallel presentation of the concepts and
arguments from the other side (both, or the various, sides) that they
can refer to?
Someplace where they are collated and presented? A wiki perhaps?
Are these even valid or necessary questions?

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 raw archives (past and future) downloadable
in mbox format and updated daily, with full unobfuscated headers
for threading and replying, with signatures and attachments.
Commonly for newcomers wishing to seed their own MUA's and archives,
mirrors, search, and so on.

One such breakage of archives by mailman defaults was discussed and
corrected here:
https://cpunks.org/pipermail/cypherpunks/

You also need to get rid of the tag in the subject, it wastes
valuable space and mail filters work just the same without it.

Please no forums (see suck above). Unless they have bidirectional
realtime message copying between list and forum. Or at least make
available exports of their message database.

Further, when will the crypto P2P communities develop and use
distributed messaging systems... bitmessage, blockchain, etc as
rough examples... to avoid old centralized issues. At some point you
have to start eating your own dog food and make people run the
clients and come to you instead. Disruptive tech is the new good.

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[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?

--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

--
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire 
the most talented Cisco Certified professionals. Visit the 
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

--
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire 
the most talented Cisco Certified professionals. Visit the 
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 transactions and queries.

I'm guessing this will all be fixed in a couple weeks and that ASIC and FPGA
miners will have their softcode updated, as will the pure softminers (GPU).

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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.

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.

--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 agnostic system
daemon to do the block processing separately from user wallet ops.
So I would suggest until then it remain split up somewhere under
.bitcoin rather than in /var or anywhere else.

--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 size of them, that would be an
issue. Enterprise systems with UPS, good disk, etc assume writes are
committed upon return, eliminating need for software apps to do sync. So
I need to figure out how to turn that off?

Is sync on for everything, or just the wallet (where it could be argued as ok)?

 For those who run a large
 database on ZFS, I believe it is advised to put ZFS's intent log on a
 separate SSD-backed device, to get fast synchronous writes.

Guessing bitcoin's writes are small? So a RAM dev intent would be cheaper
and faster than SSD for that.

 on switching the bitcoin block verifier to use a different style database
 layout (ultraprune), which is smaller, faster, and will support pruning.

I'll try to search that. If it's anything like delete old blocks/tx/coins that
have both been validated in the past and fully spent in the future since we
no longer need to validate further back beyond them [1], that would be
interesting.

[1] Unless you're a historian or some usage other than casual transactions.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 are working in these areas. Once I'm on new
hardware and playing around I, also, may find some discoveries.

I have no doubt that 'common' is windows seven on core2duo
without ecc and no crypto or hashing for the disk :)

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 any other mentions of crypto
in this thread so I'm not sure how well new hardware would perform.
Going shopping I guess.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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, 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=65000


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

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 to include the block of the Phatom project as well:
 https://code.google.com/p/phantom/
 fd00:2522:3493::/48

 Perhaps some argument to add blocks to the IsRoutable check is in
 order?  Then people who use overlay networks that are actually
 routable but which use otherwise private space can just add the
 relevant blocks.

/ [1] Well bitcoin wouldn't know to offload traffic to any of those
/ blocks, or a specific host on them, if you had them set up locally
/ via *Cat or Phantom... for bitcoin use. It would probably end up
/ half useful similar to the above FYI. But that would just affect
/ bitcoin, not whatever else you were running on them.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[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, invalid/nonwallet txid's,
which were already in there as legit ones in the old logs.

Second run in plain mode.
New wallet ver logged.
Rescanned  the last 20k blocks or so,
which might have been the marker last time the old wallet was used.

Third and later runs... duplicates the second.

Never did say 'upgrading wallet' as it sometimes does.

Running detach=1 always.

Why scan the last 20k every time? Shouldn't have to if
whole chain was scanned. And certainly no more than
once if not.

Also...
Dumping the run params (bitcoin.conf, cmdline) to the log would be good.

And not automatically truncate the log when big but just append or roll it.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[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 unneeded more than 1x. I cannot yet explain.

So I expect to avoid all by send the balance from old
wallets to new wallet soon instead.

The old wallets were ver 10500.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 :)

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 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 :)

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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, etc

Last, resolve whether or not bitcoin.org is independant.
It cannot be if it does not accept all lib/client under it's umbrella
or has a lib/client project of it's own. You will hit up against this,
just saying.


 Bitcoin-Qt
 This application is a peer-to-peer client that builds the backbone of the 
 Bitcoin network.

No, they all do this and build it, subject to their feature set.

 It is suited for enthusiasts, merchants, miners, developers

No, all implementations are suited for whoever, subject to their feature set.

  and people who want to help support the project.

Which project, the given client or the bitcoin meme.

 People who run Bitcoin-Qt are first class network citizens and have the 
 highest levels of security, privacy and stability.

Right, anyone who doesn't is unwashed rebel scum, running default
installs of xp, on systems with bad ram, who post their home address,
transaction logs, and pink bits on facebook.

 leave it running in the background so other computers can connect to yours.

Again, a feature set / usage model thing.


 MultiBit
 fast and easy to use, even for people with no technical knowledge.

Hey, we're fast, easy and for noobs, me too.

 It has a...

But at least the backing specifics to that claim are stated.


 Armory
 Armory was partly funded by a community donation drive which raised over 
 $4000.

Yeah, every lib/client will have a donation thing on their own site,
and the developers own real world wallet.

 Electrum
 the privacy level is lower than for other clients.

Not sure of this claim. It's all in the usage. Run your own remote,
use anonymizers, etc. Right?

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[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
https://github.com/bitcoin/bitcoin.git

The current development tree. As such, HEAD/master/origin
may at times not be exactly reliable/usable.

#2
https://git.gitorious.org/bitcoin/bitcoind.git

A copy of some chunk of #1 that then died
off around v0.4.0. Purposed similar to #3?

#3
https://git.gitorious.org/bitcoin/bitcoind-stable.git

Another copy of #1. For development along stable
branches and making release cuts from same?
Releases get pulled back to #1 for keeping?
The HEAD/master/origin should be reliable.

Why is this functoin not a part of #1?

Thanks.

--
Virtualization  Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[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 behind at least one database/log.nnn file.
Shouldn't it roll and delete it on exit like it does the other state files?
Particularly after a simple we're able to do nothing but local
operations invocation
like: bitcoind -proxy=127.0.0.1:9050 -keypool=0 -connect=127.0.0.1
-nodnsseed -noirc

Similarly, the .lock file is never deleted.
Shouldn't it be upon exit?

Vacuuming addr, blkindex, and wallet with db_dump | db_load will save
significant space. I do not yet know how to view or validate blk0001.dat.

When left with junk, I've been removing everything except:
addr.dat - node addresses
bitcoin.conf - config
blk0001.dat - blocks
blkindex.dat - index to blocks
wallet.dat - wallet

--
Virtualization  Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 last checkpoint), but people fear it runs contrary to
 the distributed approach of Bitcoin.

Git repos are backed by strong hashes. Each commit could be a single
block dump, perhaps into a file hierarchy. Trusted entities, pools, etc
could sign at a checkpoint/height. Blockchain tools
would need made that can take the blk* and export single blocks and
process/export up to a certain block and quit. Everyone would do a
comparison and sign a commit hash. Everyone else git pulls. Having
the block toolset is a key prequisite to any sort of distribution. They don't
exist now :( Maybe the two bitcoin compatible library projects out there
will implement them :) Torrents are also strongly hashed and could be
signed as well.

Making the blockchain tools would be the most important thing to start.

 BTW: On such an old computer you should probably use one of the thin
 clients.

If that means not validating the chain, then it's as above. I'm not sure if it's
right to not care about the history if only making new transactions with a new
key post install time and then only validating new transactions as they come
in. Will have a look.

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[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 chain?
rsync? db_dump  git  db_load?
There is also 50% or more compression available in the index
and chain.
Of some known future issues... raw transaction rate, the eventual pay
(or extort?, depending on how megapools pan out) to process mining
environment, and scaling the client count itself... this one appears to
be already present.

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 seen the block chain get fully done in 10-20
 mins and on others it slows down to the point where it will never
 catch up.. but not in a way that's related to the age of the computer
 or anything. You might want to experiment if you want to track this
 down.. try building your own libs

Rather than use dated/modified packages, I compiled current versions
of all component sources manually.

 and compare different operating
 systems, on the same hardware to get a more 'true' comparison maybe.

True. Used them all before, happy with BSD for now. Just knowing
what the general setup is on those zippy systems should suffice.
ie: blindly fishing for such a zippy system to compare through various
install tests doesn't sound too appealing. It's different than benchmarking.

Datapoint: The system below is not zippy.

 I think everyone is vaguely aware of the problem but it has not
 been tracked down and eliminated. I don't think the problem is
 within bitcoin itself but in how truthfully the database file is
 actually written to disk.

Am I correct in guessing that, given a certain height, the data
in blkindex and blk0001 should be the same across instances?

# file blk*
blk0001.dat: data
blkindex.dat:Berkeley DB (Btree, version 9, native byte-order)

Pursuant to comparison, what is the format of blk0001.dat?

 If it really gets flushed to disk every
 block like bitcoin wants it to be, then there is no way that you
 could get more than 50-60 blocks per second through it (due to
 rotational latency), but on some operating systems and versions/options
 it seems to end up caching the writes and flies through it at
 thousands of blocks per second. The problem is similar to what's
 mentioned here: http://www.sqlite.org/faq.html#q19

I'm not running Linux with asynchronous data and metadata
turned on by default if that's what you mean :) ZFS, disk crypto,
standard drive write cache. Looking at it, I'm largely buried in
that crypto at 8MB/sec or so.

 Perhaps it's as simple as some default in the db lib.. and it seems
 to default to different things on different version/operating
 systems/filesystems.

Hmm, I compiled everything with the defaults. Will go back and
look at bdb options. I don't think there was anything interesting
there. I'd bet a lot is tied to the fs and cpu.
Single core p4@1.8 512k/2g isn't much up against ZFS+disk crypto.

It seems to take its time and roll up all but the last database file (of
a hundred or more) on receiving sigterm. Is it supposed to roll
and delete the last log too? Can I safely delete everything but
the blk* files? (wallet excepted of course :)

Currently, in KiB...

running:
853716  database
747881  blk0001.dat
290601  blkindex.dat
4361addr.dat
137 __db.005
137 __db.004
137 __db.003
137 __db.002
41  __db.006
25  __db.001

sigterm:
750569  blk0001.dat
291497  blkindex.dat
8465database/log.000nnn
4361addr.dat

database/log.000133: Berkeley DB (Log, version 16, native byte-order)

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development