Pardon the intrusion, but I just wanted to say that I have experience in the area and have some advice.  First off, I wouldn't recommend trying writing multi-algo from scratch, because there are some serious pitfalls with non-trivial solutions.  That being said, the leading options are Myriad and DigiByte.  DigiByte's difficulty adjustment tends to produce wider difficulty swings, but ultimately is better at keeping the block times on target and giving each algo an equal share.  It also provides superb multipool resilience.  Myriad does a fine job as well, though there is an issue I identified with their "work decay" logic that I would recommend fixing if you go that route.

I suggest reading the source code.  That's exactly right: you should do your own work, especially since you haven't already done it on your own and of your own initiative. Or do you think I'm here to work for you? I've done my job by alerting you to the fact that with basic coding skills and the source code mentioned (that is freely available to the public), anyone can confirm it. It's your problem, not mine, if you don't care, and judging by your attitude, I guess it's just that, correct? If you don't care, why should I?

Trolling aside, it turns out you don't even need that.  Even if the only thing you know about MultiShield is that it keeps each algorithm's share at 20%, that is already sufficient to answer your question (with basic math skills, of course).  You can multiply and divide can't you?

Okay, trolling truly off now.  One thing you seem to be confused about is the latest hardfork.  MultiShield was not changed at all in the DigiSpeed hardfork (other than changing a few constants so blocks would be faster).  The formula that estimates work per block was changed, but this is unrelated to difficulty adjustments.

Edit: apparently HR didn't get it, so here's some context:


The "multiply and divide" line was similarly copied from one of your posts which seems to no longer exist.

Wait a minute...are you saying that the hashrate of one algorithm affects the diff of other algorithms or are you saying that the fact that it doesn't doesn't level the playing field?


Your analysis may very well be rigorous, but I can't find your analysis - only your conclusions and a rough description of your sources.  If you want a serious response, post your source data, the conclusions you derive from the source data, and any required logical steps that go beyond "basic math skills".  I shouldn't have to re-do all your work just to have a conversation with you about the results.

Step 1: "Phantom BTC" credits
Create a new, fake currency called "Phantom BTC", which cannot be deposited nor withdrawn.  Credit all users with Phantom BTC equivalent to their current outstanding BTC holdings and set BTC holdings to 0.  Future BTC deposits will be credited as BTC.

Step 2: BTC to Phantom BTC exchange
Create a new trading pair between BTC and Phantom BTC.  Collect a Phantom BTC commission on every trade.  This means that on every trade the amount of Phantom BTC in existence will decrease.

Step 3: Phantom BTC buyback
Use profits from other trading pairs to buy back Phantom BTC, further accelerating the rate at which it disappears.  If the stolen funds are recovered, all of the Phantom BTC can immediately be bought back.  Eventually there will be no more Phantom BTC and Cryptsy can close that trading pair.

Having a BTC to Phantom BTC exchange will allow pessimistic bagholders to withdraw their BTC at a loss, while allowing opportunistic traders to essentially buy Cryptsy's debt, with the possibility of significant returns when Cryptsy finally gets everything back on track.  Patient/optimistic bagholders can simply wait until a favorable exchange rate or until the buyback.

Altcoins in a nutshell.

If anyone wants to help me try out a possible solution to the network issues please try pulling https://github.com/digibyte/digibyte/pull/40.  My theory is that the network is basically DoSing itself and that if enough nodes stop doing that things will return to normal.

Something is broken.  And whatever it is is almost certainly responsible for the orphan rates as well.  So far I have managed to confirm that my node is receiving up-to-date blocks, but is missing an old block and therefore can't connect the chain.  It requests the missing block(s) from various peers, but eventually gives up with "Peer is stalling block download, disconnecting".

I was hoping to stay out of this conversation, but since I both discovered and fixed said security hole I thought I'd share my experience as a contributor.  Every time I pointed out a flaw and offered a solution to DigiByte, Jared immediately welcomed my ideas and code.  On the other hand, when I did the same for Myriad I was largely ignored.  I should also add that there is an unfixed security hole in Myriad's multi-PoW system that DigiByte does not and will not have.  As for releasing the fix sooner, in both cases it was decided to simply work the change into the next planned hard fork. It just happened that Myriad's planned hard fork was for a sooner date.

On a more philosophical note I do agree with you that people shouldn't need to know the identities of developers of a collaborative open source project.  But the key word here is collaborative.  Most coins are too much cathedral and not enough bazaar, to use the terms from https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar.  DigiByte development has been more closed as of late, and it's one of the few things I will criticize it for.

Edit:

Nope, this is factually inaccurate.  DigiByte fixed time-warp in November 2014.  Myriad had to "fix" time-warp 3 times, the last of which was February 2015.  In fact, Myriad copied their final time-warp fix from DigiByte.

BTC withdrawal stuck for 36 hours.  Tried to log in just now and my password doesn't work.  Password was definitely correct.  Opened a ticket, will update this post as things progress.

Update (2015/11/03): successfully withdrew 5 BTC, several more transactions still pending.

Not quite.  They're both difficulty adjustment algorithms but DigiShield only works for one algorithm, whereas MultiShield was specifically designed for multi-algorithm difficulty adjustments.  DigiByte switched from DigiShield to MultiShield a long time ago, but you'll still see DigiShield named in a lot of DigiByte propaganda because it was adopted by several other cryptocurrencies.  MultiShield is currently only used by DigiByte.

Hmm, you seem to be right about the second scenario.  But what about the first scenario?  That should still be possible, right?  Also it looks like this was discussed very briefly here: https://bitcointalk.org/index.php?topic=51069.msg609496#msg609496

Let me clarify what it means to merge mine a coin with itself, since this is at the centre of the attack.

A merge mined block consists of a parent chain, and one or more auxiliary chains, both of which are covered by the same proof-of-work.  Normally, both/all chains correspond to different coins.  For example, you might have a bitcoin parent chain with a namecoin auxiliary chain and a ixcoin auxiliary chain.  But there's nothing to prevent you from having multiple chains belonging to the same coin.  So you could feasibly create a block with a namecoin parent chain and a namecoin auxiliary chain, or a block with a bitcoin parent chain and two namecoin auxiliary chains.  By merge mining this way, you can mine two chains at once from the same coin.  This allows an attacker to build a chain in secret, while still generating revenue mining on the public chain.

A double-spending attack can be attempted by an individual with much less than 51% of the network hash power, but it is not guaranteed to succeed, and the odds of success drop exponentially as the number of required confirmations increases. Additionally, after a failed double-spending attack, the attacker's mined blocks become worthless, and he loses the associated revenue. For this reason it is assumed that an attacker with much less than 51% of the network hash power is expected to lose money by attempting to double-spend due to lost mining revenue.

It turns out that for coins that allow merged mining, an attacker can attempt a double-spending attack but retain any mining revenue even if the attack fails. Essentially, there is zero cost to the attacker to attempt an attack.

The attacker takes advantage of merged mining in order to intentionally fork the chain. One fork of the chain will contain the original spend, which will be broadcast to the network. The other fork will contain the double spend and will be kept private. The attacker creates the fork and mines both forks simultaneously by merge mining the coin with itself. The attacker continues to broadcast blocks built on top of the original spend. If the attacker successfully creates enough consecutive blocks for the receiver to consider the transaction "confirmed", then the attacker mines one more block on his private chain, and publishes the private chain, thereby completing the double-spend. If the network mines a block instead, the attacker discards his private chain, keeps his mining revenue from the blocks he published, and no one will ever be the wiser.

Should we be worried?  In a word, no.  Such an attack is very unlikely to succeed. If the attacker controls 30% of the network hash power, then according to Nakamoto's original paper a traditional double-spending attack on 5 confirmations will succeed with 17.7% odds. However, with the attack proposed here, the odds are less than 0.1%. The difference is because in my scenario the attacker must mine 6 consecutive blocks without the rest of the network mining any.

Edit:
The attack can be combined with selfish mining to improve the odds to about the same (or potentially better) as a traditional 51% attack, while remaining mostly cost-free.  If the attacker employs selfish mining, he now has 2 private chains.  He publishes blocks from the "original" private chain whenever the network solves a block, hoping for his block to disperse faster through the network.  Then he publishes the "double spend" branch once it is long enough as before.  There is some risk of lost mining revenue if he loses the block-propagation race, but even if he fails to make enough blocks to succeed in double spending, he keeps the mining revenue from the remaining published blocks.

This isn't really a fair contest unless you have intentionally generated these addresses in a way that can be brute-forced (something like the WarpWallet challenges).  Since the addresses have no outgoing transactions, the only available attack vector is to brute force secp256k1+sha256+ripemd160.  But without knowing how the addresses were generated (for example, they could just be random 160-byte addresses, in which case they are for all practical considerations unspendable) I'm not going to waste my time.

This made me laugh - especially the part about what you're saying holding even more weight because it's based on "common sense".  No offense, but no amount of "common sense" can match up to having read (and written parts of) the source code.  Let me do my best to break it down:

If you mine a block using SHA256d at difficulty 1000000, the network says this block contains 1000000 "work units".
If you mine a block using Scrypt at difficulty 30, the network says this block contains about 120000 "work units".
If you mine a block using Groestl at difficulty 200, the network says this block contains about 100000 "work units".
If you mine a block using Skein at difficulty 1000, the network says this block contains 24000 "work units".
If you mine a block using Qubit at difficulty 40, the network says this block contains about 40000 "work units".

If one block of each algo is mined every 150 seconds on average, this amounts to 8560 "work units" per second by the main network.

Now consider an attacker with enough hashpower to maintain the SHA256d difficulty at 1300000 (without the rest of the network).  At one block every 150 seconds this amounts to 8666 "work units" per second.  Therefore, the attacker can produce "work units" at a faster rate than the main network, and use this to mount a 51% attack against the coin.

So what about the one-cpu attack?  Well, at the time Myriad was taking the sum of the difficulties (without the multipliers) as the "work units".  In the above example each block would contain 1001270 "work units", regardless of which algorithm was used.  The attacker chooses a starting point for his chain when the SHA256d difficulty is high, and because he doesn't mine SHA256d the difficulty for that algo doesn't change.  Eventually, the attacker's blocks have difficulties that look something like (1500000, 1, 1, 1, 1) and generate 1500004 "work units" per block, despite the attacker actually mining at difficulty 1.  The dev team fixed it by adding a decay step to the work calculation - if too many blocks go by without a particular algorithm finding a block, the "work units" provided by that algorithm are reduced (possibly all the way to 0).  But Myriad is still vulnerable if the attacker has slightly more than 50% of the SHA256d hashrate.

So how do we solve it?  In the DigiSpeed branch, "work units" are calculated by multiplying all of the difficulties, then taking the 5th root.  For the example difficulties at the top of this post, it works out to about 750 "work units" per block.  But if an attacker has enough hashpower to maintain the difficulties at (9000000, 15, 100, 500, 20), his blocks contain only 670 "work units" each, even though he controls 90% of one algorithm and 33% of the other 4 algorithms.  Note that pre-DigiSpeed "work units" are not directly comparable to post-DigiSpeed "work units", and the code contains a fudge factor to make sure the coin isn't vulnerable during the transition.

That page just uses non-technical wording.  Bitcoin also uses the "most work" criterion.

Work factors only apply to multi-algo coins.

Your misconception stems from this fact: the "best" chain is determined not by the number of blocks in the chain, but by the amount of work in the chain.  Right now nodes consider the average sha256d block to contain much more work than any block from any of the other algorithms (due to magic work factors set before asics were common).

That's my pull request, here is an up-to-date calculation.

Based on current difficulties (averaged over 1000 blocks), this is each algorithms contribution to the work calculation:
sha256d: 1.13e+06 * 1
scrypt: 23.7 * 4096
groestl: 152 * 512
skein: 1070 * 24
qubit: 47.6 * 1024
This adds up to 1.38e6.  Half the total can be made with just 61% of the sha256d contribution.  Asics are to blame.  When the formula was crafted, each algorithm did indeed have a near-equal contribution.  But as the sha256d hashrate climbed the others couldn't keep up.  It was always true that an attacker could attack the coin with just 1 algorithm but they would have needed at least 87% if all algorithms were weighted properly.  The new formula does not rely on magic work factors, and does not allow one algorithm to dominate under any circumstances.

I'm not going to throw stones at marketing.  As far as I can tell they didn't know it was wrong.  Now we know, but we already have a fix prepared to make it even stronger than the original claims.

Edit: Bold part.  Read the bold part, and relax.

But how do you decide which scriptSig is "correct"?  This is one of the challenges the Bitcoin developers are currently facing - attempting to define a set of rules to make sure only one version of a scriptSig is considered "correct".


I've seen people justify many of Bitcoin's deficiencies as features, but that's a discussion for another place and time.  There are some benefits to non-malleable transactions besides being more robust against bad/uneducated programmers (which by itself is a good enough reason, IMHO).  For example you can create transactions that use the outputs of another transaction before that transaction is signed.

Managed to answer my own question.  Not including scriptSigs in the hash leads to a vulnerability where an attacker broadcasts a modified version of a block which contains too many sigops, causing a node to reject a valid block as invalid.  I conclude that the transaction hash for the merkle root must include scriptSigs, however it should be okay to use a different mechanism to compute the transaction id.