Topic: Can we still advertise the Satoshi Client for noobs? (Read 3858 times)

I was / is still a noob, but I think I understand more of how or what bitcoin is or is not and how it works in a matter of a few days of lurking here, and reading all the wikis.

For me, I got the Satoshi client (version 4 or 5; 2 to 3 months ago) and just patiently waited for the whole blockchain to download over a week. Then I got pywallet and added some private keys I generated using vanitygen and bitaddress because I couldn't spend the money I had collected through the faucet.

I had other ideas regarding scalability but they involved incompatible protocol changes that may not be accepted by other people.

I was going to point to that.  While that body of work probably didn't plant certain seeds of doubt in my mind, it certainly did help to germinate them.

Most 'Bitcoin is fine' arguments are winnable on this forum with two words: "Moore's Law."  I feel that there is some nuance to be contemplated.  Two of the more important ones:

 - Just because new technology is developed does not mean that it is necessarily universally available at low cost or without significant hurdles.

 - Bitcoin growth rates could easily dwarf technology developments even though both may be exponential.  (And if they don't, it means that Bitcoin remains a fringe toy for us geeks in my opinion.)

https://en.bitcoin.it/wiki/Scalability

I've been assuming hardware/bandwidth is getting cheaper at a greater rate than the blockchain is growing. So it should become relatively easier to run a full client on normal hardware.

Have I assumed wrong? Has anyone checked the math?

Thanks Pieter Wuille for the clarification.

I'm not really willing to expose my IP like that. But anyway, I don't think it's a bandwidth issue.

The blocks are downloaded into a memory buffer by the network handler thread. This buffer is 10 megabytes, so it can certainly contain several blocks simultaneously.

The initial verification is very fast.

The bulk of the verification is done while updating the index: we need to a) find previous outputs b) check they are not yet marked spent c) evaluate scripts and signatures d) mark previous outputs spent e) mark new outputs spendable. This has to be done transaction per transaction (mostly), as each transaction can legally spend the outputs of the previous ones. Certainly optimizations are possible, but it's not as easy as splitting verification and db updates into two threads.

By the way, Matt Corallo has a branch that does split the initial verification and connecting/indexing steps into separate threads, and this does indeed seem to improve throughput a bit.

I'm not too sure about that, but wouldn't that kind of issue be helped by forwarding port 8333 (at router level)?

Wow... that's the time my laptop takes to update like, a single week of blocks. And I'm using 6.2.

I can't explain it, but I suspect that the whole process is done in a synchronous way. Like:

• Download a block (bandwidth usage)
• Verify its validity (CPU intensive, plus indexed queries)
• Insert the block in the DB - indexation (IO intensive, and probably O(log) on the index size, or perhaps even O(n), don't know)
• Proceed to next block

If that's the case, there's probably room for some optimization by rendering this process asynchronous and making bulk inserts in the DB. A thread would go downloading blocks, in a torrent fashion. Another thread would go behind it verifying the blocks. And finally a third thread would insert the verified data in bulks on the database. Validated blocks should be kept in a memory index while they are not yet inserted, so that the verifying thread can query them too.

Well, this is all speculation of mine... can someone confirm how is the block download done?

Indeed, no need to install Python when using the windows binary (An up-to-date compact version
of Python 2.7 is included, and is totally noob-friendly)  

There are window builds (exe's which I don't think require Python?)... but I think MultiBit might be a better choice because it still requires a blockchain (although much more compact).

> type "Bitcoin" into google
> bitcoin.org is first result
> Click first download link

This, I think, is reasonable speculation of how the "noob" will install his/her client, assuming they've only heard the word "bitcoin". Of course personal recommendations may be different, I guess that's the point of this thread.

On my PC the official client simply does not work with my specs (Both windows and Linux). The latest client.

1.6ghz cpu, 512 MB ram, slow HD, windows or linux = Block chain downloading is so slow it would never finish. (Think: weeks). And computer is unusable for other tasks while client is running.

Macbook with 2ghz cpu, 4 GB ram = completes in a few hours. [note, this is on the same internet connection as the other one, so it's not slow internet that's the issue here]

Average "noob" will probably not have the latest hardware either. Everyone I know that's a normal person (i.e. not a gamer or techie) has a several years old second hand or refurbished PC. (generally, the cast off from a gamer or techie)

So no, do not advertise the official client to them!

Personally, I use Electrum, but figuring out how to run a python app is also beyond any noob. And also average noob will not backup their wallet or any of their computer data.

So e-wallets is the best answer for usability! Though whether the e-wallets are reliable and secure enough, I don't know.

Yes I seem to be experiencing the same thing, as are many others, so I would like to know if it's normal.

I don't recommend eWallets for noobs because they aren't really as safe as using a desktop client.

But wouldn't it be better to recommend MultiBit or Electrum for noobs rather than the Satoshi Client?

It seems to me one doesn't really need to acquire the whole blockchain unless they have a real reason.

It's simply becoming too large too quickly imo. Let the heavy duty servers deal with it.

Not everyone needs to have the Satoshi Client and a full blockchain stored locally.

So here are the full results.

http://static.paccrat.org/img/btc-ts.png

The slowdown between #100k and #120k is quite dramatic. I'm not (yet!) familiar enough with bitcoin internals to know if this is expected behaviour. Can anyone explain it?

Thanks,

Toby.

I'm just testing this now, with the 64-bit Linux bitcoind client. To begin with, I get around 150 blocks per second, which would be consistent with reports from other users of around 20 - 30m to get the entire chain. But around block #120000 it starts to slow down dramatically. I'm down to about 3 blocks per second around #150000. Is this normal?

As far as I can see, bitcoind is not starved of CPU, memory, or disk I/O, so it must be the network that's slowing it down. This is a not particularly great ADSL line.

Toby.

I'm sorry, you did the positive statement, you bare the burden of proof.

Since you admit it's just speculation I'd like to let you know I do not share the same view as you and will ignore yours.

Vale, lo mismo das con la solucion antes que yo, mantenos informados tio, y gracias por el cumplido.

(Ok, you will probably find the solution before I do, keep us posted dude, and thanks for the compliment.)

Can show some evidence to support this statement?