We are now using change addresses for the channel SRK to_remote outputs
(and reserving these change addresses). (see prev commits)
Note that every channel open we initiate typically uses two change addresses:
- one for the SRK to_remote output, and
- one for the funding tx change output (assuming there is change).
- Use change addresses (instead of receive) for the static_remotekey to_remote outputs,
and reserve these to greatly reduce the chance of address-reuse
- Use change addresses (instead of receive) for LN channel sweep addresses.
Note that these atm are not getting reserved.
- also, disallow deleting last address from an imported wallet (fixes#3254, fixes#4833)
- also, set LNBackups.sweep_address lazily, as during fresh wallet creation
there are no addresses in the wallet at that point yet! see trace below.
Traceback (most recent call last):
[...]
File "...\electrum\electrum\tests\test_commands.py", line 112, in test_export_private_key_deterministic
wallet = restore_wallet_from_text('bitter grass shiver impose acquire brush forget axis eager alone wine silver',
File "...\electrum\electrum\wallet.py", line 2575, in restore_wallet_from_text
wallet = Wallet(db, storage, config=config)
File "...\electrum\electrum\wallet.py", line 2502, in __new__
wallet = WalletClass(db, storage, config=config)
File "...\electrum\electrum\wallet.py", line 2346, in __init__
Deterministic_Wallet.__init__(self, db, storage, config=config)
File "...\electrum\electrum\wallet.py", line 2147, in __init__
Abstract_Wallet.__init__(self, db, storage, config=config)
File "...\electrum\electrum\wallet.py", line 261, in __init__
self.lnbackups = LNBackups(self)
File "...\electrum\electrum\lnworker.py", line 1401, in __init__
self.sweep_address = wallet.get_receiving_address()
File "...\electrum\electrum\wallet.py", line 1498, in wrapper
addr = func(self, *args, **kwargs)
File "...\electrum\electrum\wallet.py", line 1520, in get_receiving_address
raise Exception("no receiving addresses in wallet?!")
Exception: no receiving addresses in wallet?!
previously, consider following flow:
- user selects "Select server manually"
- "next"
- network dialog is shown, user leaves everything at default
- "next"
- we would not save the "auto_connect" key, and hence the first-time
network setup will be shown during the next app start again
- some commands expect a 'wallet_path' arg, while others expect 'wallet'
- 'wallet_path' in the end is supposed to be a str,
'wallet' in the end is supposed to be an Optional[Abstract_Wallet]
- initially, in the decorator, 'wallet' can be a str, in which case
the decorator replaces it with an Abstract_Wallet (from the daemon)
- Previously the decorator sometimes converted 'wallet_path' to 'wallet'.
This was because when called from the CLI it was always given 'wallet_path' (and never 'wallet),
while when called from JSON-RPC it was given either 'wallet' or 'wallet_path' (depending on command).
Now, the CLI also behaves as JSON-RPC, and hence 'wallet_path' and 'wallet' are fully separate.
- A bug is fixed where, when a command that only optionally takes a 'wallet' (such as gettransaction),
was called from the JSON-RPC with the arg present, it raised; and when called from CLI with the arg present
the arg was not actually passed to the command.
- A bug is fixed where if one command calls another command (that both take a 'wallet'),
it would raise (due to assuming 'wallet' is str and needs to be converted to Abstract_Wallet).
This fixes#6154.
-----
$ ./run_electrum --testnet daemon -d
$ ./run_electrum --testnet load_wallet -w ~/.electrum/testnet/wallets/default_wallet
$ curl --data-binary '{"id":"curltext","jsonrpc":"2.0","method":"gettransaction","params":{"txid":"9f43ff71ea2594873e4e7d15e61254a3661ff2df1af76325c854d9aa199550ce"}}' http://user:pass@127.0.0.1:7777
{"jsonrpc": "2.0", "result": "0200000001caaac6b5eb916e3067d0224f942fb331ce1dcfb4031cfb479e7941dcf95e409801000000fdfe0000483045022100e2a508bb78c2172eb03f081a342454ba1d24669e959700973b1a742a4fedd0c302203174e06feda265031cf9aa0364d4a4eafb71b0c0a62e76be7795cfbb307b677a01483045022100d0e14564838fac754395158741d64c73da2b86e7900dfdc6a63c7492b232ba130220778e7e7c21d94ebcd340057302aeff7e9a797a3aa3e0ac4884e9ff27339ea6e9014c69522102091f0b4d8ab30016a5d1c088249e02883fad8160f06fa53588ad8598650a3e6221035f2f8263bb3608d6cc4ee03bd4cb8d65c4d70af71049f05fbfee4978832a1fd22103fe42dab58718ea0413f7c8de693cdeee22ce19b1dc34c0bbdd7a48245465c5a253aefdffffff01cb9f0700000000001976a914c13fd6294d1be7b9410a5538f4b4ef10fc594ee788ac802c1800", "id": "curltext"}
$ curl --data-binary '{"id":"curltext","jsonrpc":"2.0","method":"gettransaction","params":{"txid":"9f43ff71ea2594873e4e7d15e61254a3661ff2df1af76325c854d9aa199550ce", "wallet":"~/.electrum/testnet/wallets/default_wallet"}}' http://user:pass@127.0.0.1:7777
{"jsonrpc": "2.0", "error": {"code": -32000, "message": "'str' object has no attribute 'db'"}, "id": "curltext"}
Data returned by the main server for request "server.peers.subscribe"
is of course untrusted input. Previously if it contained e.g. invalid port numbers
or IP addresses, it could kill the whole network taskgroup.
(this might have only affected master and not released versions,
which would only raise exceptions once the client actually tried to connect to an invalid host/port)
SomberNight
ThomasV
JeremyRand