I agree.  Also, based on the number of total submissions versus the final number of accepted particpants that also submitted an address (8,793 total, 3,244 successful participants -- in other words ~64% rejected), I don't imagine all that many scammers made it through anyways.

Certainly there will be some since no process is perfect, but it is highly unlikely to be as bad as some of the trolls (who are, frankly, probably most likely lying anyways given they never followed up when specifically engaged about the supposed duplicates that made it through by _ingsoc) on this thread would like to lead people to believe.

You could actually read the thread and use the Decred forums to find the answers to the questions yourself rather than repeatedly demanding others to do it for you.

Here, I'll be nice and help you help yourself:

• Block time
• Subsidy system details including a spreadsheet
• Total number of coins is stated in the bullet points of the very first post of this thread

No, I didn't miss the point.  The simple fact is there are a few people on here complaining because maybe some folks got more than they did and that's unfair.  I'm sorry if it hurts anyone's frail sensibilities, but it is simply immature to complain that maybe somebody else got more free than they did.  Besides, even if we assume you're right and the process got scammed "A LOT", what purpose does it serve to get upset about it?  For anyone that was never expecting more than 168 coins, absolutely nothing changed for them.  Anyone expecting more than that is just setting themselves up for disappointment.  If it ends up being more, sweet, if it doesn't, it's what you already expected.

I understand that, but really it's looking at it in the wrong light.  If you are only planning on getting 168 coins, which is the prudent thing to do, then anything more than that is just gravy.  Why not just be grateful for an extremely generous gift and getting in on the ground floor of a coin that appears to have a bright future instead of worrying about other people?  It should come as no surprise that there are scumbags out there.  I don't mean this as a personal attack, but anybody seriously getting upset about receiving free coins because maybe some unscrupulous folks managed to game the system a bit and get more than them seriously screams of an immature child whining "moooooooom, it's not fair Jimmy next door got two scoops of ice cream while I only got one".  Be happy you're eating ice cream while there are large populations of people that are starving.

Something else to consider is that even if some folks managed to scam and get some additional coins, it just means they're probably going to sell them as soon as they can and those of us who plan on holding can improve our positions on the cheap.

I'm more curious why it would even matter if it were true.  As a thought experiment, let's assume for a moment that everything you say were to actually happen.  Also, let's assume that all of the remaining 5,000 spots minus all of the people that have publicly posted they were accepted into the airdrop were filled by nothing but successful scammers, devs, and little magical fairies.  In that scenario, everyone that managed to get in still receives 168 coins for FREE.  Anything less than 5,000 spots means the participants get even more than that.  Nobody was asked for or paid any money.  This really seems like complaining about receiving free money to me.

Further, if the devs wanted to keep all the coins, why would they have even bothered with an airdrop to begin with?  The suggestion that they went through the entire airdrop process, of which there are already a huge number of people that have publicly posted they were accepted to, in order to turn around and keep the very same coins they simply could've simply kept to begin with seems like an whole heck of a lot of work to end up with less coins than they would've had without it.


Unless you spoke to them via PMs where more was stated, which is certainly possible, it appears to me like you are overstating the response.  I remember seeing the response and what you're saying here is not what I remembered reading, so I went and found the response.  Here it is: https://bitcointalk.org/index.php?topic=1290358.msg13493398#msg13493398

I'll quote the relevant pieces:


I don't see anything there at all that even remotely implies "layers of defense mechanisms".  In fact, quite to the contrary, they even acknowledged the system wasn't "going to be perfect".  I personally read "but reasonable steps can be taken to make it as inclusive and fair as possible" as doing exactly what you said where they could have "easily stated that they'll do their best to make sure that folks aren't gaming the system".

It's really the result of the multiplication as opposed to just the "nActualTimespan" being too large.  There is a check to ensure the minimum possible value for "nActualTimespan" is nTargetTimespan/4 = 302,400 = 0x49d40.  Thus, when you take the regtest powLimit of 0x7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff and multiply it by the minimum possible "nActualTimespan", the result is > (2^256) - 1.


Not quite.  It is limited to a minimum and maximum value.  The minimum value is, as previously stated, 0x49d40.  The maximum value is nTargetTimespan*4 = 4,838,400 = 0x49d400.  This effectively limits how much a single difficulty readjustment step can be.

So, while you do have some measure of control, there is no way to make it lower than the minimum allowed value and the regtest powLimit multiplied by that minimum allowed value overflows.

The simple fix, as provided by jrick in PR 6162 is to use 512-bit arithmetic so it can't overflow.



I agree this is not a bad idea, however it does mean that whatever is creating the block also has to be modified since they are most likely mining blocks using either the built-in CPU miner, or based on details from getblocktemplate (which includes the target bits).  They would therefore, by default, be aiming to create blocks using the higher difficulty.

You're making a supposition here that the code contains special casing for the regtest network.  I would agree with you if the retarget code had an extra branch condition that was only executed on the regtest network as then you would only be testing that branch, which is not the same branch as the one that mainnet/testnet would use.  However, that is not the case here since it is parameterized.  I personally think testnet's approach of having special cased branches regarding difficulty is more dangerous from a testing standpoint than the parameterized code in question.


I agree that regtest specifically was created for the block tester and then later expanded.  This is why we created a separate simnet in btcd for actual simulation testing because the regtest mode has behavior specific to the block tester harness and we didn't want to conflate them.  Unfortunately, when we've discussed simnet in #bitcoin-dev, more than one Bitcoin Core dev suggested to just use regtest for that purpose.  So, based upon your comments, I think there is some confusion by the BC community in general on how regtest is supposed to be used.

We can certainly discuss other approaches for the future, but the entire current RPC test harness is based on it, so for better or worse, this is way things currently work.


I'm not sure how a sharp guy such as yourself would expect any other conclusion.  You stated that the behavior was known at the time of the patch and merged anyways.  Therefore a conscious decision was made to commit a change that knowingly broke retargetting on the regtest network.  The only logical conclusion from that information is that proper retargetting on the regtest network was not deemed important enough to avoid merging the change.  Obviously, there were reasons for that decision (some of which you elucidated), but whatever the circumstances leading to the decision, the conclusion is the same.

Thanks for answering.  Unfortunately, the regtest network is currently essentially unusable in the intended way once you've generated enough blocks to reach the first retarget interval.

I suppose this is a bigger deal for us in btcd because we have tests that exercise these types of things and do a lot of simulation testing using simnet (which is effectively like the regtest network without some of the things specific to the block tester tool and some additional logic to prevent address propagation and discovery).  That is a big reason we discovered this issue since we were comparing behavior during some simulations and noticed that Bitcoin Core was erroneously rejecting blocks due to having too low difficulty, when in fact the difficulty was correct.

I have to admit I'm disappointed that the answer is basically that Bitcoin Core doesn't feel like regression and simulation testing is important enough to warrant proper retarget behavior for it, but I appreciate the response nonetheless.

First, I want to point out that I'm only reporting this here because it can't be used to fork mainnet or testnet.  However, this is a problem for the regression test network if any of the tests actually had more than 2016 blocks to exercise the retarget code.

While doing some testing using our simulation test network in btcd, Josh Rickmar and I noticed that Bitcoin Core improperly calculates the difficulty readjustment due to an overflow which occurs on the regtest network.  This is different behavior from all versions of Bitcoin Core prior to commit https://github.com/bitcoin/bitcoin/commit/df9eb5e14fa8072bc8a82b59e712c2ba36f13f4c.

The issue is that previously the calculations used the CBigNum class, which in turn used arbitrary precision OpenSSL bignums, are now limited to 256-bit integers.  For reference, here is the difficulty readjustment calculations in pow.cpp:


Notice that readjustment is calculated by multiplying the old difficulty (converted from its compact representation to a uint256) by the adjusted time span (which is limited to a max of the target time span * 4 and min of target time span / 4).  The result is then divided by the target time span and converted back to compact form.  Unfortunately, this means that using the new uint256s introduced with the aforementioned commit causes the result of the `bnNew *= nActualTimespan;` line to overflow, whereas previously it was arbitrary precision and would not.


Using real numbers for regtest, the forking condition becomes clear.

First, let's do the math using the old arbitrary precision based arithmetic.  For the sake of simplicity and to illustrate the issue, we'll assume that first 2016 blocks are found fast enough such that the minimum possible multiplication case gets hit.



Old Expected difficulty bits: 0x201fffff


Now, let's repeat the math using the current code in Bitcoin Core:


New Expected difficulty bits: 0x1e0d9ebb


Notice how the calculated value is much lower than it should be as compared to the previous behavior and therefore leads to the required proof of work being ~154000 times more difficult than it should be.

A little more math shows that since the maximum multiplier is nTargetTimespan*4 = 4838400 = 0x49d400, this overflow condition can occur so long as the difficulty is >= 0x377aef2669de1558cd0447bbf336aae22599d11488c00377aef2669de15 (compact bits: 0x1e0377ae).

A simple fix is using higher precision arithmetic for the intermediate results.  Josh Rickmar is working on a patch which does this.

Little endian:  https://github.com/btcsuite/btcd/blob/master/wire/msgtx.go#L307

Correct.  There is some development discussion in there, but typically we use other channels for that purpose.  Feel free to stop by!

We do the vast majority of our communication through IRC.

It's a mix of internal and external contributors.  Features show up as pull requests before they go in.

The main things coming up are outlined in the following PRs:

https://github.com/btcsuite/btcwallet/pull/125 - This has already been merged to master, but it's just a package that the wallet is not yet using.  
https://github.com/btcsuite/btcwallet/pull/152 - Like 125, this has already been merged to master, but the wallet is not yet using it.
https://github.com/btcsuite/btcwallet/pull/147 - This will integrate the packages mentioned in 125 and 152 making everything they discussed available.

Also, there are the following two PRs which aren't well documented yet, but are being worked on:

https://github.com/btcsuite/btcwallet/pull/155 - This brings accounts support to btcwallet, but will need documentation because they are real accounts as opposed to the bitcoin core notion of accounts (completely independent, no commingling of funds, require on-chain transactions to transfer funds between them, etc).  If you read between the lines on how pr 125 works, you can probably figure out how the accounts will work based on BIP0032.
https://github.com/btcsuite/btcwallet/pull/154 - This will update the transaction store to use the new walletdb bits covered in 152.  The current plan is to update 147 to include integration of this package once it's complete.

Finally, Monetas has been working on bringing voting pool support and that is covered in the following PRs:

https://github.com/btcsuite/btcwallet/pull/151 - This has already been merged, but it's just the package which is currently not being used.
https://github.com/btcsuite/btcwallet/pull/178 - This will provide the withdrawal side of voting pools, but like 151, won't actually be used until the rest of the code needed to use it is complete

Am I the only one that sees how conflicted the messaging is in this thread?

In one camp we have people saying that BC is not really centralized because it's free and open source and can therefore be forked and modified in any arbitrary fashion, but then the other camp talks all about consensus issues and why implementations not running the official BC source are a bad idea.

What's interesting about this is the moment you fork the code and start making changes to it, it is also an alternative implementation.  You could argue about the probabilities of forking risk, etc, but the fact remains, the moment you fork it and modify it, you are running something that is not the same as the majority of other nodes on the network.  It would not take much at all for somebody to fork BC and refactor some code while adding some features that they want which accidentally (or even intentionally if it's a malicious actor intending to distribute their fork) makes a mistake that very subtly breaks consensus.  This is really no different than any other alternative implementation when you get right down to it.

It's either acceptable to have Bitcoin nodes running different code bases or it's not.  I just don't see how any reasonable person can claim it goes both ways.  Either the message must be that it's too dangerous to run anything except the official Bitcoin Core sources, in which case the development truly is centralized and controlled by the small group of people who hold the ssh keys, or that it is in fact acceptable to run modified sources (which very much implies alternative implementations).  It's just not reasonable to claim that it's not centralized because theoretically anybody can fork it and do whatever they want while at the same time saying don't do that because it's too dangerous!

In my opinion, the responsible thing to do would be to do it on testnet.  Intentionally forking the mainnet block chain knowing it will likely cost some people money is a pretty crappy thing to do.


There are several large companies, such as Coinbase, that don't run on Bitcoin Core.


The transaction will end up in the block chain anyways (short of a massive network-wide chain fork that reorgs your transaction out and it got double-spent, but that is an issue that applies across the board regardless of any bugs), so even if your implementation didn't see it for some reason, the transaction, and hence your money, isn't lost.  The only time I can think of where this wouldn't be the case is if the bug involved sending the transaction to the wrong address.

We can't just cherry pick what to apply our arguments to.  The entire argument here is entirely based around the probability that Bitcoin Core is less likely to fork than alternatives, because the exact same logic you describe applies to multiple versions of Bitcoin Core on different compilers, OSes, hardware, etc, as much as it does to alternatives.  Of course, in an adversarial environment, you have bad faith actors looking to exploit those probabilities.  You're asserting that there is a much lower probability that they will be able to do so between two versions of Bitcoin Core.  That's fair, but it doesn't make any sense to use probabilities to assert that and then turn around and say they don't matter when applied to a different implementation.

Either probabilities don't matter and the entire argument about whether Bitcoin Core is more or less likely (probability) to fork or not is moot, or they really do matter.  I claim they absolutely do matter because Bitcoin Core isn't immune to forks either and there is clearly some chance involved that forks will occur between any two pieces of Bitcoin software.


The claim isn't that a prefab test suite is entirely sufficient, it's that it lowers the probability of a fork occurring.  When is the probability low enough that it's generally safe to transact?  If you claim there isn't one, then Bitcoin, as a whole, is unsafe to transact on because the entirety of consensus is probability based to begin with.

I personally think the question is wrong here.  Not even Bitcoin Core is technically 100% compatible with the same version of itself, so asking that question is starting with a false premise.  As previously mentioned, there is a lot of work to be done in the formal verification space, but even then, due to hardware differences, compiler optimization differences, OS differences, and a myriad of other factors, I personally think it's unlikely there will ever be absolute 100% certainty.  The question then becomes, does there really have to be?

To me, what it really comes down to is probabilities.  The popular assumption is that Bitcoin Core has an extremely low probability that it will fork against itself.  So, let's go with that premise and say that the probability of Bitcoin Core forking against itself is something like 1 in a 100 trillion (1e14).

When an alternative implementation passes all consensus tests and covers all known corner cases, then it too has a relatively low probability of forking.  If that is not true, then the consensus tests need to be improved.  For the sake of argument, let's assume that such an alternative is 3 orders of magnitude, or 1000x, more likely to fork.  Well, then the forking probability relative to the Bitcoin Core forking probability previously stated would then be 1 in 100 billion (1e11).

Moreover, if/when a fork does happen, it identifies a case that the consensus tests missed and can be used to improve the consensus tests which in turn further reduces the probability for all nodes involved (including Bitcoin Core) that validate against the consensus tests.

It is estimated that in any given year the odds that you will die from an impact of an asteroid or comet are between 1 in 3,000 and 1 in 250,000.  However, that probability is still low enough that I bet you don't live in a steel box and refuse to go outside just in case.

Thanks for your response.  Yes, I'm the lead dev on btcd.

a and b) First, both of these are completely irrelevant.  No one knows who Satoshi was/is, yet that isn't a problem for Bitcoin Core.  So, even if every single contributor were unknown (they're not as you can find the names of every contributor on github), why would it be a problem for btcd when it isn't for Bitcoin Core?  Second, the defense bit is not true, but even if it were though, I'd venture to say with the number of contributors on Bitcoin Core, at least one or more have affiliations in one way or another with some organization that you, or somebody else, doesn't like.  The code is completely open for all to see, so it would be obvious to see if something nefarious were going on as you are implying.

c) It has been publicly stated many, many times that it is being coded because the ecosystem severely needs multiple diverse implementations if Bitcoin is ever going to truly flourish to the level we all want it to.  Thinking that a single implementation controlled by a handful of people is a good scheme for a system that is supposed to take over the World's monetary supply is just not very forward thinking.  This has been covered ad naseum.

d) This is a complete red herring and exists just as much with Bitcoin Core as it does with anything else.  The exact same thing can easily happen (and already has as you've noted) with Bitcoin Core.  This is a real problem with the technology that needs to be solved independent of the number of implementations on the network.  In fact, working toward solutions which address this fundamental issue is necessary for Bitcoin Core too since it means mistakes there don't lead to undesirable consequences either.  The current approach is "well let's just hope it doesn't happen!" and frankly, that just isn't good enough.

e) You've been misinformed.  Here is a blog post I made on the very first package we released back in May of 2013 which was only the wire protocol that clearly states "Here at Conformal, we are keenly aware of how important it is that any full-node implementations agree on the exact same set of rules for what blocks get included into the block chain as minor differences can lead to chain forks and double-spends." (https://blog.conformal.com/btcwire-the-bitcoin-wire-protocol-package-from-btcd/).  The Bitcoin Core devs weren't even aware we were working on the project at that point in time.  There was no "convincing" needed or involved.

f) This is referring to d and e, see those.

That's quite an assertion.  In what way is it opaque?  The code is ISC licensed, freely available on github, and the issues are openly tracked via the github tracker.   It also has has high quality comments and code documentation (frankly I would even contend that means btcd is actually _less_ opaque in that regard as the code is generally more modular and easier to follow).