instead, schedule a queued finished signal to unregister the listener after the handler has finished.
See PythonActivity.java in P4A for why this probably causes the most often occurring crash we see on the Play Store:
```
Exception java.lang.RuntimeException:
at android.app.ActivityThread.deliverResults (ActivityThread.java:5164)
at android.app.ActivityThread.handleSendResult (ActivityThread.java:5205)
at android.app.servertransaction.ActivityResultItem.execute (ActivityResultItem.java:51)
at android.app.servertransaction.TransactionExecutor.executeCallbacks (TransactionExecutor.java:135)
at android.app.servertransaction.TransactionExecutor.execute (TransactionExecutor.java:95)
at android.app.ActivityThread$H.handleMessage (ActivityThread.java:2136)
at android.os.Handler.dispatchMessage (Handler.java:106)
at android.os.Looper.loop (Looper.java:236)
at android.app.ActivityThread.main (ActivityThread.java:8061)
at java.lang.reflect.Method.invoke
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:656)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:967)
Caused by java.util.ConcurrentModificationException:
at java.util.ArrayList$Itr.next (ArrayList.java:860)
at org.kivy.android.PythonActivity.onActivityResult (PythonActivity.java:218)
at android.app.Activity.dispatchActivityResult (Activity.java:8501)
at android.app.ActivityThread.deliverResults (ActivityThread.java:5157)
```
The low-S rule for ecdsa signatures is mandated by Bitcoin Core policy/standardness (though not by consensus). If we get signatures from untrusted sources, we should mandate they obey the policy rules. (e.g. from LN peers)
Note that we normalize the signatures in the sig format conversion methods (DER <-> (r,s) <-> sig64).
The BOLTs treat high-S signatures as invalid, and this changes our behaviour to that.
(previously we would silently normalize the S value)
see https://github.com/bitcoin/bitcoin/pull/6769
see https://github.com/lightning/bolts/pull/807
get_preimage_script should really have been private API...
looks like everywhere it is used outside of transaction.py, it is actually abused :/
Other existing usages in plugin code I don't dare to touch without lots of manual testing...
In fact, semantically it might be more correct to only trigger 'blockchain_updated' and not 'network_updated' here...
Anyway, 'blockchain_updated' should be triggered whenever the Blockchain object gets longer (or changes otherwise).
In particular, in qml, the NetworkOverview only updates the displayed height on 'blockchain_updated'.
Values for exponential search are based on available fee budget:
we try with budget/64, budget/32, ..., budget/1 (spread uniformly among the selected Trampoline Forwarders).
Hence, if we make the fee budget configurable, that will usefully affect the trampoline fees as well.
related https://github.com/spesmilo/electrum/issues/9033
Instead of some functions operating with hex strings,
and others using bytes, this consolidates most things to use bytes.
This mainly focuses on bitcoin.py and transaction.py,
and then adapts the API usages in other files.
Notably,
- scripts,
- pubkeys,
- signatures
should be bytes in almost all places now.
This avoids some false negatives for is_proxy_tor.
(previously we only set is_proxy_tor when the proxy settings were changed)
In particular, consider scenario:
- Tor browser not running
- user sets "localhost:9150" as proxy
- detection sets network.is_proxy_tor to False
- user starts Tor browser
- network, due to retries, finds proxy working and connects to some servers
- network.is_proxy_tor remains False
SomberNight
ThomasV
jinjiadu
Sander van Grieken
Ondřej Vejpustek
hugehope
goodmost