If you have been reading that field, you probably want to use Transaction.REFERENCE_DEFAULT_MIN_TX_FEE.
If you have been writing to that field to change the SendRequest.feePerKb default, use a Context.feePerKb
instead. There is also a new Context.ensureMinRequiredFee.
Split PeerConnectionEventListener into individual connect, disconnect
and discovery listeners.
Remove custom listener registration from Peer, as now it's possible to
register a connect listener only, without a disconnect listener.
Refactor listener interfaces into their own package.
Split listener interfaces into smaller interfaces.
Make abstract implementations actually abstract.
Rearrange methods for adding listeners to put executor first.
Deprecates the old constructors and migrates bitcoinj itself to use the new API. Also makes DumpedPrivateKey use WrongNetworkException when appropriate. Adds missing testcases and corrects/adds a bit of JavaDoc.
- depracated constructors
- wrap methods to wrap given hash values in a new instance
- of/twiceOf methods to calculate hash values in a new instance
- hash/hashTwice to calculate hash values and return the raw bytes
* A constructor that only takes the wallet as an argument
* A setTransactionBroadcaster() which should be called when the Bitcoin network is ready
Motivation: Some wallets (MultiBitHD) does not use WalletAppKit, and starts with reading the wallet before initializing the bitcoin network.
Now these wallets can create the wallet (and the wallet file is read), and call the setter after the bitcoin network is up.
Remove Netty entirely, using the new Nio wrapper classes instead
* BitcoinSerializer now uses ByteBuffers directly instead of
InputStreams.
* TCPNetworkConnection and NetworkConnection interface deleted,
Peer now extends the abstract class PeerSocketHandler which
handles deserialization and interfaces with the Nio wrapper
classes.
* As a part of this, all version message handling has been moved
to Peer, instead of doing it in TCPNetworkConnection.
* Peer.setMinProtocolVersion() now returns a boolean instead of a
null/non-null future which holds the now-closing channel.
* Peer.sendMessage (now PeerSocketHandler.sendMessage()) now
returns void.
* PeerGroup has some significant API changes:
* removed constructors which take pipeline factories,
makePipelineFactory, createClientBootstrap
* Replaced with a setSocketTimeoutMillis method that sets a
timeout between openConnection() and version/verack exchange.
(Note that because Peer extends AbstractTimeoutHandler, it has
useful timeout setters public already).
* connectTo returns a Peer future, not a ChannelFuture
* removed peerFromChannelFuture and peerFromChannel
* Peer and PeerGroup Tests have semi-significant rewrites:
* They use actual TCP connections to localhost
* The "remote" side is a InboundMessageQueuer, which queues
inbound messages and allows for writing arbitrary messages.
* It ignores certain special pings which come from pingAndWait,
which is used to wait for message processing in the Peer.
* Removed a broken test in PeerGroupTest that should be reenabled
if we ever prefer a different version than our minimum version
again.
* Removed two duplicate tests in PeerTest (testRun_*Exception)
which are tested for in badMessage as well.
* Added a test for peer timeout and large message deserialization
Author: Matt Corallo <git@bluematt.me>
If there's insufficient balance (typical error) then InsufficientMoneyException is thrown (checked).
If the SendRequest is bad in some way, like asking to create a spend that would violate the protocol rules, IllegalArgumentException is thrown (unchecked).
Also make VerificationException (and thus ProtocolException+ScriptException) unchecked.
Resolves issue 425.
The previous overloading of the term "close" to mean both settlement of the channel (broadcast of the final payment tx) and terminating/cleaning up the underlying network connection was very confusing and made the code harder to work with. The notion of "closing" a protocol that is often embedded inside others isn't really well defined, so there's perhaps more work to do here, but this change makes the code easier to follow and is basically a big pile of no-ops.
It's now just ForwardingService, doesn't use the "from address" concept anymore, and uses WalletAppKit + balance futures. The new code is much simpler and easier to read.
* API change: TransactionConfidence.Listener now takes a reason enum describing the general class of change.
* Confidence listeners are now invoked in the user code thread as well, thus eliminating any chance of unexpected re-entrancy.
* The wallet batches up confidence changes and executes them all at the end of major operations, avoiding confusing intermediate transitions that could occur in the previous design.
* Much code has been simplified as a result and it's now harder to screw up.
This implements micropayment payment channels in several parts:
* Adds PaymentChannel[Server|Client]State state machines which
handle initialization of the payment channel, keep track of
basic in-memory state, and check data received from the other
side, based on Mike Hearn's initial implementation.
* StoredPaymentChannel[Client|Server]States manage channel
timeout+broadcasting of relevant transactions at that time,
keeping track of state objects which allow for channel
resume, and are saved/loaded as a WalletExtension.
* Adds PaymentChannel[Client|Server] which manage a connection
by getting new protobufs, generating protobufs for the other
side, properly stepping the associated State object and
ensuring the StoredStates object is properly used to save
state in the wallet.
* Adds PaymentChannel[ClientConnection|ServerListener] which
create TCP sockets to each other and use
PaymentChannel[Client|Server] objects to create/use payment
channels.
The algorithm implemented is the one described at
https://en.bitcoin.it/wiki/Contracts#Example_7:_Rapidly-adjusted_.28micro.29payments_to_a_pre-determined_party
with a slight tweak to use looser SIGHASH flags so that the
Wallet.completeTx code can work its magic by adding more inputs if
it saves on fees.
Thanks to Mike Hearn for the initial state machine implementations
and all his contracts work and Jeremy Spilman for suggesting the
protocol modification that works with non-standard nLockTime
Transactions.
The old "prodnet" name could be confusing to non-native speakers or people who just haven't been exposed to Google lingo. Main net is more idiomatic.
Conflicts:
tools/src/main/java/com/google/bitcoin/tools/BlockImporter.java
Put DNS seeds into NetworkParams.
Deprecate IrcDiscovery and remove the unit tests for it.
Update examples and tools to use DNS for everything.
Resolves issue 299.
Unfortunately this introduces some new FindBugs warnings because it doesn't understand the inside-out locking pattern used here, despite that it's correct.
Update issue 233.
- Delete the PeerGroupThread and replace it with a connectToAnyPeer() method. Getting connected to the network is now significantly faster as there is no sleep-wait loop between connections.
- Delete the connectionTimeMillis param to the PeerGroup constructors.
- Expose the PeerGroup c'tor that lets you specify the ClientBootstrap and expose a utility method to make one. This means users can now customize TCP options directly.
- PeerGroup.setMaxConnections() now actually creates or tears down connections to meet the new required number, if the peer group is running.
- Update the PeerMonitor so there's a spinner that lets you add or remove peers. Connecting and version handshaking is very fast now.
- Misc changes and fixes.
It means a send won't be considered completed until it's accepted by the net.
Also is for the case where you receive a transaction (eg, via Bluetooth) and
you want to broadcast it such that you can know it's valid.
Make WalletTool use --peers instead of --peer, a comma separated list of
addresses to use. Remove the crappy sleep after send now we can wait.
Resolves issue 167.
