Very few normal people would wait days for the blockchain to download.

[Transisto]

Waiting clueless for the block count rise is the most boring thing I ever did.

Seriously can't we have some pop-up saying "transaction may not be accurate until the whole blockchain has been downloaded" ?

,or anything analog to a progress bar so that people don't fall in a coma waiting for their balance to show up.

Also, :

• The HELP button provide no help whatsoever,
  
• The setting/option pane has one page "MAIN" ,,, why have this at all ?
• Seeing   "FILE / EXIT" would puzzle-out any non-geeks. (why file )

I'm quite impressed that the Bitcoin client is still at this "for geek only" stage.

Hope that the default usage of this UI die very soon.

[1714845411]

1714845411

[1714845411]

1714845411

[Andrew Bitcoiner]

Gavin talked about development priorities at the NY conference, you might want to take a look at that.  You may also want to make the changes yourself, the code is open source and I am sure they would appreciate some submissions of UI improvements.

[Transisto]

Gavin talked about development priorities at the NY conference, you might want to take a look at that.  You may also want to make the changes yourself, the code is open source and I am sure they would appreciate some submissions of UI improvements.

Thank you,

http://www.youtube.com/watch?v=0ljx4bbJrYE&feature=player_detailpage#t=1109s

[Gavin Andresen]

The new QT GUI (in git HEAD) has a nifty block-chain-download-progress indicator.

I'd like to pull together a version 0.5 release candidate and start testing it early next week.

Maybe the big feature for version 0.6 can be fast initial download (I'm thinking the best thing to do for brand-new, starting-with-an-empty-wallet installations is to download only block headers, function as a 'lightweight' client, and 'backfill' full blocks until you're caught up with the full chain-- then function as a 'full' client).

[Transisto]

... Maybe the big feature for version 0.6 can be fast initial download (I'm thinking the best thing to do for brand-new, starting-with-an-empty-wallet installations is to download only block headers, function as a 'lightweight' client, and 'backfill' full blocks until you're caught up with the full chain-- then function as a 'full' client).

I just noticed I had a problem and it was taking longer,  

I have a flaky internet connection and it seems like dropped or unresponsive connection are not being retried by the client.
To the point were 56 connection get me a block every 3 seconds.
Restating it made it faster again.

can be quite an issue for people behind NAT.

[AlexWaters]

One of Gavin's recent patches gives a ~30% increase in download time. While it still takes a long time, I think it's manageable for most people.

Additionally, as mentioned - allowing the user to choose a headless version is something I hope will be available soon. There is plenty of innovation that could arise if people can get and start using the client in under 10 minutes.

If you would like to get new features sooner, and don't have a development / C++ background - feel free to contact me to get involved with the testing/QA process.

[etotheipi]

Normal people dont even use the client, they use an online wallet service. The client is for geeks.

I think the future of bitcoin is dependent on making lightweight clients. I am glad to see developement moving that direction.

Lightweight clients will stuff suffer from having to get their initial block scan from somewhere.  Either through a trusted service online, or your computer or device still downloading the entire chain, and throw away the 99.9% that isn't yours.   Although, a lot of this can be avoided by making sure addresses are tagged with a first date and/or block number, so that your client doesn't have to download the entire chain to find its txs.

Btw, my Linux/Ubuntu client was unusable in 0.3.24 because it would take days to update, even if it was just a couple hundred blocks behind.  I just updated to 0.4.0 and now it catches up almost immediately.  I downloaded most of the chain through 0.4.0 and it took less than a day.  Obviously not ideal for the casual user, but it's better than it was before...

[Jan]

Normal people dont even use the client, they use an online wallet service. The client is for geeks.

I think the future of bitcoin is dependent on making lightweight clients. I am glad to see developement moving that direction.

There is one (possibly two) lightweight android clients in the works implemented on top of the BCCAPI. I am very confident that this is the secure way for Bitcoin to his the mass-market. We are talking about clients that are installed and fully functional within minutes, without no risk of the server side going renegade and stealing coins.

[jim618]

As the bitcoinj blockchain from the genesis block is currently less than 16MB, for MultiBit I am just shipping it in the installer.

Gets people started much quicker. The same logic would apply to other bitcoinj clients I think.

[qikaifu]

It seems that Gavin has brought us really good news here. Thanks!

[kano]

I saw a link last week of downloads of the full block-chain up to whatever recent block.
Would that also be a good idea to have available in some reasonably secure place to help people get the full block-chain up and running much faster?
Of course there is the minor issue of the reliability of the source, however, as long as the client isn't included with it, there should be no security issue since the proper client will require it to be valid anyway.

[ThomasV]

Normal people dont even use the client, they use an online wallet service. The client is for geeks.

I think the future of bitcoin is dependent on making lightweight clients. I am glad to see developement moving that direction.

There is one (possibly two) lightweight android clients in the works implemented on top of the BCCAPI. I am very confident that this is the secure way for Bitcoin to his the mass-market. We are talking about clients that are installed and fully functional within minutes, without no risk of the server side going renegade and stealing coins.

I agree, this is the way to go.
ideally, the server-side of this BCCAPI should be performed by any node of the bitcoin network.

[Jan]

Normal people dont even use the client, they use an online wallet service. The client is for geeks.

I think the future of bitcoin is dependent on making lightweight clients. I am glad to see developement moving that direction.

There is one (possibly two) lightweight android clients in the works implemented on top of the BCCAPI. I am very confident that this is the secure way for Bitcoin to his the mass-market. We are talking about clients that are installed and fully functional within minutes, without no risk of the server side going renegade and stealing coins.

I agree, this is the way to go.
ideally, the server-side of this BCCAPI should be performed by any node of the bitcoin network.

This is an interesting idea! Basically this means that the client side can connect to any node in the network and let it be its proxy for creating valid transactions that the client can sign. The worst thing an evil node could do is to misinform the client about its current balance and generate transactions that are not valid/accepted by the network. Both of which can be alliveated by connecting to another node or connecting to several nodes simultaneously and compare the results.

The flipside is that the client side will have to reveal the set of bitcoin addresses belonging to its wallet. For a simple mass-market client anonymity may not be an issue, and it might even just have one key-pair.

[ThomasV]

This is an interesting idea! Basically this means that the client side can connect to any node in the network and let it be its proxy for creating valid transactions that the client can sign. The worst thing an evil node could do is to misinform the client about its current balance and generate transactions that are not valid/accepted by the network. Both of which can be alliveated by connecting to another node or connecting to several nodes simultaneously and compare the results.

The flipside is that the client side will have to reveal the set of bitcoin addresses belonging to its wallet. For a simple mass-market client anonymity may not be an issue, and it might even just have one key-pair.

actually I read a post by Gavin discussing that, but I can't find where it is.
the client does not have to reveal the set of bitcoin addresses to a single server; he could use a different server for each address.

btw, I downloaded your java code; is the protocol documented somewhere?

[Jan]

This is an interesting idea! Basically this means that the client side can connect to any node in the network and let it be its proxy for creating valid transactions that the client can sign. The worst thing an evil node could do is to misinform the client about its current balance and generate transactions that are not valid/accepted by the network. Both of which can be alliveated by connecting to another node or connecting to several nodes simultaneously and compare the results.

The flipside is that the client side will have to reveal the set of bitcoin addresses belonging to its wallet. For a simple mass-market client anonymity may not be an issue, and it might even just have one key-pair.

actually I read a post by Gavin discussing that, but I can't find where it is.
the client does not have to reveal the set of bitcoin addresses to a single server; he could use a different server for each address.

btw, I downloaded your java code; is the protocol documented somewhere?

I have been giving this a bit more thought. This approach requires that the bitcoin node is able to efficiently determine which transactions are associated with any incoming address, and whether the transactions are not already spent. I have not looked at the database layout of the official bitcoin client, but I doubt that the current design has been optimized for this use, we do after all have a -rescan option which takes a significant amount of time.

Regarding the BCCAPI protocol:
The API is pretty small and very well documented.
Look at the interface here: http://code.google.com/p/bccapi/source/browse/trunk/src/com/bccapi/api/BitcoinClientAPI.java
And the implementation here: http://code.google.com/p/bccapi/source/browse/trunk/src/com/bccapi/core/BitcoinClientApiImpl.java
Its simple HTTP requests over a HTTPS connection. There is no separate protocol documentation.

[ThomasV]

I have been giving this a bit more thought. This approach requires that the bitcoin node is able to efficiently determine which transactions are associated with any incoming address, and whether the transactions are not already spent. I have not looked at the database layout of the official bitcoin client, but I doubt that the current design has been optimized for this use, we do after all have a -rescan option which takes a significant amount of time.

yes, you are right, but something like libbitcoin or ABE could do it

Regarding the BCCAPI protocol:
The API is pretty small and very well documented.
Look at the interface here: http://code.google.com/p/bccapi/source/browse/trunk/src/com/bccapi/api/BitcoinClientAPI.java
And the implementation here: http://code.google.com/p/bccapi/source/browse/trunk/src/com/bccapi/core/BitcoinClientApiImpl.java
Its simple HTTP requests over a HTTPS connection. There is no separate protocol documentation.

I looked at these files. but you did not publish the server side, did you?
from looking at the code, and from what you say above, it seems that your server has to keep track of the addresses and to maintain a list  of accounts.
This is not exactly what I had in mind. I am thinking about servers you don't have to be faithful to.

[Jan]

I have been giving this a bit more thought. This approach requires that the bitcoin node is able to efficiently determine which transactions are associated with any incoming address, and whether the transactions are not already spent. I have not looked at the database layout of the official bitcoin client, but I doubt that the current design has been optimized for this use, we do after all have a -rescan option which takes a significant amount of time.

yes, you are right, but something like libbitcoin or ABE could do it

Regarding the BCCAPI protocol:
The API is pretty small and very well documented.
Look at the interface here: http://code.google.com/p/bccapi/source/browse/trunk/src/com/bccapi/api/BitcoinClientAPI.java
And the implementation here: http://code.google.com/p/bccapi/source/browse/trunk/src/com/bccapi/core/BitcoinClientApiImpl.java
Its simple HTTP requests over a HTTPS connection. There is no separate protocol documentation.

I looked at these files. but you did not publish the server side, did you?
from looking at the code, and from what you say above, it seems that your server has to keep track of the addresses and to maintain a list  of accounts.
This is not exactly what I had in mind. I am thinking about servers you don't have to be faithful to.

No, the server side code has not been made public. And yes, the server side does keep track of transactions that have inputs for or outputs to the public keys belonging to various wallets. This bookkeeping is done while downloading the block chain.

The server that you are thinking about would have a database containing all transactions, which is optimized for determining this in close to real-time for any given public key. While this is seems doable, it is not what I have built.

[ThomasV]

No, the server side code has not been made public. And yes, the server side does keep track of transactions that have inputs for or outputs to the public keys belonging to various wallets. This bookkeeping is done while downloading the block chain.

The server that you are thinking about would have a database containing all transactions, which is optimized for determining this in close to real-time for any given public key. While this is seems doable, it is not what I have built.

ok, I have decided to implement this idea.
are you willing to share the server code ?
I would be interested in the communication between your server and the bitcoin network (propagating transactions)

[Jan]

No, the server side code has not been made public. And yes, the server side does keep track of transactions that have inputs for or outputs to the public keys belonging to various wallets. This bookkeeping is done while downloading the block chain.

The server that you are thinking about would have a database containing all transactions, which is optimized for determining this in close to real-time for any given public key. While this is seems doable, it is not what I have built.

ok, I have decided to implement this idea.
are you willing to share the server code ?
I would be interested in the communication between your server and the bitcoin network (propagating transactions)

The server code is based on bitcoinj, sprinkled with my own code. It requires pre-knowledge of public keys before transactions are confirmed, which is of no use to you.
If I were to implement this I would take bitcoinj and throw away all the wallet handling code, as you won't need it for your purpose.
Look for BlockChain.java, which is responsible of all the block chain handling and plug in an persistence layer that allows you to efficiently query for unspent transaction inputs based on a public-key/address. Once this is in place you are half-way there.

[ThomasV]

unfortunately java is not my favourite language.
I guess I will try to do it from scratch in python, using bitcoin-abe + bitcoind at the server side.