from travis logs:
--- Logging error ---
Traceback (most recent call last):
File "/opt/python/3.7.6/lib/python3.7/logging/__init__.py", line 1028, in emit
stream.write(msg + self.terminator)
ValueError: I/O operation on closed file.
Call stack:
File "/opt/python/3.7.6/lib/python3.7/threading.py", line 890, in _bootstrap
self._bootstrap_inner()
File "/opt/python/3.7.6/lib/python3.7/threading.py", line 926, in _bootstrap_inner
self.run()
File "/home/travis/build/spesmilo/electrum/electrum/plugin.py", line 213, in run
self.run_jobs()
File "/home/travis/build/spesmilo/electrum/electrum/util.py", line 359, in on_stop
self.logger.info("stopped")
Message: 'stopped'
follow-up to https://github.com/spesmilo/electrum/commit/4346d2fc765f40a9388108c06cf1ee132d663923
It's not just about the Synchronizer, the Verifier should not starve other jobs either...
(previously I thought the Verifier is not too important as it only makes
requests if there are new txs; however with LNWatcher its progress is not persisted)
e.g. consider:
>>> 1.5 * 2 ** 2000
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
OverflowError: int too large to convert to float
some basic sanity checks
Previously if the server sent back a malformed response, it could partially corrupt a wallet file.
(as sometimes the response would get persisted, and issues would only arise later when the values were used)
Before this, we were subscribing to our addresses in their bip32 order,
leaking this information to servers. While this leak seems mostly harmless,
it is trivial to fix.
...\electrum\electrum\util.py:1096: DeprecationWarning: SocksConnector is deprecated. Use ProxyConnector instead.
connector = SocksConnector(
...\Python38\site-packages\aiohttp_socks\proxy\socks5_proxy.py:37: DeprecationWarning: Parameter family is deprecated and will be ignored.
super().__init__(
- add 'computing route' status for lightning payments
- use separate callbacks for invoice status and payment popups
- show payment error and payment logs in kivy
Internally, we've been using an expiration of 0 to mean "never expires".
For LN invoices, BOLT-11 does not specify what an expiration of 0 means.
Other clients seem to treat it as "0 seconds" (i.e. already expired).
This means there is no way to create a BOLT-11 invoice that "never" expires.
For LN invoices,
- we now treat an expiration of 0, , as "0 seconds",
- when creating an invoice, if the user selected never, we will put 100 years as expiration
bitromortac