This is a simplified re-do of closed pull #3088.
This patch eliminates the privacy and reliability problematic use
of centralized web services for discovering the node's addresses
for advertisement.
The Bitcoin protocol already allows your peers to tell you what
IP they think you have, but this data isn't trustworthy since
they could lie. So the challenge is using it without creating a
DOS vector.
To accomplish this we adopt an approach similar to the one used
by P2Pool: If we're announcing and don't have a better address
discovered (e.g. via UPNP) or configured we just announce to
each peer the address that peer told us. Since peers could
already replace, forge, or drop our address messages this cannot
create a new vulnerability... but if even one of our peers is
giving us a good address we'll eventually make a useful
advertisement.
We also may randomly use the peer-provided address for the
daily rebroadcast even if we otherwise have a seemingly routable
address, just in case we've been misconfigured (e.g. by UPNP).
To avoid privacy problems, we only do these things if discovery
is enabled.
CCryptoKeyStore::Unlock has a loop to attempt decrypting each key which
only executes once, likely due to a simple mistake when the code was
originally written.
This patch fixes the behavior by making it check all keys. It also adds
a fatal assertion in the case some decrypt but some do not, since that
indicates that the wallet is in some kind of really bad state.
This may make unlocking noticeably slower on wallets with many keys.
This removes some inconsistencies in what worked and didn't work in
safemode. Now only RPCs involved in getting balances or sending
funds are disabled.
Previously you could mine but not submit blocks— but we may need more
blocks to resolve a fork that triggered safe mode in the first place,
and the non-submission was not reliable since some miners submit
blocks via multiple means. There were also a number of random commands
disabled that had nothing to do with the blockchain like verifymessage.
Thanks to earlz for pointing out that there were some moderately cheap
ways to maliciously trigger safe mode, which brought attention to
the fact that safemode wasn't used in a very intelligent way.
When we are over our outbound limit ThreadSocketHandler would try to
keep the connection if the peer was addnoded.
This didn't actually work for two reasons: It didn't actually run
the accept code due to mistaken code flow, and because we have a
limited number of outbound semaphores it couldn't actually use the
connection.
Instead it leaked the socket, which might have caused issue #4034.
This patch just takes out the non-functioning white-listing for now.
This shows the minimum relay fee for non-free transactions in btc/kb.
The armory developers requested this so that they can prevent users from
creating transactions that not even their local bitcoind will relay.
This also slightly reorders the getinfo output so that the fee related
lines are grouped and changes the help text to reflect that the units
are btc/kb.
Commit be066fad accidentally removed the hex field.
This gets in the way of doing offline signing.
(credit belongs to sipa for actually looking for the
cause instead of being lazy like me and just shrugging
and writing the scriptpubkey from the asm.)
There were quite a few places where assert() was used with side effects,
making operation with NDEBUG non-functional. This commit fixes all the
cases I know about, but also adds an #error on NDEBUG because the code
is untested without assertions and may still have vulnerabilities if
used without assert.
Seems like there are a lot of advertised testnet HS nodes that
don't actually work. Lack of the testnet port on the example
HS config might be one reason.
This changes the priority calculation to not include the size of per-txin
data including up to 110 bytes of scriptsig so that transactions which
sweep up extra UTXO don't lose priority relative to ones that don't.
I'd toyed with some other variations, but it seems like any formulation
which results in an incentive stronger than making them not count will
sometimes create incentives to add extra outputs so that you have
extra inputs to consume later. The maximum credit is limited so that
users don't lose the disincentive to stuff random data in their
transactions, the limit of 110 is based on the size of a P2SH
redemption with a compressed public key.
This shouldn't need a staged deployment because the priority is not
used as a relay criteria, only a mining criteria.
As we'd previously learned, OSX's fsync is a data eating lie.
Since 0.8.4 we're still getting some reports of disk corruption on
OSX but now all of it looks like the block files have gotten out of
sync with the database. It turns out that we were still using fsync()
on the block files, so this isn't surprising.
This also makes negative transaction versions non-standard.
This avoids an issue triggered in block 256818 where transactions with
negative version numbers were incorrectly serialized into the UTXO set.
On restart nodes detect the inconsistency and refuse to start so long as
a block with these transactions is inside the self-consistency check
window, logging "coin database inconsistencies found". The software
recommends reindexing, but reindexing does not correct the problem.
This should be fixed by changing the chainstate serialization, but
working around it seems harmless for now because the version is not
used by any network rule currently.
A patch free workaround is to start with -checklevel=2 which skips
the consistency checks, but the IsStandard change is important for
miners in order to protect unpatched nodes.
I've seen users confused multiple times thinking they
should be using -tor to set their tor proxy and then
finding in horror that they were still connecting to
the IPv4 internet.
Even Jeff guesses wrong about what the knob does, so
I think we should rename it. This leaves the old
knob working, we can pull it out completely in a
later release.
There have been several incidents where mainnet experimentation with
raw transactions resulted in insane fees. This is hard to prevent
in the raw transaction api because the inputs may not be known.
Since sending doesn't work if the inputs aren't known, we can catch
it there.
This rejects fees > than 10000 * nMinRelayTxFee or 1 BTC with the
defaults and can be overridden with a bool at the rpc.
We're not seeing large reorgs that would justify waiting a large
amount past the rule required maturity, and the extra three
hours is just a nuisance. Take one more block to at least give
the 100th block time to propagate.
With an encrypted wallet the GUI was prompting for a passphrase every time
the user requested a new address. This is unnecessary, increases the
exposure to keyboard sniffers, and discourages using fresh addresses for
every transaction.
Instead only prompt for a passphrase when the keypool runs out, also call
the new address function with the flag that prevents reuse.
Thanks to AlexNagy on IRC for pointing this out and who wouldn't take any
lip from a curmudgeonly developer and insisted on what he knew to be true.
This reduces a peer's ability to attack network resources by
using a full bloom filter, but without reducing the usability
of bloom filters. It sets a default match everything filter
for peers and it generalizes a prior optimization to
cover more cases.
This fixes test_bitcoin failures on openbsd reported by dhill on IRC.
On some systems rand() is a simple LCG over 2^31 and so it produces
an even-odd sequence. ApproximateBestSubset was only using the least
significant bit and so every run of the iterative solver would be the
same for some inputs, resulting in some pretty dumb decisions.
Using something other than the least significant bit would paper over
the issue but who knows what other way a system's rand() might get us
here. Instead we use an internal RNG with a period of something like
2^60 which is well behaved. This also makes it possible to make the
selection deterministic for the tests, if we wanted to implement that.
If the user was really after the fastest possible confirmation times
they would be manually setting a fee. In cases where the wallet builds
a transaction with a priority that is too low to qualify as free until
the next block, go ahead without a fee. Confirmation frequently takes
multiple blocks even when a minimum fee is provided.
This avoids a potential crash when trying to read the scrippubkeys on
transactions where the first input IsMine but some of the rest are not
when running listaddressgroupings.
CreateNewBlock was reading pindexBest at the start before taking the lock
so it was possible to have the the block content not match the prevheader
and this can also trigger a newly added assert in ConnectBlock.
I noticed this during a code review after twobitcoins reported that ab91bf39
(BIP30 for all blocks) could cause a null dereference on a modified node
that mined during the IBD, or on testnet when it reached heights 91842 and
91880 due to CreateNewBlock calling ConnectBlock with pindex->phashBlock NULL.
Matt pointed out some time ago that there existed a minor DOS
attack where a node in its initial block download could be wedged
by an overwrite attack in a fork created between checkpoints before
a time where BIP30 was enforced. Now that the BIP30 timestamp
is irreversibly past the check can be more aggressive and apply to
all blocks except the two historic violations.
If our IRC nick is in use (because some other node thinks it has
the same address we think we have) don't fruitlessly try to reconnect
using that name forever. After three tries, give up and use a random
nick. Either we'll learn a new local address from IRC and switch
to that, or it was right and the other guy is advertising for us.
This avoids a pessimal case where a second testnet node behind
a nat is unable to get any peers because he can't get on IRC.
Previously Bitcoin would refuse to use IRC if it was either not
accepting inbound connections or not making outbound. Instead this
changes it to not use IRC only if it's not doing either or if
IPv4 is off completely. If Bitcoin is not listening this will use
the default random nicks rather than the IP based ones.
This applies on top of the coincontrol listaddressgroupings patch
and makes finding eligible outputs from the groups returned
by listaddressgroupings possible.
Signrawtransaction rpc was crashing when some inputs were unknown,
and even with that fixed was failing to handle all the known inputs
if there were unknown inputs in front of them. This commit instead
attempts to fetch inputs one at a time.
The new bytes are based on "11" to appeal to Gavin's 11 fetish.
This breaks existing testnet3 nodes as the blockchain files
are also versioned. To upgrade a node delete everything
except wallet.dat from your .bitcoin/testnet3 folder.
Because new nodes pull from the first connected node the load
balancing of the first connection is more important than it should
be. This change puts Pieter's seed first, because its probably
the best maintained right now.
Bitcoin will not make an outbound connection to a network group
(/16 for IPv4) that it is already connected to. This means that
if an attacker wants good odds of capturing all a nodes outbound
connections he must have hosts on a a large number of distinct
groups.
Previously both inbound and outbound connections were used to
feed this exclusion. The use of inbound connections, which can be
controlled by the attacker, actually has the potential of making
sibyl attacks _easier_: An attacker can start up hosts in groups
which house many honest nodes and make outbound connections to
the victim to exclude big swaths of honest nodes. Because the
attacker chooses to make the outbound connection he can always
beat out honest nodes for the consumption of inbound slots.
At _best_ the old behavior increases attacker costs by a single
group (e.g. one distinct group to use to fill up all your inbound
slots), but at worst it allows the attacker to select whole
networks you won't connect to.
This commit makes the nodes use only outbound links to exclude
network groups for outbound connections. Fancier things could
be done, like weaker exclusion for inbound groups... but
simplicity is good and I don't believe more complexity is
currently needed.
Gregory Maxwell