Thanks Groggin!

Nice write-up of us! Thanks Tristan.

http://bitscan.com/articles/the-cypherfunks-disrupting-the-music-industry

We are second on the list. Now we just need to sustain the voting:

https://www.swisscex.com/voting

Band high five!

Awesome! Thanks for notifying us Jommy!

vote, vote, vote!

While you are at it:
https://www.mintpal.com/voting
http://comkort.com/vote/#FUNK

Right. Agree on both counts. I was specifically referring to the fix. The fix treats blocks from that past as very, very fast blocks which shoots up the diff [which is not what you want].


Didn't know about that. Interesting!

So what do you suggest? Other retargeting algos that seem promising, but haven't taken a look at is digishield and dark gravity wave2. How do they perform?

And do you agree with the trade-off? Implementing the fix pushes in erroneous diff adjustments that could be detrimental to the coin. Or make it so that a 51%-er can mint more blocks with the same work? Currently, I think it's not ideal to implement the current tw fix that everyone is implementing, since if someone is maliciously doing a 51% attack, you are screwed anyway...

Thoughts?

So. I took time to fully understand the TW exploit & the fix. By the looks of it, the fix actually introduces new problems [that have affect coins such as Aiden & Coin-o].

I might be wrong. But if you have thoughts, please add them to this thread. I posted about the whole thing there:

https://bitcointalk.org/index.php?topic=552895.msg6199218#msg6199218

So here's my understanding of the TW exploit & the fix.

The problem with the well is that any blocks in the past (or blocks with the same timestamp), get regarded as "PastRateActualSeconds = 0"

      if (PastRateActualSeconds < 0) { PastRateActualSeconds = 0; }

What happens now, is that IF PastRateActualSeconds are 0, it does not adjust the diff.

     if (PastRateActualSeconds != 0 && PastRateTargetSeconds != 0)

So, the attacker does the following: they work on their own chain. They put the timestamp as far as possible into the future to get max downward adjustment, and continues until the diff is lowest possible diff for the chain. At that point, the attacker generates blocks with the same timestamp, until it hits the "block-time too early" (getmedianpast) check in AcceptBlock. Basically, the attacker is pumping loads of low-diff blocks "at the same time" until they can't anymore. Putting blocks in the past don't help as they get regarded as "0" anyway in terms of diff adjustment. But putting blocks in the past, allows the attacker to get back in line with the main chain.

So, now they do it again. Until getmedianpast check doesn't fail, and do it again. It's a trade-off between being too far ahead and having enough work. But if the chains match based on the time, it's entirely possible that the attacker has the same work, with more blocks and the chains re-organise.

So if I understand it correctly (correct me if I'm wrong), the attacker still needs 51%. But now that they HAVE that 51% they can do the same amount of work, but generate more blocks.

While the fix protects against this attack, by making it unfeasible, it actually causes other problems [sky high diff adjustments as was seen with Aiden & Coin-o].

What's SUPPOSED to happen is that the attacker is not supposed to generate blocks with the same timestamp & keep the same diff. In most scenarios, this would mean there is A LOT of hashing power and the diff should adjust accordingly.

That's what this fix does here:

if (PastRateActualSeconds < 1) { PastRateActualSeconds = 1; }

If it's a block in the past, or the same timestamp, it's regarded as having taken 1 second. The problem with this is, is that if there are legitimate blocks in the past [due to network lag, or other reasons] it is regarded as an extremely fast block, rather than a legitimate block [within range]. This shoots up the difficulty (as we've seen with some coins). This happens more easily with coins with low block-times.

These diff adjustments didn't happen with the original KGW because they weren't taken into account for the diff adjustment.

With diff adjustments happening per block, it's a difficult problem to solve. Any 1-block algo is vulnerable, as blocks in the past [which is a legitimate anomaly] is an "odd" happenstance in 1-block diff algos.

So the trade-off is:

1) When an attacker gains 51%, they have the capability to generate more blocks with the same work. While this is not ideal, the reason why this is bad, is that incentives 51% attacks (as it is more monetary profitable).
2) Remove the incentives with this fix, but screw up legitimate blocks from the past [which causes absurd diff adjustments].

Personally, I think there needs to be a small "free" period where blocks from the past is okay, which of course makes the KGW not a 1 block algo...

This is of course, all assuming I'm correct... BCX? Nite69? Others? Care to comment?

Thoughts?

In due time. If we become big, we'll have more clout. As a start, I think it would be cool to sell iTunes gift-cards for FUNK (it shouldn't be too difficult to do).

Also, if enough songs are made with the band, we can just start our own streaming service of JUST Cypherfunks music.

yep. not ideal.

Thanks for you effort Groggin! It's a appreciated.

It seems CryptoRush markets are down again [for no apparent reason]. They really are not doing a decent job of staying in contact with coin devs. I'll contact them again.

Yeah. That's how I gathered it as well. Thanks guys.

EDIT: btw. Check this. http://www.philharmonia.co.uk/explore/make_music <- thousands of free samples. How epic?!

Actually, a rather clever feature! Easily claimable tips.

I've been a bit sick, so couldn't do any dev work. Will try to get back onto this asap. So my plan is to implement the TW fix. Then also in that update add in the alert system (properly). I don't think has been using the TestNet, so I'll probably be creating a new one to test that TW fix goes through smoothly. It doesn't seem too complicated, and it's actually not a hard-fork, so it should be okay. In other words, even if less than 51% of the network has old clients, it will still run fine. It could only fork if a TW exploit is targeted to the old clients (IF they have more than 51%). So, for all intents and purposes. Should be fine.

btw: appreciate whomever been's also voting on mintpal & comkort.

https://www.mintpal.com/voting
https://comkort.com/vote/#FUNK

On the music front. Should have a remix out soon. Also have a friend, Marc, who is fully trained musician that's going to be contributing some beats/riffs to the project.

Cheers!

Bang high-five!

oh nice. Didn't know you could do tips on cryptokk.

fwiw.

The heartbleed bug DOES affect all Litecoin-based coins: http://heartbleed.com/. But it is only vulnerable if you ever used rpcssl. This is not on by default, and is rarely used. If you just downloaded a wallet, you should be fine. If you built from source, it will use your system's openssl library (which is what exchanges will most likely do, and they should patch and recompile it accordingly).

This isn't critical and will be included in the next update.

EDIT: It has been patched and will come with the next update.

Yeah. Low hashrates will always be vulnerable unfortunately, doesn't matter what you employ.

I know jwinterm has been playing with Blender (not sure if he wants to contribute to a flyer design).

Cryptorush reactivated the daemon.

https://cryptorush.in/index.php?p=trading&m=FUNK&b=LTC

Time to throw up some buy support again.

Meanwhile. Remember to vote:

https://www.mintpal.com/voting
https://comkort.com/vote/#FUNK

I've been receiving conflicting reports on the KGW TW exploit. Potcoin devs are going to remove as it the fix toys with block timing. I'm going away for a week and thus had a lot of admin to do today. But I'm going to a farm with pretty much of nothing on it, so going to have some time to look at the fix again (and it is needed).

We have a beta IRC tipbot up and running. Come hang out with us: https://webchat.freenode.net/?channels=cypherfunks

Band meeting! Here's an update of all that's happened in this week:

http://blog.thecypherfunks.com/post/81913737963/band-update-week-ending-2014-04-06

Thanks nox! The stuff you've done so far for the "band" has been a lot. Thanks again. Updated main page. btw. The BTC donation link is not valid.

Yeah. I pm'ed him. We are getting a new one up too.

Welcome Wizmaster!