Re: [ANN] [AC] Official Asia Coin Revival | Hard Fork and Voiding Pre-Mine

impossible. you can't confirm that on the fly and whoever tells you in this situation that he carefully checked the code is lying - knowingly or unknowingly. there are so many possibilities to let the one crucial comparison for the premine address return the wrong result. i also don't think that anybody skilled enough to do the task would be willing to spend all that time necessary to go through the code and check that it's really clean and doing what these two junior member accounts that are "saving" the coin are telling us.

all you can do is trust them and that doesn't feel right in this context. doing cryptobusiness shouldn't require that amount of trust.

Quote from: EnabledZombi3 on May 07, 2014, 07:17:44 PM

@Crunchynut
Thanks for playing devil's advocate. We need everyone to provide constructive criticism, and it sounds like you're code savvy enough to help us out. Go ahead and review the code. Let us know if you see a problem that needs to be addressed, or you could even address it yourself.

Quote from: crunchynut on May 07, 2014, 07:06:54 PM

Quote from: EnabledZombi3 on May 07, 2014, 04:55:22 PM

Quote from: 3xk0pt3r on May 07, 2014, 01:09:39 PM

Quote from: maxsinner on May 07, 2014, 01:00:55 PM

So what is to prevent the original developer from selling more coins from the premine as we speak? Are you rolling back the block-chain to some point in the past or what, I don't get it?

Im not a coder, but as far as i know, there is a hardcode to block wallet, where the orriginal dev have these premined coins. That's the main reason for stop deposits and withdraws on exchanges and the rason why we'rewaiting for new updated wallet. Those premined coins will be, simply told, ignored.

I am a coder. I'll break it down.

Everyone can look on our AsiaCoin block explorer from the OP that wallet AKPy5ugy98yBkBCNU9Ne1bHExy5tqdq9Gu gained 3228519924.78 AC from transaction 4f2a34278389aac0b88bbb283338d4dac9314ec62e7dba0f263fc4570aa93c3b. If we go back to the first blocks, it's easy to spot that block 1 is the original dev's premine and has a similarly large value to the dev wallet above.

As for the code fixes, look here and here for the hard coded dev wallet bans. We can all see redundant checks to block AKPy5ugy98yBkBCNU9Ne1bHExy5tqdq9Gu in ProcessBlock, IsStandard, and AcceptBlock. Check it out for yourselves. Each dev wallet ban in the code looks similar to this:

Code:

static const CBitcoinAddress lostWallet ("AKPy5ugy98yBkBCNU9Ne1bHExy5tqdq9Gu");

Code:

if (lostWallet.Get() == addressSource.Get()){
return error("CBlock::AcceptBlock() : Banned Address %s tried to send a transaction (rejecting it).", addressSource.ToString().c_str());
}

you also checked whether this code is ever executed and there isn't anything hidden that prevents that check?

and did you check cbitcoinaddress, cbitcoinaddressvisitor, cbase58data, etc. that there is nothing hidden that would let the cbitcoinaddress constructors or "lostWallet.Get() == addressSource.Get()" do something unexpected? you can confirm that the == operator works correctly and has no tiny flaw added that will fail in this special case?

it's easy to quote a few lines of code that somehow look like that everything is ok while there are several thousand lines of code involved in making this one comparison work and where you could easily hide your stuff.