This change migrates from using `NetworkParameters` to `Network` for specifying the network and
also decouples from static methods in `Address` with an interface/implementation approach.
Note that there are 3 use cases for address parsing:
1. Any network is allowed - AddressParser.parseAddressAnyNetwork(String)
2. Parse for a specified network - AddressParser.parseAddress(String, Network)
3. Parse for a previously-specified (context dependent) network - AddressParser.Strict.parseAddress(String)
In most use cases, an AddressParser instance can be accessed through the Wallet,
which already knows the Network type and in this context validation for network makes
sense. This is why `Wallet` is implementing `AddressParser.Strict`
BitcoinURI allocates its own DefaultAddressParser for now, as do some other tests
and examples that don't have access to a Wallet
In the future DefaultAddressParser may be replaced by something loaded
via the ServiceLoader mechanism or other dynamically configured mechanism.
* WalletAppKit: add a constructor that takes a BitcoinNetwork
* WalletAppKit: deprecate constructors taking netParams or Context
* WalletAppKit: add an accessor for network()
* Update examples, tools, and wallettemplate to use the new constructor
This also moves Coin, Fiat, its parent Monetary and the related MonetaryFormat into the new base package.
See the provided package-info.java for details.
* Make the static field `estimatedKeyDerivationTime` private
* Refactor the calculation to a private, side-effect free function
* Replace `estimatedKeyDerivationTimeMsec()` with `initEstimatedKeyDerivationTime()`
** Don’t return a value that wasn’t unused anyway
** Make better use of CompletableFuture API
* Platform.runLater wasn’t needed because no JavaFX functions are called
* Make all public fields private and wrap with accessors
* Make `WalletAppKit` (was confusingly named `bitcoin`) field a member not a static
* Rename `bitcoin` to `walletAppKit`
* Extract abstract class `WalletApplication` from `WalletTemplate`
* `WalletTemplate` implements `loadController()` with resource names
* `MainController`: Add `scene` member and `scene()` method
* Introduce `AppDelegate` class for delegating JavaFX `Application`
* Move almost all of `Main` to `WalletTemplate`
Rationale:
* The “template” JavaFX Application main class (`Main`) is now about 30 lines of code
* `Main` class allows easy switching between TestNet and MainNet (in fact it could become a command-line argument) and other configuration changes (e.g. `preferredOutputScriptType`)
* Prepares the way for the next steps of refactoring
* OverlayController: rename init method, add rootController to params
* OverlayableStackPaneController: update to use updated initOverlay() method,
also pass this.getClass() into GuiUtils.getResource()
* GuiUtils.getResource(): replace reference to MainController.class with clazz parameter
* Main: Reduce visibility to “package” of 3 static globals
* MainController: Reduce visibility of `instance` static to “package”, initialize
addressControl by calling 2 initialization methods
* 4 other controllers: Update for OverlayController changes
* ClickableBitcoinAddress: OverlayController changes, eliminate use of Main.APP_NAME
Rationale:
* Decrease coupling
* Eliminate cross-package use of `Main` and `MainController` static globals
* Prepare for further refactoring — moving wallettemplate.controls package
to org.bitcoinj.walletfx.controls
* Extract abstract class OverlayableStackPaneController from MainController
* Rename OverlayWindowController to OverlayController (Window was misleading)
Rationale:
1. Overlay functionality is independent of MainContoller’s wallet functions
2. Increases reusability of classes in module
3. Prepares for further refactoring
Rationale:
1. Stronger typing makes code more readable and refactorable
2. Eliminates “automatic” reflection in MainController
3. Makes overlayUI field in implementing classes private
4. Is a step towards further refactoring and reusability
Move OverlayUI and other related functionality from Main (Application) class
to MainController.
Motivation:
1. This simplifies the Main class
2. The code more logically belongs in the controller
3. The code being in the controller increases reusability
4. Is a first step towards additional refactoring made possible
because MainController can subclass an abstract class and Main
can’t because it must subclass Application
I did this for two reasons:
1. So users will know why the buttons are there and that they work
2. A convenient way to test the informational alert function.
Coin selection is a per SendRequest, per createSend() or per getBalance() call affair.
Having it wallet-global can lead to race conditions, as sometimes experienced in the
WalletTest unit tests.
This allows usage in both wallettemplate and tools and replaces
similar code in BlockFileLoader.java in core.
Requires minor back-port of Path.of() functionality from JDK11.
Previously WalletTemplate would store the .spvchain and .wallet files
in the app’s current working directory which could vary depending upon
how the app was launched.
This PR stores the app’s data files in the “app data directory” which
is always named “WalletTemplate” (APP_NAME) and located in the standard
location for application data directories on the current OS platform.
For macOS: `~/Library/Application Support/WalletTemplate`
For Linux/unix: `~/.WalletTemplate`
For Windows: ${APPDATA}/WalletTemplate (where APPDATA is a standard
Windows environment variable)
Changes:
* Added AppDataDirectory class to return current dir Path
* Modified Main to use appDataDirectory rather than “.”
- Hierarchical-deterministic derivation of native segwit addresses.
- Receive payments to native segwit addresses.
- Spend and sign payments from native segwit addresses.
- Watch-only wallets with native segwit addresses (zpub/vpub).
- WalletAppKit, Wallet-tool and Wallet-template are taught to deal with segwit-enabled wallets.
Be aware this adds a new field in the wallet protobuf: output_script_type in Key, which keeps track
of the script type of DeterministicKeyChains. Protobufs will be migrated; old DeterministicKeyChains
are assumed to be of type P2PKH.
Includes some code by Fabrice Drouin.
