It is April Fools day today, but this is no april fool trick. I believe BCX stands behind his words, even on April Fools day.

The exploit BCX has found in KGW implememtation is real and, I believe, he is most likely attacking with the exploit just now. However, we have also found a fix to it which will close the case. BCX has confirmed that the fix, when effective, will prevent using the exploit.

Since we are in a kind of stalemate we have agreed to settle down. Continuing this battle is worthless and would only cause harm to all participants. The fix is not yet effective and it is quite likely much damage would be caused if attack would get to the end. Also we all have achieved what we were after; BCX has made his point clear and the coin will be fixed. From the beginning, no one, not even BCX has wanted to destroy the coin.

BCX, do you agree? Is this an agreement?

EDIT: Here is the fix, feel free to update your coins. just change the hard fork block number

Code:

diff --git a/src/main.cpp b/src/main.cpp
index fd881d1..7687d3a 100644
--- a/src/main.cpp
+++ b/src/main.cpp
@@ -886,7 +886,7 @@ unsigned int static GravityWell(const CBlockIndex* pindexLast, const CBlock *pbl
        double                          EventHorizonDeviationSlow;
       
     if (BlockLastSolved == NULL || BlockLastSolved->nHeight == 0 || (uint64)BlockLastSolved->nHeight < PastBlocksMin) { return bnProofOfWorkLimit.GetCompact
-       
+       int64 LatestBlockTime = BlockLastSolved->GetBlockTime();
        for (unsigned int i = 1; BlockReading && BlockReading->nHeight > 0; i++) {
                if (PastBlocksMax > 0 && i > PastBlocksMax) { break; }
                PastBlocksMass++;
@@ -895,10 +895,14 @@ unsigned int static GravityWell(const CBlockIndex* pindexLast, const CBlock *pbl
                else            { PastDifficultyAverage = ((CBigNum().SetCompact(BlockReading->nBits) - PastDifficultyAveragePrev) / i) + PastDifficultyAvera
                PastDifficultyAveragePrev = PastDifficultyAverage;
               
-               PastRateActualSeconds                   = BlockLastSolved->GetBlockTime() - BlockReading->GetBlockTime();
+               if (LatestBlockTime < BlockReading->GetBlockTime()) {
+                       if (BlockReading->nHeight > XXXXX) // HARD Fork block number
+                               LatestBlockTime = BlockReading->GetBlockTime();
+               }
+               PastRateActualSeconds                   = LatestBlockTime - BlockReading->GetBlockTime();
                PastRateTargetSeconds                   = TargetBlocksSpacingSeconds * PastBlocksMass;
                PastRateAdjustmentRatio                 = double(1);
-               if (PastRateActualSeconds < 0) { PastRateActualSeconds = 0; }
+               if (BlockReading->nHeight > XXXXX) { // HARD Fork block number
+                       if (PastRateActualSeconds < 1) { PastRateActualSeconds = 1; }
+               } else {
+                       if (PastRateActualSeconds < 0) { PastRateActualSeconds = 0; }
+               }
                if (PastRateActualSeconds != 0 && PastRateTargetSeconds != 0) {
                PastRateAdjustmentRatio                 = double(PastRateTargetSeconds) / double(PastRateActualSeconds);
                }

Edit2: small modification for the fix
Edit3: added a missing an opening curly bracket, ty Cannacoin!

What is the reasoning behind this? Why allow blocks whose timestamps are behind head block? I see no good reason for that. I see only risks it brings (as history has pointed out).

Another question; would it be safe (ie. does it open any vulnerabilities) to prevent that, or allow to skip only 1 timestamp backwards?

[Count from the block 0: TimeAverage = (TimeAverage + LastBlockTime)/2]

Basicly KGW is just calculating running average, min x hours, up to y days. Then, it limits the max change with the horizon.
However, the calculated average block time should be weighted so the latest block times affects more than the older block times. KGW does not do this.

This is the alternative:

In the simplest theorethical implementation:

Count from the block 0: TimeAverage = (TimeAverage + LastBlockTime)/2

Cannot do that in practise; it would weigth the latest block time too much (50%), and also we cannot walk throught the blockchain everytime we start over, so

Code:

FilterAttenuation = 8
Walkingblock = (block@heightof(currentblock-(FilterAttenuation*2)))
TimeAverage = Walkingblock.time
while Walkingblock.heigth < currentblock.height
{
   Walkingblock = Walkingblock.next;
   TimeAverage = (TimeAverage*(FilterAttenuation-1) + Walkingblock.time)/FilterAttenuation;
}  

Actually this simulates quite well RC circuits commonly used on electorics to filter signals.

What do you think? I think it is a lot simpler and more effective that KGW.

Edit:

I assume WalkingblockTime is Walkingblock.time.

Ty, fixed! (also the missing parenthesis)

[Count from the block 0: TimeAverage = (TimeAverage + LastBlockTime)/2]

Basicly KGW is just calculating running average, min x hours, up to y days. Then, it limits the max change with the horizon.

This is the alternative:

The average should be weighted so the latest block times affects more than the older block times.
In the simplest theorethical implementation:

Count from the block 0: TimeAverage = (TimeAverage + LastBlockTime)/2

Cannot do that in practise; it would weigth the latest block time too much (50%), and also we cannot walk throught the blockchain everytime we start over, so

Code:

FilterAttenuation = 8
Walkingblock = (block@heightof(currentblock-(FilterAttenuation*2))
TimeAverage = Walkingblock.time
while Walkingblock.heigth < currentblock.height
{
   Walkingblock = Walkingblock.next;
   TimeAverage = (TimeAverage*(FilterAttenuation-1) + WalkingblockTime)/FilterAttenuation;
}  

Actually this simulates quite well RC circuits commonly used on electorics to filter signals.

What do you think? I think it is a lot simpler and more effective that KGW.

Interesting.. I currently don't have bitcoin client running, but when I do netstat, I see a lot of connections to bitcoin port, and majority of them seems to be from a DNS starting with "crawl-". Some kind of DDNS attack? Of course, since thetre is nothing runinng, most of them is in a close-wait state.

Similar experiences?

Edit: Some more info; actually I *did* have bitcoin-qt running. Sometimes when I exit, it just leaves the process on. And seems like it works as a honeypot at that stage
After I killed the bitcoin-qt process, all the (jammed) connections disappeared.

Is this a stupid suggestion: MtGox could inlcude a signed comment with their own transaction id in every outgoing transaction. Wouldn't this prevent fraud?

Hi! We all are very frustrated to be forced to generate a new nickname and password for every site on internet. Here is a white paper on an idea of passwordless site login:
https://mega.co.nz/#!QxwEyAyB!FkX6R0uoE1Ponar8KdDDbjK1GS5lXBOOnpRgSxpXvYc

To make it simple; when you want to log in to a site, you just 1) go to the site on any internet terminal. 2) read the 2D barcode 3) you are in. Securely.

Got this idea from bitmessage; these bitmessage addresses could be used for passwordless anonymous login to any system. Or there could be another blockchain delivering bitidentity messages..

Use case, bulletin board:
- user sends a identity request to the page's bitidentity address. For every bitidentity address, there will be a new private key.
- one gets a sessionkey as a reply (maybe direct https - link) which one could use to login to the page and configure nickname etc.

Very secure, no passwords, anonymous identity.

What? Do I need to mine my coins twice in eligius? Let's me tell more; I started to mine at eligius, noticed it gives quite approximate 0.006 btC / day for my single lousy 5770 at 200 MH/S. This is quite much what is expected (could be a slightly more, thought).

However, then I decided to try to mine some ppcoins for a while. Mined a few days, returned to Eligius.. and noticed that my saldo is not increasing regardless of the hashrate...

See this:
http://eligius.st/~wizkid057/newstats/userstats.php/1K9jjmJb7pc8T4PVgEQCnSsDCLVbwKzKYK

I'm going to quit at eligius. And never get back. Just don't like the idea I'm giving 0.1 coins to a stealing site.
Looks like WOT rating (see https://www.mywot.com/)  is just correct for that site.

Now when https://glbse.com/ is gone, maybe it is time to make a blockchain for trading assets, ie decentralized stock exchange? Stock exchange transactions could be tied to bitcoins so transactions could be conditional, verified only if certain bitcoin address receives a payment.
Also, assets could have an owner bitcoin address, where the divident could be sent.

But there are problems; First one is how are the initial assets generated? Maybe like namecoins? Where would be the contracts?

Imagine a bitcoin-qt like briefcase display, showing stock possessions instead of bitcoins.

Compare these two transactions:

http://blockchain.info/tx-index/19470941/990bdf89aa2c9929397815024928749371d3f95d7024e6910c0c39599a366efa

and

http://blockchain.info/tx-index/19472730/5a21c267dfcb110498a5792ca2ad5176fef55e69d3cf365273725feb5f1e9e36

Both are generated with the standard bitcoin client. Why the smaller one needed a transaction fee, but the bigger one did not?

What is the logic on this? It does not seem to follow the rules on https://en.bitcoin.it/wiki/Transaction_fees

Based on that, neither of the example transactions would need a fee.

Btw, almost every transaction has 2 outputs; to minimize fragmentation, should the payment be constructed from 2 or more inputs, if possible? Might have a big effect when the pruning is working..

Edit :bitcoin client version: v0.7.0rc2-19-g31fac11-beta

This is the initial forum to talk about my idea to open an ebook publisher based on bitocins. Still just an idea, let's see what this will be