Today is already August 13 so you are two days late already...
You should announce the winner so people get excited about voting again.
When they see you are not taking the dates serious they get frustrated because they spend time and effort on voting for their favorite coins.

Thanks Jared,
Could you point in the direction of the specific code for that additional filter by dogecoin?

Much appreciated.

Jared,
Would you kindly provide a bit of in depth technical information on a) the problematic symptoms digishield is experiencing under the 0.9.1 codebase and b) What is the root cause of it and, if possible at the moment, c) how it will be solved?

Also, is Dogecoin for example experiencing anything similar now that they have switched to the 0.9(.1?) codebase?

Thank you.

BIG VOTING GIVEAWAY AND BOUNTY!
Who wants to make money by voting on BTER?
Contact for details!

Anyone with BTER points who doesn't know what to do with them and doesn't really care, please go to voting section and vote for ISR

I've been reading up on the multi-algo approach and the problem it is aiming to solve and wanted to see if I understood the problem itself properly and then try and understand how the multi-algo approach would solve it.
If I got it right, the main problem is that multi-pools come in for short periods of time, bring a huge spike of hashpower into the network, then leave after they have driven the diff drastically up to where it is no longer that profitable for them to mine.
The aftermath, once they leave, is twofold - a high diff left with much less hashpower to solve it (DigiShield helps mitigate that to a nice extent) and of course the coins the multi-pool dumps into the market upon leaving, driving the price down.
Another problem added here (and to each his own on its priority opposite the problems stated above) would be the security of the network in terms of 51% when gigantic pools (multi or otherwise) come in to have their cake, eat it too and then have it again (with the potential of double spend and such).

Does this describe the main, if not the entire scope of the problem?

Assuming it does, I am trying to understand how the multi-algo will essentially solve it or at least mitigate in a substantial way.
While I think I understand the reasoning given for it, I am struggling with the fact(?) that multi-pools these days are becoming multi-algo as well where essentially they allow miners to decide which algo to use and divert each algo to the most profitable coin within that algo's space.
Essentially what I see could happen here, is that such a multipool would now be able to direct ALL its algos into the DGB network (let's assume they work with the 5 chosen for DGB), so essentially under their control (as a pool) would be not just one algo but possibly 5 algos, assuming they can get enough hash power. Even if that possibility is remote and they cannot gain an overall 51% (which I think is indeed much less likely), they could still bring a total hashpower overall that would allow them to spike up the individual diffs and most of all, gain a chunk of the coins being mined and dump them into the market as they do now, driving prices down and then leaving for another coin while the diffs have spiked up for everyone else to deal with it, until the next cycle (each on their respective algo/diff within DGB).

I would appreciate some thoughts on my analysis of things. (From anyone, of course, but definitely from the DGB devs)

I've been reading up (well, catching up I suppose) on the multi-algo approach and the problem it is aiming to solve and wanted to see if I understood the problem itself properly and then to try and understand how the multi-algo approach would solve it.
If I got it right, the main problem is that multi-pools come in for short periods of time, bring a huge spike of hashpower into the network, then leave after they have driven the diff drastically up to where it is no longer that profitable for them to mine.
The aftermath, once they leave, is twofold - a high diff left for much less hashpower to solve (DigiShield helps mitigate that to a nice extent) and of course the coins the multi-pool dumps into the market upon leaving, driving the price down.
Another problem added here (and to each his own on its priority opposite the problems stated above) would be the security of the network in terms of 51% when gigantic pools (multi or otherwise) come in to have their cake, eat it too and then have it again (with the potential of double spend and such).

Does this describe the main, if not the entire scope of the problem?

Assuming it does, I am trying to understand how the multi-algo will essentially solve it or at least mitigate in a substantial way.
While I think I understand the reasoning given for it, I am struggling with the fact(?) that multi-pools these days are becoming multi-algo as well where essentially they allow miners to decide which algo to use and divert each algo to the most profitable coin within that algo's space.
Essentially what I see could happen here, is that such a multipool would now be able to direct ALL its algos into the DGB network (let's assume they work with the 5 chosen for DGB), so essentially under their control (as a pool) would be not just one algo but possibly 5 algos, assuming they can get enough hash power. Even if that possibility is remote and they cannot gain an overall 51% (which I think is indeed much less likely), they could still bring a total hashpower overall that would allow them to spike up the individual diffs and most of all, gain a chunk of the coins being mined and dump them into the market as they do now, driving prices down and then leaving for another coin while the diffs have spiked up for everyone else to deal with it, until the next cycle (each on their respective algo/diff within DGB).

I would appreciate some thoughts on my analysis of things. (From anyone, of course, but definitely from the DGB devs)

as a followup - I just tried doing a manual multisig transaction of a 6 of 10, using only compressed pub keys in the latest bitcoin core, but still getting tx rejected 22. the script is somewhat shorter than with the non-compressed, but definitely not by a huge amount.

Any ideas on how to get this to work?
I've seen people saying that with compressed pub keys even a 15 of 15 could fit within the 520b limit, so what am I missing here?

Great work on this!

I've tried the service and a 2of3 worked great.
however, I tried something that I actually need right now in the form of a 6-of-10 and... no go
Getting a tx rejected -22 and log error says "nonstandard transaction: scriptsig-size" which I assume relates to the 500b limit mentioned earlier in the thread.
Is there a way to make this work?
Reading around in some other discussions I saw being mentioned that even a 15 of 15 should work, so I'm a bit confused as to why 6 of 10 doesn't.

Also OutCast, on a side note, it would be really great if you could provide the non-minified bitcoinjs code (either as a download here or in the git repo) as part of the opensource approach.


Thanks!