Bitcoin's difficulty adjustment algorithm uses a simple average of solve times over a two-week window to estimate network hash rate. It has been demonstrated that this only works for the dominant coin of a proof-of-work system, and leads to instability when there is fierce competition with another similarly configured but not merge-mine compatible system (see: Bitcoin and Bitcoin Cash, initially; Bitcoin and Freicoin since 2013).

Freicoin hard-fork changed to a different difficulty adjustment algorithm in March of 2013 in order to partially resolve this issue. Instead of a two-week average, Freicoin switched to a 144-tap Parks-McClellan finite impulse response linear filter to extract a hash rate estimate from recent block solve times. The Freicoin algorithm worked in terms of getting past the existential crisis of a hash crash, but there is still substantial solve time variance due to the effects of majority hash power following mining profitability with respect to other coins.

With the adoption of forward blocks, we have a one-time opportunity to change the difficulty adjustment algorithm again, but this time as a soft-fork. As we are not responding to a crisis as we were in 2013, we should take the time available to investigate the options available and see if a better difficulty adjustment algorithm can be designed in order to further minimize the negative effects of multi-chain pool hoppers on interblock solve times / quality of service.

The link to "original whitepaper" in README.md ( https://freicoincore.in.freico.pdf/ ) is broken.
I could not find the paper anywhere else so it's pretty hard to get an overview of the project.

Now that the protocol-cleanup rule change has happened, we can activate CLTV and CSV for non-segwit scripts as well. This minimizes the difference between segwit and non-segwit script engines, and would make our patch set a little bit simpler.

Note: Original title was "Switch signature tie breaker to be quadratic residue instead of low-S in verification." See this comment for an explanation of the change. The below text no longer applies.

In the rebase to 0.9 we changed the signing code to only produce signatures for which the R.y value is a quadratic residue, as opposed to bitcoin's tie breaking condition of low-S. Should this become mandatory and consensus-enforced, the change would enable batch validation of ECDSA signatures. In 0.10 the "LOW_S" verification condition is added which enforces this. We should change this verification code to enforce R.y quadratic residue instead.

To support the relaxation of script limits for witness scripts, some opcode semantics need to be altered. One of these is ROLL, which has runtime costs equal to the size of the stack. If the stack has 30,000 entries, then 30000 ROLL requires moving 30000*sizeof<vector<unsigned char> > bytes around, because it deletes an item deep in the stack.

This is unacceptable and ROLL needs to go. However many of the use cases for ROLL could be accomplished, sometimes even more cheaply, with an opcode that swaps the top most stack element with the element n deep in the stack. This is constant-time behavior: no moving of intermediate bytes is required. For witness scripts, ROLL should be replaced with this "deep swap" semantics.

Presently there is one initial patch which applies the AGPLv3 sublicense to all files that later receive meaningful AGPLv3 licensed patches applied to them. The per-file copyright header changes of this patch should be split off into a separate patch for each file, to be applied immediately before the first time that file is modified. This will make reorganizations of the source code easier to deal with in a rebase.

Updates to the Qt client in v11 include a new high-resolution image for the splash screen. In bitcoin a 1024x1024 true color image is used. Unfortunately our highest resolution logo artwork is only 256x256. We need to regenerate the logo at higher resolution in order to get rid of pixilation on the splash screen.

Calling getmininginfo reports in the error field "Warning: Unknown block versions being mined! It's possible unknown rules are in effect". This warning also shows up in the debug log whenever the tip is extended. This is because bit 28 must be force-set until 2 Oct 2019, but there is no corresponding version bits entry for this bit during that timeframe. The following code is what detects and generates this warning:

It ought to be changed to cover only the range VERSIONBITS_NUM_BITS - 1 until signaling times out on 2 Oct 2019.

So far as I know this warning is purely cosmetic and does not affect node operation in any way. Nevertheless to prevent user complacency with respect to this very serious warning the bug ought to be fixed and a point release made to solve this one issue.

Thanks to Fredrick Bodin for finding and reporting this issue.

Support for ZMQ notification adds a huge attack vector. Given the frequency of bugs found upstream, it should be considered a serious network security vulnerability to have ZMQ linked to the address space of every node. Still, it is a useful feature and we should support it, so long as it is not included in builds by default. We should change the default configuration setting to no and require --enable-zmq to include it.

When we went from software floating point to integer math for demurrage calculations, the code was written to only support calculation of future value corresponding to higher reference heights. Since reference heights are monotonically increasing, this is the only calculation which freicoin as-is requires. However tradecraft will permit epoch-based values within its confidential transactions implementation, and converting between the two will require moving values from a positive refheight to the zero-refheight epoch. Therefore an inverse-demurrage integer-math function needs to be implemented.

When the integer-math demurrage was implemented, it was specifically designed to round down so that no input would result in a greater value than the more precise floating-point calculation would have provided. This was to prevent a hard-fork due to its usage in transaction fee calculation. However this restriction does not exist for conversion into and out of the confidential transactions domain, so perhaps two new functions are required, with zero bias.

Right now any mining node's debug output is chock full of share notifications, if the miner requests a low difficulty. This ends up filling the log buffer and at some point the old history gets truncated. Share notifications are only really useful when debugging miner connections, so it should only be output when -debug='stratum is set.

Right now the default wallet behavior unnecessarily leaks information about transaction creation times by using the next block height as the transaction lock height. This is not unlike the setting of nLockHeight for anti-fee-sniping, but at least that implementation introduces some randomness to increases the anonymity set.

Privacy and fungibility could be improved by either matching the lock height to the anti-fee-sniping height used, or to the maximum ref height of the inputs. In either case the change would be a bit more complex than this makes it sound as it would require adjusting the output amounts in a way that avoids truncation in round-trip conversion.

Twice the other day I was trying to figure out how many miners were connected to a node, first to see from a centralized point whether all of my miners were connected rather than checking them individually, and then at another point I wanted to see if there were lingering file handle leaks from connections left open. In both instances it would have been helpful to have an RPC which enumerates each connected StratumClient and prints some information about the connection.

The core issue hasn't been exactly diagnosed, but it is repeatable. At the time of writing, the "bitcoin" RPC compatibility mode disables activation of the block-final transaction rule. Removing this aspect of bitcoin mode and allowing the block-final rules to activate causes the 'pruning.py' RPC test suite to fail for reasons indicative of an underlying bug. It is not yet known why, but GetFinalTx() on the tip returns a 0 value instead of the expected transaction hash, making that node unable to mine blocks. Shutting it down and doing a -reindex solves the problem, but this is an internal state that should not be possible to create.

In the interest of minimizing the attack surface of the tradecraft daemon, the HTTP REST protocol added in bitcoin/0.10 should be removed. The functionality that it provides is available either from JSON-RPC or from the p2p protocol, and if a REST interface is required it should be done as a separate middleware layer that translates REST requests into JSON-RPC or p2p messages--something that would be trivially simple to implement with python-bitcoinlib and flask.

Expected: opening the DMG should display a fancy background with an arrow directing the Freicoin-Qt.app to the Applications directory shortcut.

Actual: a simple icon-view Finder window opens with just the shortcut and app icons visible in a standard view.

I think this might be due to the renaming scripts corrupting the cached .DS_Store.

The deterministic signing code for Bitcoin Core uses RFC 6979, which is an internet standard for deterministic nonce selection. It is however an excessively conservative algorithm with an unnecessary number of hashing steps, due to the author's decision to rely on existing approved primitives rather than optimize for speed:

Deterministic signatures are safe in the random oracle model. Using HMAC_DRBG allowed me to rely on existing research on the safety of that construction and how close it comes to a "true" random oracle. If I had used any other "handmade" construction, then I would have had to provide extensive analysis on why it is secure. Being naturally lazy, I chose HMAC_DRBG.

Moreover, this use of HMAC_DRBG makes the end result more "convincing" -- and a large part of specifying a cryptographic algorithm as a RFC is to get other people to use it.
(https://crypto.stackexchange.com/a/24326)

However in our use case where it would be useful to report a zero-knowledge proof that the algorithm was followed in the construction of a signature, e.g. to prove a hardware signer is not compromised, we want this algorithm to be as simple as possible to express in an arithmetic circuit. A straight hash should work, as is done by Ed25519.

A large number of RPC tests are disabled by the demurrage patch set, since default behavior involving transaction lock heights causes account balances to decay and therefore alter the conditions being checked. A simple way to restore these tests, which are valuable, is to disable demurrage on the regtest chain by default. Tests written for freicoin specifically can enable demurrage on a per-test basis.

The SI standard describes digit-separating thin spaces as an optional visual cue, but it says nothing of using thin spaces for the whole part of the number only, and no spaces for the decimal part. This is an arbitrary design decision based on aesthetics. We should conform with international standards instead: either revert the removal of thin-space digit separators for the decimal portion of amounts or remove digit-separators entirely.

Since October 2nd freicoin daemons have been reporting an unrecognized new rule has activated. This is because bit #28 was forced set as a result of a prior soft-fork until that date. The version bits warning code was also disabled, but only until this date. Now it is active and looking back, it sees successful activation as per the BIP9 rules.

Thankfully this causes no known issues, and the p2pool mining software is ignoring the warning rather than treat it as an error. But the versionbits code should be modified to ignore bit#28 signalling during this period.

I've received some email requests for bootstrapping node IPs. Upon investigation it seems that 3 of the 4 DNS seeds checked in recent versions of freicoind are down. Two of these are maintained by community members that are no longer active and should therefore be removed as the represent potential security vulnerabilities. The other downed server is my own. In getting it back up I intend to setup geographic distribution and redundant failover. This issue is to track setup of this service and any editing of the master node list that is required as a result.

For whatever reason it seems that if you stop freicoind and then start it again immediately, it's usually okay, but if you allow some time to pass (some blocks to be found), it will not start up without a reindex. It fails to process new blocks with the error "ConnectBlock: prior block-final tx hash not found; corruption likely!" Upon further investigation, the block-final tx hash is zero, which is the value returned when its record is not found in the database. This failure is only supposed to happen after activation when upgrading from a client that didn't support block-final transactions to one which does.

The interim release v0.9.5.1-5869 added a soft-fork rule that the coinbase nLockTime be set to the medium-time-past of the block containing it. This code needs to be ported to the rebase-0.10 branch before the release of 10.4, or a simpler post-activation patch if it activates before code freeze for release.

The maximum number of signature operations that can be usefully performed within the context of a single P2SH script is 20, not 15 as is assumed by the standardness rules of the bitcoin codebase. The value of 15 was calculated at the time it was introduced based on size of parameters to CHECKMULTISIG: with 33-byte public keys there is no way to have a threshold larger than k-of-15 using the CHECKMULTISIG opcode within a 520 byte redeem script. However, other constructions are possible. Using the same size-reduction technique as P2SH, a k-of-19 threshold can be supported with a script size of 518 bytes for a k-of-19 threshold:

TRUE 0 (2ROT DUP HASH160 <pubkeyhash> EQUALVERIFY CHECKSIG ADD)x19 ... k EQUALVERIFY

Alternatively, a 20-of-20 multisig (requiring all signatures) can be supported, weighing in at just 510 bytes:

(DUP HASH160 <pubkeyhash> EQUALVERIFY CHECKSIGVERIFY)x19 <pubkey> CHECKSIG

Although it would be preferable to use Schnorr multi signature schemes and key aggregation for efficiency reasons, the above thresholds are of practical use today and should be supported. Therefore, the MAX_P2SH_SIGOPS value should be 20, not 15, and the relevant unit tests updated.

There is currently a persistent error message reported to the client of "Warning: This version is obsolete, upgrade required!" This is due to the block.nVersion being set to a value > 3, which itself is due to the BIP8-like soft-fork deployment mechanism used for recent soft-forks. The older codebase is interpreting these version-bits settings as unrecognized version numbers. This code should be removed as it is in error.

From the stratum logs of public mining servers, I have noted that some people are mistakenly leaving out the chain specifier from the merge-mining configuration in the password field of a stratum connection. So instead of a stratum password of freicoin=1EpB4RDznaju35KKbQ87AsiLQMywcTUDtz, they put just 1EpB4RDznaju35KKbQ87AsiLQMywcTUDtz. That would be fine if some sort of warning were generated for the user, but we actually can't do that because of the way gracefully handle unrecognized password options. So the result is that their miner solo-mines bitcoin without even realizing that they aren't merge-mining freicoin.

Since the default behavior in the wild is to merge-mine freicoin, and since freicoin addresses look like bitcoin addresses, we should attempt to decode the password field as a CBitcoinAddress. If that works, assume the user meant it as the freicoin merge-mining address.

There's a test inside of p2p_compactblocks.py in which a block header is sent from a node supporting compact blocks to another node which supports compact blocks, and the expectation is that a request is made for a compact block transmission. However a regular block transmission is received instead.

What triggers this change in behavior is merely the addition of block-final transactions. I do not know if this is expected behavior since the announced block now has two transactions instead of one. Sending a full block instead of a compact block shouldn't cause any network consensus issues; it is just potentially wasteful if the same behavior is seen with larger blocks.

This should be investigated more thoroughly, but for now the p2p_compactblocks.py test script has been modified to accept either a compact block getdata request or a regular block getdata request at the offending line on the 16 branch in which this behavior was first observed.

(Grep for "FIXME: For some reason bitcoind" in the file to find the documented change.)

Commit 6380180 rejects non-null values for the extra popped field of CHECKMULTISIG. This was a dumb decision by bitcoin--we should instead require that this field be an (inverted?) bitmask of the public keys used, so that no guessing is required and batch validation can be used.

We don't allow stuffing the block chain with data irrelevant to block validation. Applications that are designed to use OP_RETURN data outputs should be using pay-to-contract or sign-to-contract commitments instead.

Release 0.10 of bitcoin allowed one data commitment per transaction, up to 40-bytes in length. This should be reverted in the rebase of freicoin/tradecraft to 0.10. We do not allow stuffing the chain with any amounts of arbitrary user data.

The deployment of Forward Blocks gives us a one-time opportunity to change proof-of-work functions away from the double-SHA256, non-merge-mined PoW we currently share with bitcoin. The reasons for doing so are many-fold:

1. The exclusive/non-merge-mined status of freicoin's PoW with respect to bitcoin results in a negative feedback loop that puts the freicoin price into a vicious downward spiral in response to bitcoin/freicoin price swings, which has hampered growth of an independent economy. Either adoption of merge-mining or switching to an entirely new proof-of-work would fix this.

2. Unlike in 2012 and 2013, the bitcoin mining ecosystem is presently heavily centralized. There are a few large players that together control a majority of operating mining hardware and/or access to new hardware at competitive cost. Unfortunately merged mining only makes this dynamic worse, as merge mined coins tend to be even more centralized than their parent mining ecosystem. The parent mining ecosystem constrains the level of decentralization that can be reached by a child network.

3. The extremely high efficiency of double-SHA256 ASICs over commodity hardware eliminates the option of a decentralized fallback measure--GPUs are simply too slow and too power inefficient to provide an effective fallback if the naturally centralized mining hardware market became compromised. On the other hand, some experimental projects such as ProgPoW are able to achieve small constant factor differences between an ASIC and a commodity graphics GPU, which would be sufficient to enable a decentralized mining fallback when the mining hardware supply chain has been corrupted.

This issue is to track work towards identifying a credible alternative proof-of-work that could be adopted for forward block share chains, thereby restoring some centralization resistance and decoupling the freicoin/tradecraft scrip price from bitcoin.

The v12 stratum server uses pre-generated Merkle branches to efficiently generate work for each miner regardless of block size by copying and modifying the coinbase transaction only. The placement of the witness commitment in the block-final transaction and the inclusion of both the coinbase and block-final transaction in the witness Merkle tree makes supporting stratum with segwit-aware miners a bit trickier. So as to not delay the release of v13, it was decided to merge a preliminary version which didn't attempt this optimization but instead copies the entire block each time work is generated or received. For current low transaction rates this isn't an issue, but the performance issue does need to be addressed as soon as possible.

In v12 the stratum server needed only retain the path from the coinbase to the Merkle root of the block. With v13, it needs to retain the path from the coinbase to the root of the witness Merkle tree, which is used to regenerate the witness commitment. It then needs to use the path to both the coinbase and block-final transaction (both sides of the block Merkle tree) to generate the Merkle root. A trick helps us do this last part efficiently: drop the last hash in the proof for both the coinbase and block-final transactions, as in both cases that hash is represented by the other proof. Once the block-final transaction is known, calculate the root of the truncated proof, which is the hash of the right-hand side of the tree, which is the last hash for the coinbase proof. Then use the updated coinbase hash to calculate the updated block Merkle root.

Unfortunately the existing code for manipulating proofs of Satoshi-design Merkle trees is not up to task for this. When we generate a branch proof for the block-final transaction, that proof sometimes includes the hash of the block final transaction itself, unless the number of transactions is precisely a power of 2. This is because the hash gets duplicated, and the duplicate becomes part of the proof.

New Merkle proof code needs to be written which does not include duplicated hashes, but instead uses knowledge of the total number of objects and the position to do the duplication at verification time. This new Merkle tree code can then be used to implement efficient work generation and verification for segwit-aware stratum mining services.

GetRandBytes currently (in bitcoin/0.10) returns an error code indicating whether random bytes were actually generated. This error code should currently be checked in all the places GetRandBytes is called, but GetRandBytes should just error out the entire program if this fails given the disastrous security implications of failing to get random data and continuing operation. See bitcoin PR #4400.

This volume name is "Freicoin-Core." It should be just "Freicoin."

This could be related to #31 .

As part of adding inner witness versions and MAST proofs to our implementation of segwit, there is no longer a relationship between the segwit script hash and the 20-byte P2SH script hash, as there is with bitcoin. As a consequence, the wallet now maintains a separate database of witness scripts, so it is possible that a wallet will recognize some P2SH outputs as its own, but not their P2WSH counterparts, or vice versa. When a bitcoin user adds a redeem script to their wallet the segwit version of that script is automatically known, but in our implementation the witness script needs to be registered for the witness version to be recognized.

Right now, what's implemented is the minimum behavior necessary to satisfy unit and functional tests, with the smallest diff from bitcoin's implementation. Segwit scripts are not automatically registered when new keys are generated, nor does adding a script automatically add the segwit version. Also, weirdly, registering a 1... address as a witness script registers both the P2WPKH and P2WSH-wrapped P2PKH scripts... but that's an oddity that bitcoin does as well, so for now we leave it in.

This issue is to track the task of investigating the registration with witness redeem scripts, implicitly or explicitly, and to make changes necessary for the RPC API to have the right balance of ease of use and future maintainability.

I've noticed that when launching the Qt client on macOS, the old "interlocked-F" design by Aaron Blumenshine briefly shows up as the icon of the application on the launch bar for about a second, before being replaced by the new Arctic Tern design.

Obviously we still have the old logo persisting around somewhere in the branding patches, and it needs to be found and replaced with the new logo to prevent this issue on startup.

Forward Blocks may not be necessary to change proof-of-work in a soft-fork way on Tradecraft. As a result, perhaps we should replace bitcoin-competitive solo dSHA256 with bitcoin-compatible merge-mined dSHA256 as the proof-of-work in the near term, prior to the deployment of full forward blocks? This suggested improvement comes with trade-offs, and would need the acceptance of the entire Tradecraft community.

The invention of Forward Blocks happened as a result of musing over how to change Freicoin/Tradecraft's proof-of-work function as a soft-fork. The notion of forward blocks (as specified in the proposal) and the compatibility chain achieves this goal in the general sense. However it has come to my attention that it might be possible to use a simpler construction just to change the proof-of-work that does not require any of the forward blocks development effort. This only really works on Tradecraft because of our unique situation of our PoW competing with an economically larger chain (bitcoin) and the details of our difficulty adjustment algorithm.

The construct is this: require valid, merge mined PoW headers for block templates. Then when mining the assembled block, all that can change is the nonce, extranonce, a few version bits (for AsicBoost), the difficulty bits, coinbase string field, etc. A copy of these for merge mined validation is placed in a miner-generated commitment.

This is not a new idea. It was in fact the starting off point for development of forward blocks, which fixes the issues this approach has to changing the proof-of-work. The main issue is: proof-of-work is no longer progress-free. You have to first find a block using merged mining, and then find a block using the native proof-of-work (or vice-versa). This greatly magnifies the effectiveness of block withholding / selfish-mining, and can have a huge centralizing effect. However the problem would mostly go away if the difficulty of the original PoW could be dropped to a trivial range... which describes Freicoin presently. And thanks to how our difficulty adjustment algorithm works, it can be clamped to that range as well.

It's possible to bias the difficulty adjustment filter to make the adjustment algorithm think the hashrate is continuously dropping by a small amount. Since with the added secondary proof of work would be driving the block rate independent of the original difficulty, the original difficulty will drop slowly over time until it reaches a truly trivial range (e.g. 1 to 256) and the bias is no longer enforced. A block of that difficulty can be found by an ASIC miner or the mining pool sub-second time.

To implement this, the consensus code changes to Tradecraft to support merged mining are actually quite trivial. Although not required, it would be a good opportunity to test and deploy a new difficulty adjustment algorithm (see #3) and see how it works in production before we have a chance to change it again with Forward Blocks. Getting this to work with bitcoin mining pools would be a bit more complicated, but a basic implementation would work for initial deployment.

If this were adopted by even a small bitcoin mining pool, it would mean that solo mining is out of reach for all of the existing miners on the Tradecraft network. It is therefore absolutely essential that the ramifications of this are explained well, and the proposal have near-unanimous consensus of the entire community. I would suggest a 95% activation threshold, with cancellation on timeout, and have signalling for it NOT be the default.

There has been some changes and additions to the freicoin/0.9 development branch as issues were discovered. These changes should be cleaned up, re-ordered, and squashed in preparation of the rebase to 0.10.

Unlike bitcoin, achieving scalability with forward blocks on tradecraft will require an eventual hard-fork. Thankfully however, forward blocks presents the ideal opportunity for deploying such a thing, as there is a consensus-visible trigger for real demand causing larger shards to create a backlog requiring bigger compatibility chain blocks to clear. However while forward blocks is still being written, every version of freicoin/tradecraft that does not support detection of and acting on this eventual hard-fork is a version that will be incompatible with the trigger of larger compatibility blocks.

Therefore, the responsible thing to do is to deploy the hard-fork in this and future releases of freicoin/tradecraft, to be triggered on a suitably distant date years into the future. Later releases will either push back this date extending the block size rules for additional time (which would be a soft-fork), or implement the real demand-driven detection and switchover logic.

As to the contents of this hard-fork, it will remove most aggregate limits other than block-size, since they become less relevant with the performance enhancements that come with enhancements pulled from upstream, and perform various other navel-gazing fixes. Most critically though it should bump up the maximum block size to the largest value the software is able to support (my guess: 32MB, which would be 128MWe, which means the largest post-segwit block would still fit in a single 128MB blkxxxx.dat file), and completely remove constraints on block difficulty.

Of course the actual fork will be far more constrained, using a flexible cap to slowly ramp up aggregate limits, and with a new, more responsive difficulty adjustment filter. But by simply removing limits or bumping them to the maximum possible after a time-based activation date, these older, pre-forward-blocks clients will still understand the compatibility blocks that are relayed to them, even though they don't know to enforce the more restrictive validation rules.

We should acquire a developer signing keys from Apple for the gitian-built official releases of tradecraft and freicoin, and update the gitian build process to incorporate these signatures.

The registered organization "Community Forge" is owed coins from the foundation-sponsored donation matching campaign:

  Donation:	1,996.60765506
  Matched: 	3,993.21531012
  Payout:  	1,096.20734614
  Todo:    	2,897.00796398

The point of contact for the organization needs to be tracked down and a current address received, so that the outstanding balance of 2,897.00796398 in donations + matching can be delivered.

When a block is found, new work is immediately sent to the node that found it, and then the block notification thread also sends new work to all connected nodes. This results in a new block template being sent to the same miner twice.

Release 0.10 of bitcoin added the CHECKLOCKTIMEVERIFY opcode, which checks that the enclosing transaction's absolute lock time requirement is at least the specified value. This opcode is useful and we will be adding in the updated version of script to be deployed with segwit, but adding it pre-segwit with the semantics that bitcoin has prevents using the opcode as a forward block shard identifier.

Additionally, I recall that there were a few things we'd want to do differently with CHECKLOCKTIMEVERIFY, including making minimal encodings a consensus requirement (which was an oversight in bitcoin) and dropping the inputs (which can only be done with a segwit script deployment). These should ideally be fixed now so that the implementation reflects the intended future semantics of the opcode, even if the opcode won't be activated for many releases.

The bitcoin and elements scripting languages contain some opcodes which evolve program state in ways dependent on the entire execution environment rather than just local parameters. These opcodes which present special challenges to any overlaid type system are:

RETURN: as originally defined, terminated execution and returned the top-most value on the stack. Any code fragment which contained a RETURN opcode potentially had non-functional effects not reflected in its type signature, as it would end termination if the RETURN was executed. The RETURN opcode has since been removed and any script containing it made invalid, but nevertheless it was once part of the bitcoin scripting language and has analogues in other Forth derived languages. It would be wise to review the literature surrounding concatenate languages and see if there are any constructs or compilation architectures for which a RETURN-like opcode makes sense, and how these exceptional termination conditions are handled by type systems, if at all.

DEPTH pushes the current size (in elements) of the stack. It is particularly useful in real world scripts as a way of conditioning based on the number of parameters provided in the witness, as well as other space saving optimizations. However it has the distinct drawback that its output, the value pushed on the stack, is not a function of its inputs, at least not in a way that is easily expressible or useful in practical type systems. Code using DEPTH is therefore difficult to reason about based on type signatures alone. Future script versions should probably have DEPTH removed for ease of analysis, but before doing so we should survey the literature to make sure that the opcode is in fact merely a non-vital optimization, and not e.g. an essential part of some compiler architectures or idiomatic Forth code. If it is to be kept, some way of reconciling its behavior with the type system needs to be found.

IFDUP duplicates the top-most stack item, but only if it evaluates as false. The type signature of this operation is thus data-dependent and from a type analysis perspective it leaves the stack in an indeterminate state.

The following line causes the daemon to enter initial-block-download state if the chain tip is older than nMaxTipAge, which is currently hard coded to 1 day.

This is generally good advice and should be the default, but unfortunately miners running this code will have their mining APIs turn off as soon as one day goes by without finding a block. And unfortunately this is a common occurrence on Tradecraft, where there is still large difficulty and hashrate swings. The last few times this happened basically the whole network shut down, until someone found a block--a chicken-and-the-egg problem.

Some mining pools are currently running with this check disabled in custom-build binaries. But there should be a configuration file setting that either configures this check or disables it entirely, to be used by mining pools who know what they are doing.

Bitcoin v0.12 introduces "opt-in" replace-by-fee semantics. This was an unfortunate political compromise as a result of situational context we are fortunate not to have to deal with. There is no such thing as optionality to RBF because there is no way to prevent transaction replacement in miner mempools. It is trivial to execute a double-spend even when the transaction being replaces is not BIP-125 compatible, and there are tools available to do this. Supporting this feature and advertising it is confusing and a potential source of security failures.

"Opt-in" RBF should be removed and replaced with full-RBF. We have no expectation of ever supporting zeroconf transactions at the settlement layer, and that is not changing.

In the rebase to 0.10, it appears that some code newly introduced in the bitcoin change set was not updated to handle demurrage properly. This results in, among other things, watch-only balances not being adjusted for demurrage. The consequences for UI and wallet might be worse than just that, but there shouldn't be any ramifications for consensus code at least.

In fixing this, we should investigate making nValue of CTxOut and CCoins protected and accessed by getters and setters, so that any new code in future releases that touches these fields will be automatically found during compilation.

There are many locations in the codebase where block height values are used, even more so with Freicoin which introduces consensus-critical reference heights, which don't exist in bitcoin. In the original satoshi code, heights were simple signed int values, which on all supported platforms at the time were 32 bits in length. This unfortunately wasn't officially clarified when the type used for height storage became consensus critical with BIP34 ("height in the coinbase"). With Freicoin we used explicitly sized int32_t types for ref height storage, since with 10 minute blocks on average the field won't overflow for some 40,000 years.

However the introduction of protocol cleanup and potential future forward blocks scaling could change this. Once the protocol cleanup rules activate, which is always about 2+ years away, the block rate could be anything. And with forward blocks, compatibility blocks could even safely arrive with less than a second separation, which would exhaust the 32-bit range of the refheight field within a humanly relatable amount of time. Unlike bitcoin we don't anticipate going this route since we also have the option of increasing block size. But we shouldn't pre-maturely tie our hands; we should fix the height-field overflow issue so there isn't ever a future point (in 10 years time or in 40,000 years) where the chain goes haywire because lock heights and reference heights wrap around to negative numbers or zero.

The imminent release of v13 adds some urgency because yet another point is introduced where the consensus code depends on storage of height values: segwit inputs sign the input value, which in Freicoin must also include the reference height (the lock_height of the prior transaction).

This issue should track the extension of all consensus-critical height or timestamp fields to be of sufficient size as to work for millennia into the future, even in the face of protocol upgrades in line with what has been proposed before (e.g. the six-blocks-per-second forward blocks proposal presented at Scaling Bitcoin). Ideally this is accomplished by upgrading all absolute time or height fields to be 64 bits, but in some cases (e.g. the timestamp in the block header) it difficult to find more than a few extra bytes. Extending by even a single high-order byte moves the issue from decades to millennia away, however, which is sufficient for our design requirements.

Bitcoin-0.9 started producing "low-S" values for its wallet signatures, and started enforcing this for relay in 0.10. Our 0.9 release uses quadratic residue as the tie breaker (see issue #5), which means that about half of the transactions being made would not relay on 0.10's default rules, or be mined by a 0.10 miner. We should therefore drop this relay restriction until a "low-S" producing wallet is in wide enough distribution.

This issue is to track the progress of performing a straight rebase of the freicoin/0.9 release branch to the upstream bitcoin/0.10 branch. There are other tickets to track progress in fixing various issues that were introduced with 0.10.

In addition to the freicoin/0.9 tree, the maaku/vagrant-0.10 branch provides the gitian changes necessary to get bitcoin/0.10 to compile, and is a good thing to reference when cherry-picking those patches.