bitcoinj 0.13 released!

38 views
Skip to first unread message

Mike Hearn

unread,
Jul 14, 2015, 10:53:43 AM7/14/15
to bitc...@googlegroups.com, bitcoinj...@googlegroups.com
Hi there,

I'm pleased to announce the release of bitcoinj 0.13, which should be available from Maven Central in a few hours. This release represents about 9 months of work by many contributors: thanks to you all!

The commit hash of 0.13 is 52cec27046dd6307f2b83394f545b225cfccb066


Release notes
  • Major performance improvements:
    • Chain sync is now faster
    • Much faster handling of large wallets, especially on Android.
    • Tor bootstrap is significantly faster, and is now just a couple of seconds on desktops once the local caches are warm. This takes us one step closer to Tor-by-default.
  • Thanks to Kalpesh Parmar:
    • A MySQL block store has been added, it has the same feature as the PostgreSQL block store (can index the UTXO set and do balance queries for arbitrary addresses)
    • The Wallet class can now be connected to a UTXO database such as those created by the MySQL or Postgres block stores (or a remote block explorer). Unspent transaction outputs will be fetched from the given UTXOProvider for the purposes of creating spends and calculating the balance. Combined with the HD wallet support this allows for server side wallets with much higher scalability than previously possible.
  • A LevelDB SPV block store has been added. It doesn’t store the UTXO set or block contents, but lets you quickly look up any block header by hash, if you need that.
  • Checkpoints have now been integrated into the WalletAppKit class so you don’t need to set them up manually any more when using the JAR. Dalvik/Android users still must do it themselves, as classes.dex files cannot contain embedded files.
  • PeerGroup now implements a stalled peer detector: peers that are serving us the chain slower than a configurable bytes/second threshold will be disconnected and chain download will restart from another. The defaults are chosen conservatively so only peers that can’t filter >20 blocks per second will trigger a stall.
  • There is now support for HTTP seeds using the Cartographer protocol, which gives signed and thus auditable results.
  • Support for the getutxos message defined in BIP 65 has been added.
  • Some improvements to the WalletTemplate app. You can now send any amount out, and password scrypt hashing strength adaptation was improved.
  • Tor tweaks:
    • Track directory authority changes: turtles has been replaced by longclaw.
    • A workaround for thread safety bugs in some Linux glibc’s has been added, which resolves a segfault that could occur when trying to use Tor.
  • A new Context class has been introduced. Using Context is optional currently but will over time replace NetworkParameters in most cases as the general global object. A Context will be created and propagated between threads automatically for you in the 0.13 release as a backwards compatibility aid: however it is recommended that you create a Context yourself and pass it into core objects like Wallet and PeerGroup when possible to make the transition easier. In future, Context will hold various bits of configuration and global state that different parts of the library can use, to reduce repetitive re-configuration and wiring.
  • MarriedKeyChain can now be constructed with a watching key.
  • Thanks to Jarl Fransson, the payment channels library now has support for encrypted wallets.
  • TransactionBroadcast has been improved and now recognises network rejection via the reject message much more reliably.
  • Default number of peers has been bumped to 12 from 4 to avoid issues with flaky transaction broadcasts. Most wallet apps already have a similar change at the app level already.
  • Thanks to Mike Rosseel, peer discovery now works differently: peers handed back by aPeerDiscovery implementation are used in order and discoverers will be polled until a configurable max is reached, rather than stopping as soon as any discoverer returns peers.
  • The LinuxSecureRandom class that works around the Android random number generator faults has been integrated with bitcoinj and will be used automatically when appropriate. LinuxSecureRandom just reads entropy from /dev/urandom and bypasses the buggy userspace RNGs that all Android devices have shipped with. This change should help avoid issues with new Android developers that aren’t branching existing wallets and haven’t heard about the problems affecting the platform.
  • Thanks to Matt Corallo and Dave Collins, there are many improvements to the block tester.
  • References to prodnet have all been replaced with the more standard “main net” terminology.
  • Thanks to Amichai Rothman for many code cleanups.
  • Many, many bug fixes, small tweaks and new APIs, more API sanity checks and so on.

API changes:

  • The wallet.getBalance() call now returns the balance including watched addresses/outputs. To exclude watched outputs you should usewallet.getBalance(BalanceType.AVAILABLE_SPENDABLE) (or ESTIMATED_SPENDABLE to include immature coinbases and unconfirmed transactions). If you were previously usingwallet.getWatchedBalance() this is now a deprecated alias.
  • The Script constructor no longer sets the creation time to the current time. If you’re adding scripts to the wallet via wallet.addWatchedScript() then you should take care to set the creation time to something sensible and appropriate for your app, as otherwise you may end up with a wallet that has a creation time of zero meaning it will never use the checkpointing optimisation (as it doesn’t know when the script might appear in the chain). You will see a log warning if you forget to do this.
  • PeerEventListener has a new onPeersDiscovered event and theonBlocksDownloaded event now receives FilteredBlock objects when Bloom filtering is enabled. This allows apps to use the Merkle proofs calculated by remote peers for their own ends.
  • The PeerFilterProvider interface has replaced the getLock method with begin/end methods.
  • Changes to the TransactionConfidence API:
    • The getBroadcastBy() method now returns a set instead of an iterator.
    • Thanks to a collaboration with devrandom, confidence objects are no longer owned by Transaction objects: two different Transaction objects that represent the same logical transaction (i.e. same hash) will return the same confidence object from theirgetConfidence() methods. This eliminates bugs that could occur in previous versions if you ended up with the same transaction deserialized twice. Additionally confidence objects now pin themselves to the root object set when a listener is added to them, thus avoiding a common class of bugs in which a transaction is received from a network event listener, another listener is added to the confidence object and then it never runs because the entire object hierarchy gets garbage collected. These changes should be transparent to your app; they are here to remove sharp corners from the API and enable future scalability improvements.
  • As part of the previous change the MemoryPool class has been renamed toTxConfidenceTable and has a significantly different internal implementation and API. It is unlikely you were directly using this class, but if you were you may need to adapt your code.
  • PeerGroup.broadcastTransaction now returns a TransactionBroadcast object instead of a future: you can fix your code by just adding a .future() call on the result.
  • DownloadListener has been renamed to DownloadProgressTracker
  • PeerGroup.addPeerFilterProvider and ClientConnectionManager.openConnectionnow return futures instead of nothing.
  • PeerGroup no longer implements the Guava service interface. It has its own start/startAsync and stop/stopAsync methods. You no longer need to callawaitRunning() or awaitTerminated() which have been removed.
  • The PeerGroup lock is no longer held whilst invoking Bloom filter providers: this helps you to avoid circular deadlock when calling back into bitcoinj from inside your provider.
  • Thanks to Jarl Fransson, when deserializing a wallet the lock order is now alwayswallet->extension.
  • Coin.parseCoin() now throws IllegalArgumentException instead of ArithmeticException if the given string would result in fractional satoshis.

Andreas Schildbach

unread,
Jul 14, 2015, 5:34:47 PM7/14/15
to bitc...@googlegroups.com, bitcoinj...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Unfortunately we had to do a quick followup release in order to get
all binaries deployed to Maven Central. There are no code changes.

The git hash of release 0.13.1 is
f18c19f5260a4c38269c50290aa842b9f61e492e.


On 07/14/2015 04:53 PM, Mike Hearn wrote:
> Hi there,
>
> I'm pleased to announce the release of bitcoinj 0.13, which should
> be available from Maven Central in a few hours. This release
> represents about 9 months of work by many contributors: thanks to
> you all!
>
> The commit hash of 0.13 is
> 52cec27046dd6307f2b83394f545b225cfccb066
>
>
> _Release notes_
>
> * Major performance improvements: o Chain sync is now faster o Much
> faster handling of large wallets, especially on Android. o Tor
> bootstrap is significantly faster, and is now just a couple of
> seconds on desktops once the local caches are warm. This takes us
> one step closer to Tor-by-default. * Thanks to Kalpesh Parmar: o A
> MySQL block store has been added, it has the same feature as the
> PostgreSQL block store (can index the UTXO set and do balance
> queries for arbitrary addresses) o The Wallet class can now be
> connected to a UTXO database such as those created by the MySQL or
> Postgres block stores (or a remote block explorer). Unspent
> transaction outputs will be fetched from the given |UTXOProvider|
> for the purposes of creating spends and calculating the balance.
> Combined with the HD wallet support this allows for server side
> wallets with much higher scalability than previously possible. * A
> LevelDB SPV block store has been added. It doesn’t store the UTXO
> set or block contents, but lets you quickly look up any block
> header by hash, if you need that. * Checkpoints have now been
> integrated into the WalletAppKit class so you don’t need to set
> them up manually any more when using the JAR. Dalvik/Android users
> still must do it themselves, as classes.dex files cannot contain
> embedded files. * PeerGroup now implements a stalled peer detector:
> peers that are serving us the chain slower than a configurable
> bytes/second threshold will be disconnected and chain download will
> restart from another. The defaults are chosen conservatively so
> only peers that can’t filter >20 blocks per second will trigger a
> stall. * There is now support for HTTP seeds using the Cartographer
> protocol, which gives signed and thus auditable results. * Support
> for the |getutxos| message defined in BIP 65 has been added. * Some
> improvements to the WalletTemplate app. You can now send any amount
> out, and password scrypt hashing strength adaptation was improved.
> * Tor tweaks: o Track directory authority changes: turtles has been
> replaced by longclaw. o A workaround for thread safety bugs in some
> Linux glibc’s has been added, which resolves a segfault that could
> occur when trying to use Tor. * A new |Context| class has been
> introduced. Using Context is optional currently but will over time
> replace NetworkParameters in most cases as the general global
> object. A Context will be created and propagated between threads
> automatically for you in the 0.13 release as a backwards
> compatibility aid: however it is recommended that you create a
> Context yourself and pass it into core objects like Wallet and
> PeerGroup when possible to make the transition easier. In future,
> Context will hold various bits of configuration and global state
> that different parts of the library can use, to reduce repetitive
> re-configuration and wiring. * |MarriedKeyChain| can now be
> constructed with a watching key. * Thanks to Jarl Fransson, the
> payment channels library now has support for encrypted wallets. *
> TransactionBroadcast has been improved and now recognises network
> rejection via the reject message much more reliably. * Default
> number of peers has been bumped to 12 from 4 to avoid issues with
> flaky transaction broadcasts. Most wallet apps already have a
> similar change at the app level already. * Thanks to Mike Rosseel,
> peer discovery now works differently: peers handed back by
> a|PeerDiscovery| implementation are used in order and discoverers
> will be polled until a configurable max is reached, rather than
> stopping as soon as any discoverer returns peers. * The
> |LinuxSecureRandom| class that works around the Android random
> number generator faults has been integrated with bitcoinj and will
> be used automatically when appropriate. LinuxSecureRandom just
> reads entropy from /dev/urandom and bypasses the buggy userspace
> RNGs that all Android devices have shipped with. This change should
> help avoid issues with new Android developers that aren’t branching
> existing wallets and haven’t heard about the problems affecting the
> platform. * Thanks to Matt Corallo and Dave Collins, there are many
> improvements to the block tester. * References to prodnet have all
> been replaced with the more standard “main net” terminology. *
> Thanks to Amichai Rothman for many code cleanups. * Many, many bug
> fixes, small tweaks and new APIs, more API sanity checks and so
> on.
>
> API changes:
>
> * The |wallet.getBalance()| call now returns the balance
> /including/ watched addresses/outputs. To exclude watched outputs
> you should use|wallet.getBalance(BalanceType.AVAILABLE_SPENDABLE)|
> (or |ESTIMATED_SPENDABLE| to include immature coinbases and
> unconfirmed transactions). If you were previously
> using|wallet.getWatchedBalance()| this is now a deprecated alias. *
> The Script constructor no longer sets the creation time to the
> current time. If you’re adding scripts to the wallet via
> |wallet.addWatchedScript()| then you should take care to set the
> creation time to something sensible and appropriate for your app,
> as otherwise you may end up with a wallet that has a creation time
> of zero meaning it will never use the checkpointing optimisation
> (as it doesn’t know when the script might appear in the chain). You
> will see a log warning if you forget to do this. *
> |PeerEventListener| has a new |onPeersDiscovered| event and
> the|onBlocksDownloaded| event now receives |FilteredBlock| objects
> when Bloom filtering is enabled. This allows apps to use the
> Merkle proofs calculated by remote peers for their own ends. * The
> |PeerFilterProvider| interface has replaced the |getLock| method
> with begin/end methods. * Changes to the |TransactionConfidence|
> API: o The |getBroadcastBy()| method now returns a set instead of
> an iterator. o Thanks to a collaboration with devrandom, confidence
> objects are no longer owned by Transaction objects: two different
> Transaction objects that represent the same logical transaction
> (i.e. same hash) will return the same confidence object from
> their|getConfidence()| methods. This eliminates bugs that could
> occur in previous versions if you ended up with the same
> transaction deserialized twice. Additionally confidence objects now
> pin themselves to the root object set when a listener is added to
> them, thus avoiding a common class of bugs in which a transaction
> is received from a network event listener, another listener is
> added to the confidence object and then it never runs because the
> entire object hierarchy gets garbage collected. These changes
> should be transparent to your app; they are here to remove sharp
> corners from the API and enable future scalability improvements. *
> As part of the previous change the |MemoryPool| class has been
> renamed to|TxConfidenceTable| and has a significantly different
> internal implementation and API. It is unlikely you were directly
> using this class, but if you were you may need to adapt your code.
> * |PeerGroup.broadcastTransaction| now returns a
> |TransactionBroadcast| object instead of a future: you can fix your
> code by just adding a |.future()| call on the result. *
> |DownloadListener| has been renamed to |DownloadProgressTracker| *
> |PeerGroup.addPeerFilterProvider| and
> |ClientConnectionManager.openConnection|now return futures instead
> of nothing. * PeerGroup no longer implements the Guava service
> interface. It has its own start/startAsync and stop/stopAsync
> methods. You no longer need to call|awaitRunning()| or
> |awaitTerminated()| which have been removed. * The PeerGroup lock
> is no longer held whilst invoking Bloom filter providers: this
> helps you to avoid circular deadlock when calling back into
> bitcoinj from inside your provider. * Thanks to Jarl Fransson, when
> deserializing a wallet the lock order is now
> always|wallet->extension|. * |Coin.parseCoin()| now throws
> IllegalArgumentException instead of ArithmeticException if the
> given string would result in fractional satoshis.
>
> -- You received this message because you are subscribed to the
> Google Groups "bitcoinj" group. To unsubscribe from this group and
> stop receiving emails from it, send an email to
> bitcoinj+u...@googlegroups.com
> <mailto:bitcoinj+u...@googlegroups.com>. For more options,
> visit https://groups.google.com/d/optout.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlWlgHUACgkQymYr4YuHemBnZQCdF21G0aZjrzXi6YcDbjdn0X5F
MZAAn2hxkiHaWQtoMSm/YYa0I0yCtSD4
=1xUj
-----END PGP SIGNATURE-----
Reply all
Reply to author
Forward
0 new messages