-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
This message is to inform you that I, Paul Rabahy have rolled over GPG
keys.
My old key = EA695E0CE2D0DCB0D65167A8D1CBA2A21BCD88F6
My new key = D62A803E27E7F43486035ADBBCD04D8E9CCCAC2A
My new key now has an offline primary key with an online subkey that I
will be
using for normal communications.
I have signed this message with both the old and new key so it should show
up
as validly signed. Please add my new key to your keyring so that future
communication will be properly verified.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJWB3/LAAoJENHLoqIbzYj2LBwQAMgH5u2KDuxK2gmpRjEpVXe8
XPOon+SRL5zXfu1dFInXCg8APJEVaXhSeY+/s0GmUq0INRpK4r0tvZVN84X2UoHz
y88P6BeHzQI7dsCStINhW4Hb7DVpFvkHAxsRhy05/geD56/IOXnsG+5SvsH3essJ
O6DuRQOipDWkZ9NQuQPrqzlkcBErMbL4Cs0ED5DOOYccntnt5HM909KDHfKcG8iJ
/qNTVzVFYMGbLn6MVq89reatmIOxuVBkbixsqad5M4P9rQ3iGPnUzIEp4wn7/Ssd
XDiCZypzlHkcs1GKBLtWnYWahlWHItcd/Yz3AiHLfUehcZb52p0mvIaTf4lyAR5p
kQFTXZwrrzJDaomSE2Y2IeMIATZE7/7RInkHD6okUTFSoCFgxOeAxLBI6sxLH5x5
xLIdv45iiv3P5fz1gungfzn2OYy+dHgT74bJ32N18hs+xwZM2G6AYYvVvkTSDqC0
c3AopnjEV4i+4Aq0QfDD9fXpBc0QuDN7c5GkcFCiFlhN+gffjT8hkFliiW3e2X5K
Vsycv1sYXFSS/YYZ7RCixWgTkpi18ABaLu/N1ses7hLNMxx9ovjrMIJ5gC6Nyga9
2BiumvNMh0iE9yhPiN0a4YsZZnW/tc5K1+OJxnKZvxWrXqOgIhnKZA1U1Y83COgA
6pI5uKrggGQWgQFJxTmciQEcBAEBCAAGBQJWB3/LAAoJEDJeXsBcJ6amLBwH/ib+
wiD3wDy+VeTDFvh4AgQqDRCk+CvGEKJlcoBLm3ZDwzi+/26XB/BCFoopW9h67ZmC
yMFhgvCJ3RwPcVGgZBOZ//88E2symcYRBSZJVwMN/n3McmEKBmmEH6/tTqhLeBal
2pynse7qgfZV7P/rSMcqFdhzMYq6Jt25obTl3IqTo939G1oOxRK8ORNT3Hs4/uiF
7xsx+nUBe/L6dvw2Rxr8bWm7WKi/LF7fKN/HZuBfK2qH0S4ctG49fiBw3DTV+erO
lYHdOMA9sjk90Le5sNBw75Hyr4WMLUkGFkh9SvDK1Xe3bUCfCpBTpcPnRUqnHL32
9GbqORFiaUGPRCnaWKQ=
=JR4m
-----END PGP SIGNATURE-----
4e2efb3 tests: update transaction_tests for new dust threshold (Wladimir J. van der Laan)
28e3249 Bump minrelaytxfee default (Wladimir J. van der Laan)
Common sentiment is that the miniupnpc codebase likely contains further
vulnerabilities.
I'd prefer to get rid of the dependency completely, but a compromise for
now is to at least disable it by default.
To bridge the time until a dynamic method for determining this fee is
merged.
This is especially aimed at the stable releases (0.10, 0.11) because
full mempool limiting, as will be in 0.12, is too invasive and risky to
backport.
This version of miniupnpc fixes a buffer overflow in the XML (ugh)
parser during initial network discovery.
http://talosintel.com/reports/TALOS-2015-0035/
The commit fixing the vulnerability is:
79cca974a4
Reported by timothy on IRC.
1534d9a Creates unittests for addrman, makes addrman testable. Adds several unittests for addrman to verify it works as expected. Makes small modifications to addrman to allow deterministic and targeted tests. (EthanHeilman)
Adds an `obfuscate` parameter to `CLevelDBWrapper` and makes use of it
for all new chainstate stores built via `CCoinsViewDB`. Also adds an
`Xor` method to `CDataStream`.
Thanks to @sipa @laanwj @pstratem @dexX7 @KyrosKrane @gmaxwell.
This adds SCRIPT_VERIFY_LOW_S to STANDARD_SCRIPT_VERIFY_FLAGS which
will make the node require the canonical 'low-s' encoding for
ECDSA signatures when relaying or mining.
Consensus behavior is unchanged.
The rational is explained in a81cd96805:
Absent this kind of test ECDSA is not a strong signature as given
a valid signature {r, s} both that value and {r, -s mod n} are valid.
These two encodings have different hashes allowing third parties a
vector to change users txids. These attacks are avoided by picking
a particular form as canonical and rejecting the other form(s); in
the of the LOW_S rule, the smaller of the two possible S values is
used.
If widely deployed this change would eliminate the last remaining
known vector for nuisance malleability on boring SIGHASH_ALL
p2pkh transactions. On the down-side it will block most
transactions made by sufficiently out of date software.
Unlike the other avenues to change txids on boring transactions this
one was randomly violated by all deployed bitcoin software prior to
its discovery. So, while other malleability vectors where made
non-standard as soon as they were discovered, this one has remained
permitted. Even BIP62 did not propose applying this rule to
old version transactions, but conforming implementations have become
much more common since BIP62 was initially written.
Bitcoin Core has produced compatible signatures since a28fb70e in
September 2013, but this didn't make it into a release until 0.9
in March 2014; Bitcoinj has done so for a similar span of time.
Bitcoinjs and electrum have been more recently updated.
This does not replace the need for BIP62 or similar, as miners can
still cooperate to break transactions. Nor does it replace the
need for wallet software to handle malleability sanely[1]. This
only eliminates the cheap and irritating DOS attack.
[1] On the Malleability of Bitcoin Transactions
Marcin Andrychowicz, Stefan Dziembowski, Daniel Malinowski, Łukasz Mazurek
http://fc15.ifca.ai/preproceedings/bitcoin/paper_9.pdf
