bitcoinj / bitcoinj

A library for working with Bitcoin

Welcome to bitcoinj

The bitcoinj library is a Java implementation of the Bitcoin protocol, which allows it to maintain a wallet and send/receive transactions without needing a local copy of Bitcoin Core. It comes with full documentation and some example apps showing how to use it.

Technologies

• Java 8+ (needs Java 8 API or Android 8.0 API, compiles to Java 8 bytecode) and Gradle 4.4+ for the core module

• Java 11+ and Gradle 4.4+ for tools, wallettool and examples

• Java 17+ and Gradle 7.3+ for the JavaFX-based wallettemplate

• Gradle - for building the project

• Google Protocol Buffers - for use with serialization and hardware communications

Getting started

To get started, it is best to have the latest JDK and Gradle installed. The HEAD of the master branch contains the latest development code and various production releases are provided on feature branches.

Building from the command line

Official builds are currently using JDK 17. Our GitHub Actions build and test with JDK 11, 17 and 21.

To perform a full build (including JavaDocs, unit/integration tests, and wallettemplate) use JDK 17+.

gradle clean build

If you are using JDK 17+ and Gradle 7.3+, the build will automatically include the JavaFX-based wallettemplate module. The outputs are under the build directory.

To perform a full build without unit/integration tests use:

gradle clean assemble

Building from an IDE

Alternatively, just import the project using your IDE. IntelliJ has Gradle integration built-in and has a free Community Edition. Simply use File | New | Project from Existing Sources and locate the build.gradle in the root of the cloned project source tree.

Building and Using the Wallet Tool

The bitcoinj wallettool subproject includes a command-line Wallet Tool (wallet-tool) that can be used to create and manage bitcoinj-based wallets (both the HD keychain and SPV blockchain state.) Using wallet-tool on Bitcoin’s test net is a great way to learn about Bitcoin and bitcoinj.

To build an executable shell script that runs the command-line Wallet Tool, use:

gradle bitcoinj-wallettool:installDist

You can now run the wallet-tool without parameters to get help on its operation:

./wallettool/build/install/wallet-tool/bin/wallet-tool

To create a test net wallet file in ~/bitcoinj/bitcoinj-test.wallet, you would use:

mkdir ~/bitcoinj

./wallettool/build/install/wallet-tool/bin/wallet-tool --net=TESTNET --wallet=$HOME/bitcoinj/bitcoinj-test.wallet create

To sync the newly created wallet in ~/bitcoinj/bitcoinj-test.wallet with the test net, you would use:

./wallettool/build/install/wallet-tool/bin/wallet-tool --net=TESTNET --wallet=$HOME/bitcoinj/bitcoinj-test.wallet sync

To dump the state of the wallet in ~/bitcoinj/bitcoinj-test.wallet with the test net, you would use:

./wallettool/build/install/wallet-tool/bin/wallet-tool --net=TESTNET --wallet=$HOME/bitcoinj/bitcoinj-test.wallet dump

Note	These instructions are for macOS/Linux, for Windows use the wallettool/build/install/wallet-tool/bin/wallet-tool.bat batch file with the equivalent Windows command-line commands and options.

Building the reference build

Our reference build (which is also used for our releases) is running within a container to provide good reproducibility. Buildah 1.26+, Podman 4.1+ and Docker (with BuildKit) are supported. We tested various combinations of host OSes (Debian, Ubuntu, macOS, Windows+WSL) and architectures (amd64, arm64). For usage instructions see build.Containerfile.

Example applications

These are found in the examples module.

Where next?

Now you are ready to follow the tutorial.

Testing a SNAPSHOT build

Building apps with official releases of bitcoinj is covered in the tutorial.

If you want to develop or test your app with a Jitpack-powered build of the latest master or release-0.16 branch of bitcoinj follow the dynamically-generated instructions for that branch by following the correct link.

• master branch

• release-0.16 branch

bitcoinj's Issues

Wallet is loosing coins (change?) when sending

Originally reported on Google Code with ID 28

Now I got it:

I just had 1 BTC balance according to Wallet.getBalance(). Then I sent 0.8 BTC, look
at the log:

I/System.out( 6219): about to send 80000000 (BTC 0.80) to n4YrSHNNGKHB6RfgTsnF1S784a1hVxwRfx
W/System.err( 6219): 523107 [backgroundThread] INFO com.google.bitcoin.core.Wallet
- Creating send tx to n4YrSHNNGKHB6RfgTsnF1S784a1hVxwRfx for 0.80
W/System.err( 6219): 523108 [backgroundThread] INFO com.google.bitcoin.core.Wallet
-   with 0.20 coins change
D/dalvikvm( 6219): GC_CONCURRENT freed 672K, 52% free 3294K/6727K, external 1993K/2137K,
paused 2ms+6ms
W/System.err( 6219): 523527 [backgroundThread] INFO com.google.bitcoin.core.Wallet
-   created 1e4d2a37cf562c067c12781cff76c5c63f738b1e3a18e3ee34a18e7027501979
W/System.err( 6219): 523531 [backgroundThread] INFO com.google.bitcoin.core.Wallet
- confirmSend of 1e4d2a37cf562c067c12781cff76c5c63f738b1e3a18e3ee34a18e7027501979
I/System.out( 6219): wallet saved to: /data/data/de.schildbach.wallet/app_testnet/wallet-test

Although I should have that 0.20 BTC change, Wallet.getBalance() returns 0.0 BTC!

Reported by andreas.schildbach on 2011-06-13 20:43:38

• Blocked on: #31, #64

add method for removing event listeners to Wallet

Originally reported on Google Code with ID 27

    public synchronized void removeEventListener(WalletEventListener listener) {
        eventListeners.remove(listener);
    }

Reported by andreas.schildbach on 2011-06-13 18:49:08

TransactionOutPoint.fromTx is null

Originally reported on Google Code with ID 47

Please have a look at the attached testnet wallet. In order to de-serialize, you'd need
to temporarly add a Transaction.updatedAt (public Date) field.

I created this transaction yesterday:

broadcasting transaction:   b8e9fd0af76b3c05fd33db7461a470e9ad42651ffa1f25cf25713c177d1536d6
      from mwhsLCBMmTXgzjMXhteKk63siFRsCboVEm
        to mvpp82HddxaEgmN4sdtwPnFE1BRyjkdmg8 0.50 BTC
        to mwhsLCBMmTXgzjMXhteKk63siFRsCboVEm 0.50 BTC

Problem is, input.outpoint.getConnectedOutput() is now null in my wallet. This leads
to a NullPointerExcepton in Wallet.confirmSend()
I looked more closely: TransactionOutPoint.fromTx is null.

By looking at the code, there are only two cases in which fromTx will be null:

- genesis (I guess that's not the case)
- a blockchain reorg (could have happened, I was catching up on blocks just before
this problem started)

Reported by andreas.schildbach on 2011-07-12 11:50:31

---

- _Attachment: [wallet-testnet](https://storage.googleapis.com/google-code-attachments/bitcoinj/issue-47/comment-0/wallet-testnet)_

more robust serialization format for wallet

Originally reported on Google Code with ID 4

A recent added logic methos in TransactionOutPoint made me aware of the fact how vulnerable
our current wallet format (based on Serialization) is. Without any change of data at
all, the old format is not readble any more.

My proposal:

1) short-term: Go away from autogenerated serialVersionUID to manually assigned ones.
Advance only if strictly necessary (if the meaning of data changes).

2) mid-term: Allow for automatic migration if something needs to change. This means
old formats have to be supported for reading. I don't know if this is possible with
serialVersionUID.

3) long-term: As the Java serialization mechanism is not meant for long-term persistence,
move to an own solution. This is probably platform dependent. For example, on Android
I'd prefer to use an sqlite DB to store keys. Perhaps some kind of plugin mechanism
would be nice.

Reported by andreas.schildbach on 2011-03-13 11:39:29

• Blocking: #36

Ability to spend change before a transaction is confirmed

Originally reported on Google Code with ID 40

With the attached wallet, I've received 2, 3 and 4 BTC, having a total of 9 BTC.

When I sent 1, 1 and 1 BTC successfully. Any further sending yields the messages:

W/System.err(19106): 53630 [backgroundThread] INFO com.google.bitcoin.core.Wallet -
Creating send tx to mjzhnyZ3BxyMihgP3jvpBMUZufqSjTBh5g for 1.00
W/System.err(19106): 53631 [backgroundThread] INFO com.google.bitcoin.core.Wallet -
Insufficient value in wallet for send, missing 1.00

Reported by andreas.schildbach on 2011-07-06 18:02:39

---

- _Attachment: [wallet-testnet](https://storage.googleapis.com/google-code-attachments/bitcoinj/issue-40/comment-0/wallet-testnet)_

When to save the wallet?

Originally reported on Google Code with ID 38

I need to be able to determine when a wallet has unsaved changes. I see two options:

1. a Wallet.isDirty() method
2. a WalletEventListener.onWalletChanged() method

I am for option 2 as it lets me use the existing event listener.
Which one would you prefer?

Reported by jan.moller on 2011-07-02 15:54:42

Logging with SLF4J?

Originally reported on Google Code with ID 16

Considering the fact that bitcoinj may be used in several environments i suggest to
replace the 'homebrewn' logging facility with slf4j [1].

IMHO this is the best solution to handle logging in libraries as it does not force
the user to use a specific logging library.

I have attached a patch that replaces all LOG instances with slf4j. You'll need the
file slf4j-api.jar while compiling and an implementation while running.

[1] http://www.slf4j.org/faq.html#what_is

Reported by fhaust on 2011-04-21 19:38:11

---

- _Attachment: [bitcoinj-slf4j.patch](https://storage.googleapis.com/google-code-attachments/bitcoinj/issue-16/comment-0/bitcoinj-slf4j.patch)_

Use Maven shade plugin + dependency instead of storing the Bouncy Castle code in Subversion

Originally reported on Google Code with ID 42

Howto:
======

1. Add this to the plugins section in pom.xml:
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-shade-plugin</artifactId>
    <version>1.4</version>
    <executions>
        <execution>
            <phase>package</phase>
            <goals>
                <goal>shade</goal>
            </goals>
            <configuration>
                <relocations>
                    <relocation>
                        <pattern>org.bouncycastle</pattern>
                        <shadedPattern>com.google.bitcoin.bouncycastle</shadedPattern>
                    </relocation>
                </relocations>
                <artifactSet>
                    <includes>
                        <include>org.bouncycastle</include>
                    </includes>
                </artifactSet>
                <minimizeJar>true</minimizeJar>
            </configuration>
        </execution>
    </executions>
</plugin>

2. Add this to the dependencies section in pom.xml
<dependency>
    <groupId>org.bouncycastle</groupId>
    <artifactId>bcprov-jdk15</artifactId>
    <version>1.46</version>
    <type>jar</type>
    <scope>compile</scope>
</dependency>

3. Replace all usage of 'com.google.bitcoin.bouncycastle' to 'org.bouncycastle' in
all Java files.

Opening the the .jar files will show that Bouncy Castle class files exists in com/google/bitcoin/bouncycastle
and a decompiler will show that depending code uses the classes in the com.google.bitcoin.bouncycastle
package.

Reported by hegjon on 2011-07-07 22:41:53

Allow incoming peer connections

Originally reported on Google Code with ID 46

I had several requests of two mobile Wallets connecting each other directly.

For this to work, one of those would need to accept incoming connections.

Of course, this could also be used to participating in the P2P network like a Desktop
client does.

I'll quote the Bitcoin 0.3.24 release notes: "The percentage of bitcoin clients that
accept incoming connections is quite small, and that is a problem."

Reported by andreas.schildbach on 2011-07-08 22:01:13

Transaction date in Transactions

Originally reported on Google Code with ID 43

I propose we add a transaction date for transactions.

Clients need to able to sort the list of transactions by time. The official client
displays a date and time as well.

Reported by andreas.schildbach on 2011-07-08 08:03:50

Patch for /trunk/build.xml

Originally reported on Google Code with ID 22

Remove extraneous '/' at line 32

Reported by bowlingb on 2011-05-22 03:26:37

---

- _Attachment: [build.xml.patch](https://storage.googleapis.com/google-code-attachments/bitcoinj/issue-22/comment-0/build.xml.patch)_

Patch to add ECKey#toASN1 to convert it back into the standard format

Originally reported on Google Code with ID 8

This patch adds a toASN1 method to go along with ECKey#fromASN1.

The produced byte sequence is not identical, it is longer, because of the way BountyCastle
adds padding to the eliptic curve parameters.
But the attached unit test confirms that it can be read again and produces the same
key.

I planned to use this instead of Object serialization, but it seems that the ASN1 is
actually longer than the Java serialization, because it also includes the curve description,
which the code assumes to be fixed.

https://github.com/thiloplanz/bitcoinj/commit/1d1f32699c4d554ed66c33f1cc38d0fd1eaeeed5

I have submitted the electronic version of your CLA.

Reported by thiloplanz on 2011-03-31 13:07:44

Implement the peer discovery protocol

Originally reported on Google Code with ID 10

Right now, you have to know the IP address of another network peer to connect to. See
for example the PingService class, which connects to localhost (where presumably the
native client is running).

We should implement a class that implements peer discovery, using the same methods
as the native client (i.e. a built-in list of IPs that are usually online, and querying
the IRC channel).

Reported by thiloplanz on 2011-04-08 13:11:02

Wallet: list all transactions

Originally reported on Google Code with ID 3

It would be useful if a wallet can be asked for all transactions that affect the balance
at all, not only the 'unspent' ones.

Reported by andreas.schildbach on 2011-03-11 13:53:20

decoupling of wallet and blockchain

Originally reported on Google Code with ID 19

Currently the BlockChain depends on the Wallet and calls methods directly. I believe
that this is not correct.

In my eyes the BlockChain doesn't even have to know about the Wallet. It should be
the other way around. And i'll take that statement one step further by saying that
the Wallet shouldn't work on the BlockChain but should communicate with the Node.

In the bitcoin wiki there is a page about the bitcoin infrastructure: https://en.bitcoin.it/wiki/Infrastructure

While the 'wallet protocol' doesn't seem to be finished yet it should be clear that
the Wallet can work by communicating with the Node via the 'p2p protocol'.

I'll attach a patch against r70 that removes the Wallet dependency in the BlockChain.
It is pretty unpolished but my intention here is to spark the discussion about the
more fundamental decoupling mentioned above.

Reported by fhaust on 2011-05-12 17:51:26

---

- _Attachment: [wallet-uncoupling.patch](https://storage.googleapis.com/google-code-attachments/bitcoinj/issue-19/comment-0/wallet-uncoupling.patch)_

PingService waits indefinitely on peer discconnect

Originally reported on Google Code with ID 12

What steps will reproduce the problem?
1. Grab the 0.3.20.1 client and start it on localhost 
2. Start the PingService without a pingservice.blockchain
3. Wait

What is the expected output? What do you see instead?
Successful download of the initial blockchain from localhost. Instead the mainline
peer disconnects due to an issue with flood protection, the Peer thread reading incoming
data dies and the main thread waits indefinitely.

What version of the product are you using? On what operating system?
mainline 0.3.20.1, bitcoinj r51, OSX 10.6.7

Please provide any additional information below.

It would be nice to have a few re-tries on peer disconnect. Also, it would be nice
for Peer to indicate failure back to it's caller. I propose we drop the CountDownLatch
returned by startBlockChainDownload() and instead create an await() method in Peer
mirroring CountDownLatch.await() semantics (possibly dropping the resolution parameter)
that can throw an exception if the download fails.

If a hard error is encountered by the peer and it shuts down, all it's methods should
fail with an unchecked exception IMHO. 

Reported by noa.resare on 2011-04-10 17:56:05

Transactions: effect on balance of my wallet

Originally reported on Google Code with ID 2

It would be useful if a transactions can be asked for the effect on the balance of my
wallet. This means the the sum of output values sent to my keys minus the sum of input
values taken from my keys.

Currently transactions can only be asked for getValueSentToMe (coins send to the keys
in my wallet).

Reported by andreas.schildbach on 2011-03-11 13:51:43

BlockChain block handling potential bug and enhancement

Originally reported on Google Code with ID 15

I have been reviewing bitcoinj for a project that is going to involve keeping track
of the block chain ala blockexplorer. I have a few problems with how the block handling
works in BlockChain.java. I am looking at fixing it myself, as I kind of need it for
my project, but I want to document the issues and make sure I am going in the right
direction.

My main concerns are:

1. StoredBlock asserts that there must be no transactions, and BlockChain.add() removes
the transactions from the block as soon as they have been processed. Blockstore.add()
 is passed a StoredBlock, meaning that there is no way for a BlockStore to implement
storing entire blocks, with transactions. 

Proposed Solution: 
1. Remove StoredBlock assetion of empty transactions
2. Add removal of transactions to existing BlockStore implementations to keep existing
functionality
3. Remove block.transactions = null from BlockChain.add

2. More seriously this is checking for transactions, and sending them to the wallet
before fitting this block into the block chain. Am I correct in reading that a block
which forks the chain, but does not cause a reorganization would have its transactions
sent to the wallet?... and then nothing done to remove them later? (I notice Wallet.reorganize()
is unimplemented so that case seems worst)

Wouldn't it make sense to only process transactions if the block is both new and fits
into the current longest block chain? (otherwise you need to do a reorganize anyway)

Once these are dealt with, I plan to implement an SQLBlockStore to hold both the chain
itself and the transactions within each block. 

Reported by thecarp on 2011-04-21 03:55:56

Use Apache Maven instead of Ant

Originally reported on Google Code with ID 13

Maven is supported out of the box in NetBeans, IntelliJ and via `mvn eclipse:eclipse`
for Eclipse. Maven also handle depenedencies, so external libraries could be declared
in the pom-file.


Attaching the Maven project file, should be placed in the top-level directory.

How to run the PingService:
1. bitcoinj$ `mvn clean install`
2. cd target && java -cp bitcoinj-1.0-SNAPSHOT.jar com.google.bitcoin.examples.PingService


BE AWARE! It will take a while the first run, since Maven will download all it's dependencies.

Reported by hegjon on 2011-04-10 20:17:17

Patch to specify timeout for peer connections and PingServiceIrcPeer example.

Originally reported on Google Code with ID 17

There is no network timeout parameter when trying to connect to peers.
I'm not sure what the java default is but its long. Over a minute as far as I can tell.


Not an issue when you are only connecting to localhost but when you have to go through
a list of potential peers before one will let you connect it causes a problem.

This patch changes NetworkConnection to accept a connection timeout parameter (milliseconds).

Also included is examples/PingServiceIrcPeer which demos the PingService connecting
to a discovered peer with a 5 second timeout. 
(5 seconds is still probably too long to wait before trying another)

examples/PingService and PrivateKeys were modified to use the timeout parameter.

(Obviously this patch should not be applied unless the PeerDiscovery patch is applied
first)

Reported by jwsample on 2011-04-29 02:13:53

---

- _Attachment: [bitcoinj-nettimeout.patch](https://storage.googleapis.com/google-code-attachments/bitcoinj/issue-17/comment-0/bitcoinj-nettimeout.patch)_

Patch to add missing getters to allow external Block serialization

Originally reported on Google Code with ID 9

Block and related classes are missing a few getters in order to allow external code
to query all relevant fields. With these additions, I could write code to serialize
a block as JSON in the format used by Blockexplorer (not included in this patch).

While doing this, I also noticed that the existing getter 'getMerkleRoot' returns a
byte array that is also stored and used internally (it is transient, though). This
would potentially allow external code to change the contents of the array, breaking
the Block instance (but probably only impacting itself). The method should maybe return
a copy. The other getters seem to enforce immutability.


https://github.com/thiloplanz/bitcoinj/commit/8181a1ee03c61145cc08e12270a74654f7328a6d

Reported by thiloplanz on 2011-04-07 11:12:49

PeerGroup code review request

Originally reported on Google Code with ID 41

Hi Mike,

Initial draft for your review - r136 - r138.

No unit tests yet.  I am hoping for feedback on architecture and API.

Sorry for the multiple revisions, I'm not sure if svn has a way to squash multiple
revs into one.

Reported by [email protected] on 2011-07-07 16:34:05

Transaction.getValueSentFromMe() bug & fix

Originally reported on Google Code with ID 35

Playing around with bitcoinj I found a bug with the PingService.
For some reason it stopped returning coins, and it turned out that the cause was that
WalletEventListener.onCoinsReceived() was not always called when coins are received.

In some cases the valueDifference in Wallet.receive() gets negative when the wallet
receives coins. This is because a bug in Transaction.getValueSentFromMe(). 

The problem is that a connected output in a transaction may point at the change to
the sender of a previous input sent to the wallet. The fix is simple, patch attached.


The wallet balance however turns up right, because the balance calculation is not based
on valueSentFromMe.

Reported by jan.moller on 2011-07-02 06:48:24

---

- _Attachment: [ValuesSentFromMe.patch](https://storage.googleapis.com/google-code-attachments/bitcoinj/issue-35/comment-0/ValuesSentFromMe.patch)_

unit tests fail to load SLF4J

Originally reported on Google Code with ID 21

unit tests fail to load SLF4J.

test target needs to be updated to include slf4j jars.

Index: build.xml
===================================================================
--- build.xml   (revision 78)
+++ build.xml   (working copy)
@@ -27,6 +27,8 @@
   <target name="test" depends="compile">
     <junit showoutput="false">
       <classpath path="lib/junit-4.8.2.jar:out"/>
+      <classpath path="lib/slf4j-api-1.6.1.jar:out"/>
+      <classpath path="lib/slf4j-simple-1.6.1.jar:out"/>
       <batchtest>
    <fileset dir="tests"><include name="**/*.java"/></fileset>
         <formatter type="brief" usefile="no"/> 

Reported by bowlingb on 2011-05-18 02:52:06

Patch for MemoryBlockStore to really clone Blocks

Originally reported on Google Code with ID 5

Index: src/com/google/bitcoin/core/BlockStoreException.java
===================================================================
--- src/com/google/bitcoin/core/BlockStoreException.java    (revision 38)
+++ src/com/google/bitcoin/core/BlockStoreException.java    (working copy)
@@ -17,7 +17,16 @@
 package com.google.bitcoin.core;

 /**
- * Thrown when something goes wrong with storing a block. Examples: out of disk space.
+ * Thrown when something goes wrong with storing a block. Examples: out of disk
+ * space.
  */
 public class BlockStoreException extends Exception {
+
+    public BlockStoreException() {
+   super();
+    }
+
+    public BlockStoreException(Throwable cause) {
+   super(cause);
+    }
 }
Index: src/com/google/bitcoin/core/MemoryBlockStore.java
===================================================================
--- src/com/google/bitcoin/core/MemoryBlockStore.java   (revision 38)
+++ src/com/google/bitcoin/core/MemoryBlockStore.java   (working copy)
@@ -16,6 +16,12 @@

 package com.google.bitcoin.core;

+import java.io.ByteArrayInputStream;
+import java.io.ByteArrayOutputStream;
+import java.io.IOException;
+import java.io.ObjectInputStream;
+import java.io.ObjectOutputStream;
+import java.math.BigInteger;
 import java.nio.ByteBuffer;
 import java.util.HashMap;
 import java.util.Map;
@@ -30,15 +36,44 @@
     private Map<ByteBuffer, StoredBlock> blockMap;

     MemoryBlockStore() {
-        blockMap = new HashMap<ByteBuffer, StoredBlock>();
+   blockMap = new HashMap<ByteBuffer, StoredBlock>();
     }

     public synchronized void put(StoredBlock block) throws BlockStoreException {
-        byte[] hash = block.header.getHash();
-        blockMap.put(ByteBuffer.wrap(hash), block);
+
+   final StoredBlock clonedBlock = clone(block);
+
+   byte[] hash = clonedBlock.header.getHash();
+   blockMap.put(ByteBuffer.wrap(hash), clonedBlock);
     }

     public synchronized StoredBlock get(byte[] hash) throws BlockStoreException {
-        return blockMap.get(ByteBuffer.wrap(hash));
+   return blockMap.get(ByteBuffer.wrap(hash));
+    }
+
+    private StoredBlock clone(final StoredBlock block)
+       throws BlockStoreException {
+
+   try {
+       final ByteArrayOutputStream baos = new ByteArrayOutputStream(2000);
+       final ObjectOutputStream os = new ObjectOutputStream(baos);
+       os.writeObject(block.getHeader());
+       os.writeObject(block.getChainWork());
+       os.writeInt(block.getHeight());
+       os.close();
+
+       final ObjectInputStream is = new ObjectInputStream(
+           new ByteArrayInputStream(baos.toByteArray()));
+       final Block header = (Block) is.readObject();
+       final BigInteger chainWork = (BigInteger) is.readObject();
+       final int height = is.readInt();
+       is.close();
+
+       return new StoredBlock(header, chainWork, height);
+   } catch (final IOException x) {
+       throw new BlockStoreException(x);
+   } catch (final ClassNotFoundException x) {
+       throw new BlockStoreException(x);
+   }
     }
 }

Reported by andreas.schildbach on 2011-03-26 00:01:58

Improve how coin values are represented in the API

Originally reported on Google Code with ID 11

The Utils class assumes that there are 100 million nanocoins in a bitcoin.

>  /** How many nanocoins there are in a BitCoin. */
>  public static final BigInteger COIN = new BigInteger("100000000", 10);
>  /** How many nanocoins there are in 0.01 BitCoins. */
>  public static final BigInteger CENT = new BigInteger("1000000", 10);

Both of these public(!) constants are missing a zero.

As a result the toNanoCoins method does not work correctly.

Will send a patch together with an improved one for issue #1 (and unit tests for both)

Reported by thiloplanz on 2011-04-09 02:17:04

log and/or get height of block chain

Originally reported on Google Code with ID 24

In order to debug problems with the block chain, I think the height should be logged
with log messages like "Block forks the chain, but it did not cause a reorganize."

Also, users are accustomed to see the number of blocks in the status bar, so I propose
there should be a getter of some kind.

Reported by andreas.schildbach on 2011-06-09 20:49:03

Implement a BitCoin class that encapsulates a BigInteger and formatting

Originally reported on Google Code with ID 23

As mentioned in the TODO

Reported by hegjon on 2011-06-03 10:46:02

java.lang.IllegalArgumentException: count < 0 in CountDownLatch

Originally reported on Google Code with ID 44

Peer.startBlockChainDownload() sometimes passes -1 (or 0?) blocksToGet into the CountDownLatch...


int blocksToGet = chainHeight - blockChain.getChainHead().getHeight();
chainCompletionLatch = new CountDownLatch(blocksToGet);

...causing a...

java.lang.IllegalArgumentException: count < 0
at java.util.concurrent.CountDownLatch.<init>(CountDownLatch.java:175)
at com.google.bitcoin.core.Peer.startBlockChainDownload(Peer.java:395)
at de.schildbach.wallet.Service.blockChainDownload(Service.java:392)
at de.schildbach.wallet.Service.access$7(Service.java:386)
at de.schildbach.wallet.Service$3$1.run(Service.java:316)
at android.os.Handler.handleCallback(Handler.java:587)
at android.os.Handler.dispatchMessage(Handler.java:92)
at android.os.Looper.loop(Looper.java:123)
at android.app.ActivityThread.main(ActivityThread.java:4627)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:521)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:858)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:616)
at dalvik.system.NativeStart.main(Native Method)

Reported by andreas.schildbach on 2011-07-08 19:32:04

Patch - DNS Discovery

Originally reported on Google Code with ID 18

Patch to add DNS Discovery is attached.

I probably should have started with this one instead of IRC. Much simpler.

The constructor requires a NetworkParameters object since DNS can't provide which port
to use.

If no host names are passed to the constructor bitseed.xf2.org and bitseed.bitcoin.org.uk
are used. 

The addresses returned are de-duplicated. Since the two default servers are mirrors
of each other you will probably only see the name of one if you print the results.

Reported by jwsample on 2011-04-29 21:38:46

---

- _Attachment: [bitcoinj-dnsdiscovery.patch](https://storage.googleapis.com/google-code-attachments/bitcoinj/issue-18/comment-0/bitcoinj-dnsdiscovery.patch)_

BitcoinSerializerTest.testVersion unit test fails if Message.SELF_CHECK enabled

Originally reported on Google Code with ID 29

If I set the Message.SELF_CHECK flag to true then the BitcoinSerializerTest.testVersion
unit test fails with the following message:

Serialization is wrong: 
000000000000000000000000000000000000ffff0a000001f6da vs 
010000000000000000000000000000000000ffff0a000001daf6

It looks like there are two issues:
1. Zero is always written instead of the services field value.
2. The upper and lower port bytes are written in the opposite order to the way they're
read.

Reported by nathan.baulch on 2011-06-14 17:11:21

Provide a compiled JAR in the Downloads section.

Originally reported on Google Code with ID 32

It would be very helpful to provide a compiled JAR in the Downloads section, especialy
for people wanting to test or develop a program using bitcoinj as a library.
Since the source code is already accessible, it has no added value to propose a Zip
of the source code in the Downloads section.

Reported by contact.oliviersaugeon on 2011-06-27 15:22:43

Minor array indexer bug in IrcDiscoveryTest

Originally reported on Google Code with ID 33

The assertion loop in IrcDiscoveryTest.testParseUserList uses hard coded array index
"0" instead of the for loop variable "i" in a couple of places.
I've attached a very simple patch to address this.

Reported by nathan.baulch on 2011-06-28 03:29:41

---

- _Attachment: [IrcDiscoveryTestFix.patch](https://storage.googleapis.com/google-code-attachments/bitcoinj/issue-33/comment-0/IrcDiscoveryTestFix.patch)_

Arch Linux, bitcoinj test fails

Can you please help me with this? Thanks! Seems to fail because of transaction confidence not building. There is nothing on the web I could find about it.

http://pastebin.com/vFaxjuTm

Patch for various Findbugs/PMD/Javadocs issues

Originally reported on Google Code with ID 34

Applied fixes for Findbugs/PMD/missing Javadocs

Taken count down from 1837 to 1807
Not explicitly closing streams
Javadocs in various files

Suggested refactorings
Replace Hashtables with generic HashMap (or synchronized map if threading is an issue)
Replace Vector with generic ArrayList (or synchronized list again for threading)

I've added a few entries with REFACTOR to identify possible areas which are being highlighted
as problem areas by the tools.

If you're happy with these changes, I'll continue to work on lowering the count as
part of a familiarisation process with the overall library.

Reported by g.rowe.froot on 2011-06-28 23:27:52

---

- _Attachment: [Findbugs-PMD-Javadocs.patch](https://storage.googleapis.com/google-code-attachments/bitcoinj/issue-34/comment-0/Findbugs-PMD-Javadocs.patch)_

Patch for allowing alternative BlockStores into BlockChain

Originally reported on Google Code with ID 6

Index: src/com/google/bitcoin/core/BlockChain.java
===================================================================
--- src/com/google/bitcoin/core/BlockChain.java (revision 40)
+++ src/com/google/bitcoin/core/BlockChain.java (working copy)
@@ -68,8 +68,11 @@
     private final ArrayList<Block> unconnectedBlocks = new ArrayList<Block>();

     public BlockChain(NetworkParameters params, Wallet wallet) {
-        // TODO: Let the user pass in a BlockStore object so they can choose how to
store the headers.
-        blockStore = new MemoryBlockStore();
+   this(params, wallet, new MemoryBlockStore());
+    }
+    
+    public BlockChain(NetworkParameters params, Wallet wallet, final BlockStore blockStore)
{
+        this.blockStore = blockStore; 
         try {
             // Set up the genesis block. When we start out fresh, it is by definition
the top of the chain.
             Block genesisHeader = params.genesisBlock.cloneAsHeader();

Reported by andreas.schildbach on 2011-03-26 00:17:20

Utils method to express bitcoin value as a double

Originally reported on Google Code with ID 25

I think something like this is needed in order to calculate with Bitcoin values, e.g.
calculate the value in other currencies:

public static double bitcoinValueToDouble(BigInteger value) {
    BigInteger coins = value.divide(COIN);
    BigInteger cents = value.remainder(COIN);
    return Double.parseDouble(String.format("%d.%08d", coins.intValue(), cents.intValue()));
}

Reported by andreas.schildbach on 2011-06-09 20:56:15

own source folder for com.google.bitcoin.examples

Originally reported on Google Code with ID 26

I think that package should be put into a separate source folder (e.g. examples, or
maybe join into the test folder?). Otherwise, the contained classes are included with
applications, which they do not belong to.

Reported by andreas.schildbach on 2011-06-09 21:08:49

Startup is slow

Originally reported on Google Code with ID 14

DiskBlockStore.load(file) is slowing down the startup.

It takes one second to load the current block chain with 117.000 blocks on my Intel
Core i7 with SSD. It takes "forever" on an emulated Android device.

I found two places that could be improved:
 1. Use BufferedReader for to read the file
   - FileInputStream input = new FileInputStream(file);
   + InputStream input =  new BufferedInputStream(new FileInputStream(file));

 2. Utils.doubleDigest(input, offset, length) is called 117.000 times.
   * Move MessageDigest.getInstance("SHA-256") to a final static variable.

Attaching the "Hot Spots" results before and after these two code changes.

Reported by hegjon on 2011-04-11 22:38:20

---

- _Attachment: bitcoin-profile-before.png
_ - _Attachment: bitcoinj-profiling-after.png
_

Patch for additional toNanoCoins() method

Originally reported on Google Code with ID 1

Index: Utils.java
===================================================================
--- Utils.java  (revision 17)
+++ Utils.java  (working copy)
@@ -47,6 +47,12 @@
         bi = bi.add(BigInteger.valueOf(cents).multiply(CENT));
         return bi;
     }
+    
+    public static BigInteger toNanoCoins(final CharSequence humanFriendlyString)
+    {
+       final float amount = Float.parseFloat(humanFriendlyString.toString());
+       return Utils.toNanoCoins((int) amount, (int) ((amount % 1) * 100));
+    }

     public static void uint32ToByteArrayBE(long val, byte[] out, int offset) {
         out[offset + 0] = (byte) (0xFF & (val >> 24));

Reported by andreas.schildbach on 2011-03-10 10:43:16

Don´t join the scripts in Transaction.join(Script a, Script b) without checking them separately for correctness!

Originally reported on Google Code with ID 30

You should evaluate each script separately sharing only the stack (as in VerifyScript()
in standard bitcoin client, or first check them for correctness.

I you join scripts without checking the correctness of each script separately, then
ScriptSig can force the script interpreter to see ScriptPubKey as data bytes to push
into the stack, by appending a OP_PUSHDATAx opcode to the last byte of ScriptSig.

Best regards,
 Sergio Demian Lerner.

Reported by sergio.d.lerner on 2011-06-18 15:21:17

StackOverflowError when sending my last Bitcoins

Originally reported on Google Code with ID 36

Have a look at

http://blockexplorer.com/testnet/address/mukdwUGeAjJiyDsg4pGU9S3xaQbJfa6JFe

After I was entering the last transaction (05acd31488ab73fb901ac8882989042ae288b2ccae8e6b6e96838ba517b9123b)
which was using all my remaining 5 Bitcoins, the client immediately crashed (I guess
while saving the wallet).

Note that I have applied the patch from issue 35.


E/AndroidRuntime(24167): java.lang.StackOverflowError
E/AndroidRuntime(24167):    at java.io.ObjectOutputStream.dumpCycle(ObjectOutputStream.java:471)
E/AndroidRuntime(24167):    at java.io.ObjectOutputStream.writeObjectInternal(ObjectOutputStream.java:1739)
E/AndroidRuntime(24167):    at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:1689)
E/AndroidRuntime(24167):    at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:1653)
E/AndroidRuntime(24167):    at java.io.ObjectOutputStream.writeFieldValues(ObjectOutputStream.java:1143)
E/AndroidRuntime(24167):    at java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:413)
E/AndroidRuntime(24167):    at java.io.ObjectOutputStream.writeHierarchy(ObjectOutputStream.java:1241)
E/AndroidRuntime(24167):    at java.io.ObjectOutputStream.writeHierarchy(ObjectOutputStream.java:1205)
E/AndroidRuntime(24167):    at java.io.ObjectOutputStream.writeNewObject(ObjectOutputStream.java:1575)
E/AndroidRuntime(24167):    at java.io.ObjectOutputStream.writeObjectInternal(ObjectOutputStream.java:1847)
E/AndroidRuntime(24167):    at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:1689)
E/AndroidRuntime(24167):    at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:1653)
E/AndroidRuntime(24167):    at java.io.ObjectOutputStream.writeFieldValues(ObjectOutputStream.java:1143)
E/AndroidRuntime(24167):    at java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:413)
E/AndroidRuntime(24167):    at java.io.ObjectOutputStream.writeHierarchy(ObjectOutputStream.java:1241)
E/AndroidRuntime(24167):    at java.io.ObjectOutputStream.writeNewObject(ObjectOutputStream.java:1575)
E/AndroidRuntime(24167):    at java.io.ObjectOutputStream.writeObjectInternal(ObjectOutputStream.java:1847)
E/AndroidRuntime(24167):    at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:1689)
E/AndroidRuntime(24167):    at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:1653)
E/AndroidRuntime(24167):    at java.util.ArrayList.writeObject(ArrayList.java:651)
E/AndroidRuntime(24167):    at java.lang.reflect.Method.invokeNative(Native Method)
E/AndroidRuntime(24167):    at java.lang.reflect.Method.invoke(Method.java:507)
E/AndroidRuntime(24167):    at java.io.ObjectOutputStream.writeHierarchy(ObjectOutputStream.java:1219)
E/AndroidRuntime(24167):    at java.io.ObjectOutputStream.writeNewObject(ObjectOutputStream.java:1575)
E/AndroidRuntime(24167):    at java.io.ObjectOutputStream.writeObjectInternal(ObjectOutputStream.java:1847)
E/AndroidRuntime(24167):    at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:1689)
E/AndroidRuntime(24167):    at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:1653)
E/AndroidRuntime(24167):    at java.io.ObjectOutputStream.writeFieldValues(ObjectOutputStream.java:1143)
E/AndroidRuntime(24167):    at java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:413)
E/AndroidRuntime(24167):    at java.io.ObjectOutputStream.writeHierarchy(ObjectOutputStream.java:1241)
E/AndroidRuntime(24167):    at java.io.ObjectOutputStream.writeNewObject(ObjectOutputStream.java:1575)
E/AndroidRuntime(24167):    at java.io.ObjectOutputStream.writeObjectInternal(ObjectOutputStream.java:1847)
E/AndroidRuntime(24167):    at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:1689)
E/AndroidRuntime(24167):    at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:1653)
E/AndroidRuntime(24167):    at java.util.ArrayList.writeObject(ArrayList.java:651)
E/AndroidRuntime(24167):    at java.lang.reflect.Method.invokeNative(Native Method)
E/AndroidRuntime(24167):    at java.lang.reflect.Method.invoke(Method.java:507)
E/AndroidRuntime(24167):    at java.io.ObjectOutputStream.writeHierarchy(ObjectOutputStream.java:1219)
E/AndroidRuntime(24167):    at java.io.ObjectOutputStream.writeNewObject(ObjectOutputStream.java:1575)
E/AndroidRuntime(24167):    at java.io.ObjectOutputStream.writeObjectInternal(ObjectOutputStream.java:1847)
E/AndroidRuntime(24167):    at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:1689)
E/AndroidRuntime(24167):    at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:1653)
E/AndroidRuntime(24167):    at java.io.ObjectOutputStream.writeFieldValues(ObjectOutputStream.java:1143)
E/AndroidRuntime(24167):    at java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:413)
E/AndroidRuntime(24167):    at java.io.ObjectOutputStream.writeHierarchy(ObjectOutputStream.java:1241)
E/AndroidRuntime(24167):    at java.io.ObjectOutputStream.writeNewObject(ObjectOutputStream.java:1575)
E/AndroidRuntime(24167):    at java.io.ObjectOutputStream.writeObjectInternal(ObjectOutputStream.java:1847)
E/AndroidRuntime(24167):    at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:1689)
E/AndroidRuntime(24167):    at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:1653)
E/AndroidRuntime(24167):    at java.io.ObjectOutputStream.writeFieldValues(ObjectOutputStream.java:1143)
E/AndroidRuntime(24167):    at java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:413)
E/AndroidRuntime(24167):    at java.io.ObjectOutputStream.writeHierarchy(ObjectOutputStream.java:1241)
E/AndroidRuntime(24167):    at java.io.ObjectOutputStream.writeNewObject(ObjectOutputStream.java:1575)
E/AndroidRuntime(24167):    at java.io.ObjectOutputStream.writeObjectInternal(ObjectOutputStream.java:1847)

Reported by andreas.schildbach on 2011-07-02 07:38:46

• Blocked on: #4

Create a scalable BlockStore

Originally reported on Google Code with ID 20

DiskBlockStore reads the entire chain into memory at startup.  Create an O(1) startup
BlockStore.

Reported by [email protected] on 2011-05-12 23:17:24

BlockChain to handle multiple wallets

Originally reported on Google Code with ID 39

This patch allows the BlockChain to feed into multiple wallets.
The change basically replaces BlockChain's
 Wallet wallet
with
 List<Wallet> wallets
and makes sure to call into all affected wallets when transactions are added.

Works like a charm in my setup.

Reported by jan.moller on 2011-07-05 19:49:46

---

- _Attachment: [BlockChainMultiWallet.patch](https://storage.googleapis.com/google-code-attachments/bitcoinj/issue-39/comment-0/BlockChainMultiWallet.patch)_

How-To for missing transactions in your wallet

Originally reported on Google Code with ID 31

This comes from reading the source, so please review it and think twice about it.

Here is the how-to:
- open your wallet / connect to the network
- Use a disk based block store
- send some coins to the wallet
- wait for the confirm log message on the bitcoinj app
- kill your java process :-)

What has happened?
- The chain head was updated in the blockstore
- The wallet "lost" the new transaction event
- The wallet will never ever see the event again.

I'd guess that this is the root of some of the lost-coins/lost-transaction complains.
The blockstore is persisted before the wallet gets stored. And the head pointer is
part of the block store, but it should be part of the wallet. (The key information
should be "what revision has our wallet", not "what revision did we download last?").

Reported by rtreffer on 2011-06-26 11:34:07

Update Guava to 17.0 when it's out to address BloomFilter large data set issue

Exciting that you folks are using Guava, and upgraded to 16.0.1. 17 should be out "any day now" (17.0-rc1 was just released to maven)

Most importantly, 17.0-final will fix https://code.google.com/p/guava-libraries/issues/detail?id=1119 in which BloomFilter is broken for large data sets. I'm new enough to bitcoinj to not know what BloomFilter is used for, but if it's used on the blockchain data (which I presume it is) that is a pretty big dataset that may be subject to this bug.

Non-fatal NullPointerException and lost coins when receiving bitcoins

Originally reported on Google Code with ID 37

Have a look at
http://blockexplorer.com/testnet/address/mkpfXCwR7m4NGZu6oLubYrTW4g71uUx3jv

I was sending 5 BTC (9d12d10f0b29239e0807744daa50b22b4079657b12a4a0fdb842abe70f6d1ec0)
from the Satoshi client while the BitCoinJ client was NOT active. After I saw that
the tx was included in a block, I started the BitCoinJ client. Soon after, I received
the transaction and the following exception occured. The 5 BTC are not visible in Wallet.getBalance(ESTIMATED)
right now, although they should.

Note that I have the patch from issue 35 applied.

W/System.err(25136): 584416 [main] INFO com.google.bitcoin.core.Peer - blockChainDownload(0000000000000000000000000000000000000000000000000000000000000000)
W/System.err(25136): 584822 [Bitcoin peer thread: [46.4.245.112]:18333 (connected)]
INFO com.google.bitcoin.core.BlockChain - 1 blocks per second
W/System.err(25136): 584834 [Bitcoin peer thread: [46.4.245.112]:18333 (connected)]
INFO com.google.bitcoin.core.Wallet - Received tx for 5.00 BTC: 9d12d10f0b29239e0807744daa50b22b4079657b12a4a0fdb842abe70f6d1ec0
W/System.err(25136): java.lang.NullPointerException
W/System.err(25136):    at com.google.bitcoin.core.Wallet.updateForSpends(Wallet.java:341)
W/System.err(25136):    at com.google.bitcoin.core.Wallet.processTxFromBestChain(Wallet.java:307)
W/System.err(25136):    at com.google.bitcoin.core.Wallet.receive(Wallet.java:282)
W/System.err(25136):    at com.google.bitcoin.core.Wallet.receive(Wallet.java:211)
W/System.err(25136):    at com.google.bitcoin.core.BlockChain.scanTransaction(BlockChain.java:409)
W/System.err(25136):    at com.google.bitcoin.core.BlockChain.sendTransactionsToWallet(BlockChain.java:276)
W/System.err(25136):    at com.google.bitcoin.core.BlockChain.connectBlock(BlockChain.java:173)
W/System.err(25136):    at com.google.bitcoin.core.BlockChain.add(BlockChain.java:156)
W/System.err(25136):    at com.google.bitcoin.core.BlockChain.add(BlockChain.java:102)
W/System.err(25136):    at com.google.bitcoin.core.Peer.processBlock(Peer.java:129)
W/System.err(25136):    at com.google.bitcoin.core.Peer.run(Peer.java:87)
W/System.err(25136):    at com.google.bitcoin.core.Peer.access$1(Peer.java:79)
W/System.err(25136):    at com.google.bitcoin.core.Peer$1.run(Peer.java:66)
W/System.err(25136):    at java.lang.Thread.run(Thread.java:1019)

Reported by andreas.schildbach on 2011-07-02 09:33:48

Add NFKD normalization form to BIP39 code

Hello,

during BIP39 acceptance discussion we've found that it would be helpful to better specify the way how to handle UTF-8 strings. Please check bitcoin/bips#17 for more details and for relevant changes in the draft.

This link will probably help you with NFKD normalization: http://docs.oracle.com/javase/tutorial/i18n/text/normalizerapi.html

I think we're quite near to find a concensus across developers and BIP39 will turn into Accepted state quite soon. However I recommend to wait with the changes until it will be clear that everybody is happy with NFKD and there won't be any further changes in the paper.

implement transaction fees

Originally reported on Google Code with ID 45

Just a reminder issue so it doesn't get lost.

Transaction fees are even an issue on testnet nowaways. Although blocks really do not
contain many transactions on testnet, many of my non-fee transactions are left pending
for several blocks.

Reported by andreas.schildbach on 2011-07-08 19:58:01

Patch to allow alternative BlockStores to exist in a different Java package

Originally reported on Google Code with ID 7

Index: src/com/google/bitcoin/core/BlockStore.java
===================================================================
--- src/com/google/bitcoin/core/BlockStore.java (revision 38)
+++ src/com/google/bitcoin/core/BlockStore.java (working copy)
@@ -26,7 +26,7 @@
  *
  * BlockStores are thread safe.
  */
-interface BlockStore {
+public interface BlockStore {
     /**
      * Saves the given block header+extra data. The key isn't specified explicitly
as it can be calculated from the
      * StoredBlock directly. Can throw if there is a problem with the underlying storage
layer such as running out of
Index: src/com/google/bitcoin/core/StoredBlock.java
===================================================================
--- src/com/google/bitcoin/core/StoredBlock.java    (revision 39)
+++ src/com/google/bitcoin/core/StoredBlock.java    (working copy)
@@ -27,7 +27,7 @@
  *
  * StoredBlocks are put inside a {@link BlockStore} which saves them to memory or
disk.
  */
-class StoredBlock {
+public class StoredBlock {
     /**
      * The block header this object wraps. The referenced block object must not have
any transactions in it.
      */
@@ -45,12 +45,24 @@
      */
     int height;

-    StoredBlock(Block header, BigInteger chainWork, int height) {
+    public StoredBlock(Block header, BigInteger chainWork, int height) {
         assert header.transactions == null : "Should not have transactions in a block
header object";
         this.header = header;
         this.chainWork = chainWork;
         this.height = height;
     }
+    
+    public Block getHeader() {
+   return header;
+    }
+    
+    public BigInteger getChainWork() {
+   return chainWork;
+    }
+    
+    public int getHeight() {
+   return height;
+    }

     /** Returns true if this objects chainWork is higher than the others. */
     boolean moreWorkThan(StoredBlock other) {

Reported by andreas.schildbach on 2011-03-26 00:30:48