It could just as well be on either part of the gitian build, but to safely put it on the Qt side would require bumping the filename, and every gitian user rebuilding it.
v0.5.3.1 put it on the Bitcoin side, and this is easier to work with and keep safe, so I'm moving it.
Use `qmake MINGW_THREAD_BUGFIX=0` to disable
Sometimes a new block arrives in a new chain that was already the
best valid one, but wasn't marked that way. This happens for example
when network rules change to recover after a fork.
In this case, it is not necessary to do the entire reorganisation
inside a single db commit. These can become huge, and exceed the
objects/lockers limits in bdb. This patch limits the blocks the
actual reorganisation is applied to, and adds the next blocks
afterwards in separate db transactions.
2^31 milliseconds is only about 25 days. Also clamps Sleep() to 10 years,
because it currently sleeps for 0 seconds when the sleep time would cross
2^31 seconds since the epoch. Hopefully boost will be fixed by 2028.
Introduce the following network rule:
* a block is not valid if it contains a transaction whose hash
already exists in the block chain, unless all that transaction's
outputs were already spent before said block.
Warning: this is effectively a network rule change, with potential
risk for forking the block chain. Leaving this unfixed carries the
same risk however, for attackers that can cause a reorganisation
in part of the network.
Thanks to Russell O'Connor and Ben Reeves.
Before 0.6 addrProxy was a CAddress, but netbase changed it to CService.
Retain compatibility by wrapping/unwrapping with a CAddress when saving
or loading.
This commit retains compatibility with 0.6.0rc1 (which wrote the setting
as a CService) by trying to parse twice.
Doing so would allow an attack on old nodes, which would relay a
standard transaction spending a BIP16 output in an invalid way,
until reaching a new node, which will disconnect their peer.
Reported by makomk on IRC.
- Add "size" and "bits"
- Rename "blockcount" to "height"
- Rename "hashprevious" and "hashnext" to "previousblockhash" and "nextblockhash" (respectively)
