Yes indeed. See:
https://bitcointalksearch.org/topic/rfc-requirements-for-headers-only-client-7972
Topic: [ANNOUNCE] BitCoinJ v0.1, a client-mode implementation in Java (Read 19192 times)
In terms of scalability, could a two-tier system be developed where super users would run the main bitcoin client that would store and verify the block chain and on the second tier normal users would use a lesser version of the client such as BitCoinJ (that does not store the block chain and is only used for verification of payments?)
If bitcoin goes mainstream and takes as many transactions as Visa (thousands per second) then would Bitcoin(supernode)/BitcoinJ(node) be a solution? Not everyone can afford racks of computers...
If bitcoin goes mainstream and takes as many transactions as Visa (thousands per second) then would Bitcoin(supernode)/BitcoinJ(node) be a solution? Not everyone can afford racks of computers...
I figured going from C# to Java would be easier than C# to C++.
Think of Java as C# without all the nifty stuff. When approaching a problem figure out how you'd do it without lambdas, function pointers, events, properties, valued enums, value type strings, etc. You just have objects and functions.Then remember never to test string equality with ==, always .equals().
I figured going from C# to Java would be easier than C# to C++.
It is. Just jump in. I don't think [mike] is a full time Java coder either though you wouldn't know it.
Think of Java as C# without all the nifty stuff. When approaching a problem figure out how you'd do it without lambdas, function pointers, events, properties, valued enums, value type strings, etc. You just have objects and functions.
Then remember never to test string equality with ==, always .equals().
Now you know Java. Get cracking!
Cool, I appreciate the work you're doing. I'm not doing anything critical, just want to play around with some ideas for Bitcoin related projects. I figured going from C# to Java would be easier than C# to C++.
Yes, that is supposed to work. I haven't tested it though. John Sample has been doing some work on the networking layer and supporting multiple simultaneous peers.
Right now it's not that useful to talk to multiple peers, at least not for Android clients which is what I'm working towards. The connect/sync/disconnect model works much better. In future it'll be helpful for other stuff but there needs to be some protocol extensions first (eg finding the lowest latency peer, probing the memory pool etc).
BitCoinJ is still a building site. Be aware lots will change, in particular the wallet format and APIs will still change a fair bit. I need to do more work on block chain re-orgs as there are a few unusual cases that aren't really handled today like a reorg causing a pending tx to become invalidated by a double spend. After that I'll probably do a 0.2 release.
Right now it's not that useful to talk to multiple peers, at least not for Android clients which is what I'm working towards. The connect/sync/disconnect model works much better. In future it'll be helpful for other stuff but there needs to be some protocol extensions first (eg finding the lowest latency peer, probing the memory pool etc).
BitCoinJ is still a building site. Be aware lots will change, in particular the wallet format and APIs will still change a fair bit. I need to do more work on block chain re-orgs as there are a few unusual cases that aren't really handled today like a reorg causing a pending tx to become invalidated by a double spend. After that I'll probably do a 0.2 release.
Ah, that makes sense. I'm newish to Java, and I've only been looking over the code the past few days, but can multiple Peers share the same BlockChain/Wallet? I was trying to figure out how one might manage multiple connections, but I wasn't sure if multiple instances of a Peer would sync on the same BlockChain.
Is it possible to create a Peer without a Wallet? It seems like you need a Wallet to create a BlockChain and a BlockChain to create a Peer.
You need a wallet. If you don't care about that just create a new one for every run of your program, "new Wallet()" directly passed to the constructor works fine.
I might make providing the object optional in future. Obviously you can't send/receive coins without a wallet so that use case is only for, as Satoshi might say, intrepid programmers who want to do something a bit different.
There are presently at least 2 independent Python p2p implementations...
Where? Are they open source?
Is it possible to create a Peer without a Wallet? It seems like you need a Wallet to create a BlockChain and a BlockChain to create a Peer.
What is "Goonies android client"? I was just about to take your java implementation and port it to android. Is someone else already working on this?
[mike], great job. Since it's Java and you hinted the code is Android compatible -- is there a plan to roll out a mobile client? -- not necessarily a p2p client though -- That is one thing I am eager to see.
Never mind, just read the project home, it says:"The project aims to be easier to understand than the C++ implementation, and be suitable for usage on constrained devices such as mobile phones."
"BitCoinJ implements (or rather, will implement) the "simplified payment verification" mode of Satoshis paper. It does not store a full copy of the block chain, rather, it stores what it needs in order to verify transactions with the aid of an untrusted peer node."
This is great if it can be achieved on mobile devices with good performance, I have some doubt though.
[mike], great job. Since it's Java and you hinted the code is Android compatible -- is there a plan to roll out a mobile client? -- not necessarily a p2p client though -- That is one thing I am eager to see.
Never mind, just read the project home, it says:"The project aims to be easier to understand than the C++ implementation, and be suitable for usage on constrained devices such as mobile phones."
"BitCoinJ implements (or rather, will implement) the "simplified payment verification" mode of Satoshis paper. It does not store a full copy of the block chain, rather, it stores what it needs in order to verify transactions with the aid of an untrusted peer node."
This is great if it can be achieved on mobile devices with good performance, I have some doubt though.
[mike], great job. Since it's Java and you hinted the code is Android compatible -- is there a plan to roll out a mobile client? -- not necessarily a p2p client though -- That is one thing I am eager to see.
+1 to what [mike] said, from this dev
(this is 'jgarzik', posting under a new nick)
(this is 'jgarzik', posting under a new nick)
Maybe later. For now there is plenty of work to do in supporting the needs of Goonies Android client.
I'm not sure if it'd be better to build a new GUI on top of BitCoinJ and compete with the C++ client directly, or just finish implementing client mode in Satoshis code and continue recommending that to new users.
My gut feeling is that a really well done client-mode in the C++ node would be better for now, because it could theoretically start out in client mode and then upgrade itself to a supernode (with a full copy of the chain) if it detected it had sufficient spare computing power and inbound connectivity. This would be best for the networks health as it'd ensure a constant supply of nodes that are verifying transactions properly. If most users ended up on an alternative BitCoinJ based client, that wouldn't happen.
But it's also a lot more work which right now nobody is doing. And I think we all accept/hope that in the future, people who just want to buy and sell things won't be able to run supernodes anyway because the transaction rate will be high enough that it'll become a major burden. Only miners and the biggest/more sophisticated merchants will do it. In that case having a One True Client that switches between modes might just become a liability as people with good computers install it and then a few days later wonder why their hard disk is constantly thrashing and they see giant spikes in CPU usage from this simple bit of payments software.
Another factor is that the burden of maintaining cross platform GUI code is pretty high. Satoshis code is lacking a lot of simple features (like recurring payments) that aren't hard to do, but nobody does them because working with wxWidgets is painful and compiling on all 3 supported platforms especially awkward. A Java SWT/Swing based client would be open to more developers, and you could make a change on one platform that runs on others you may not have access to with a reasonable degree of confidence.
On the other hand Java desktop apps have a reputation for sucking, partly because historically Swing and the JVM were very bad at doing GUIs, partly because Java is a resource pig and partly because Oracles JRE is annoying as hell and constantly bugs you to upgrade.
So there are pros and cons, I haven't thought about it much beyond that.
I'm not sure if it'd be better to build a new GUI on top of BitCoinJ and compete with the C++ client directly, or just finish implementing client mode in Satoshis code and continue recommending that to new users.
My gut feeling is that a really well done client-mode in the C++ node would be better for now, because it could theoretically start out in client mode and then upgrade itself to a supernode (with a full copy of the chain) if it detected it had sufficient spare computing power and inbound connectivity. This would be best for the networks health as it'd ensure a constant supply of nodes that are verifying transactions properly. If most users ended up on an alternative BitCoinJ based client, that wouldn't happen.
But it's also a lot more work which right now nobody is doing. And I think we all accept/hope that in the future, people who just want to buy and sell things won't be able to run supernodes anyway because the transaction rate will be high enough that it'll become a major burden. Only miners and the biggest/more sophisticated merchants will do it. In that case having a One True Client that switches between modes might just become a liability as people with good computers install it and then a few days later wonder why their hard disk is constantly thrashing and they see giant spikes in CPU usage from this simple bit of payments software.
Another factor is that the burden of maintaining cross platform GUI code is pretty high. Satoshis code is lacking a lot of simple features (like recurring payments) that aren't hard to do, but nobody does them because working with wxWidgets is painful and compiling on all 3 supported platforms especially awkward. A Java SWT/Swing based client would be open to more developers, and you could make a change on one platform that runs on others you may not have access to with a reasonable degree of confidence.
On the other hand Java desktop apps have a reputation for sucking, partly because historically Swing and the JVM were very bad at doing GUIs, partly because Java is a resource pig and partly because Oracles JRE is annoying as hell and constantly bugs you to upgrade.
So there are pros and cons, I haven't thought about it much beyond that.
Are there any plans to add a GUI to bitcoinj so that we ordinary mortals can test it as a replacement for the official Bitcoin client?
The PingService example uses localhost so yes, it expects a local C++ node running.
You can point it at some other node if you like, for instance one of the nodes on the wiki fallback page. I haven't written the code to discover new nodes, record their addresses etc yet, so you have to provide it with an IP address to start with.
You can point it at some other node if you like, for instance one of the nodes on the wiki fallback page. I haven't written the code to discover new nodes, record their addresses etc yet, so you have to provide it with an IP address to start with.
Just to make sure, is it supposed to need the official bitcoin client running when running the example to download blocks?
Jump to: