[ANN][YAC] YACoin ongoing development

[alenevaa]

I thought the orphaned issue was 'fixed' and the 'malicious miner' had stopped.  So are you saying that even if I do get solo mining working there is a very good chance that the computing power I dedicated to mining will be on a 'split' blockchain? 

Yep, exactly!

Even all PoS blocks that your wallet has found will be orphaned. You can check it later by yourself.
We are waiting for the fixes that senj has proposed and for consolidating the hashpower.
I have running pool in standby mode with a little hashpower just for monitoring situation. But everybody welcome to mine, of course..

[1713998909]

1713998909

[1713998909]

1713998909

[1713998909]

1713998909

[aso118b]

I thought the orphaned issue was 'fixed' and the 'malicious miner' had stopped.  So are you saying that even if I do get solo mining working there is a very good chance that the computing power I dedicated to mining will be on a 'split' blockchain? 

Yep, exactly!

Even all PoS blocks that your wallet has found will be orphaned. You can check it later by yourself.
We are waiting for the fixes that senj has proposed and for consolidating the hashpower.
I have running pool in standby mode with a little hashpower just for monitoring situation. But everybody welcome to mine, of course..

So we can't mine or mint or send transactions right now....  How long until the 'quick fix' is applied?

[alenevaa]

So we can't mine or mint or send transactions right now....  How long until the 'quick fix' is applied?

Public transactions are included in chain by [irony]merciful malicious miner[/irony] ('3M').
Of course only the transactions which operate with earlier blocks before splitting the chain.

I hope that 3M will be bored or price will be dumped so low that 3M won't get any sense and he get off.

[aso118b]

I thought the orphaned issue was 'fixed' and the 'malicious miner' had stopped.  So are you saying that even if I do get solo mining working there is a very good chance that the computing power I dedicated to mining will be on a 'split' blockchain? 

Yep, exactly!

Even all PoS blocks that your wallet has found will be orphaned. You can check it later by yourself.
We are waiting for the fixes that senj has proposed and for consolidating the hashpower.
I have running pool in standby mode with a little hashpower just for monitoring situation. But everybody welcome to mine, of course..

So we can't mine or mint or send transactions right now....  How long until the 'quick fix' is applied?

Is there an ETA or timeline for this to be implemented?  Until YAC can be mined by the community again, and not one miner, the coin is dead... 

[Beave162]

Is there an ETA or timeline for this to be implemented?  Until YAC can be mined by the community again, and not one miner, the coin is dead... 

It is simply a matter of time before this 'attack' is defeated for the cause of "fairer" distribution in the block rewards.

YACoin has always been going through a process of weeding out the people who are just vested in a coin for short-term profits over long-term purpose. I'd say the people sticking with it at this point are very high-quality in many ways.

This person (or group) is really hurting himself the most if you consider lost opportunity. As the price drops--as it should as long this attack continues--the magnitude of earnings and opportunities for people who are in it for the long-haul will just be that much greater. The 'fixes' will hopefully be released soon, but time is on our side no matter what.

[old c coder]

old c coder, I considered your comments and realized you made very substantial arguments.
Therefore I've made changes:

GetPoWPoSRatio() function now returns double, and there is new GetSpacingThreshold() function that adjusts, rounds and converts that ratio to integer.
Now Proof Of Work target moving average does not get stored in PoS block's nonce attribute. I've added to CBlockIndex class new member nBitsMA for that purpose. Like you said - having it in PoS block's nonce was not needed, and second: I think it is even better, if we can keep PoS nonce at 0 and force PoW blocks have nonce>0. That is how we will be able to easily differentiate blocks in future and derive chaintrust only from headers.

Next I've managed to complete code upgrade. I've split github commits into logical contexts. I suggest you start scrutinizing from oldest one on, because that functionality get's reused in later commits.

Last commit will need to be explained, but in short: it deals with small value ProofOfStake blocks in a way Balthazar mentioned more than a year ago (the need to make attack energy expensive). I had a complex solution for that, but then I came up with a better one: reuse scrypt-jane and transform stake kernel hash operation to use memory(scrypt-jane) for hash, and stakeNfactor used gets calculated from stake kernel value. I also introduced new higher dynamic threshold - you now need more than 20 coins (in one input) to generate stake and that value is incrementally increasing. Again, a lot of explaining needed here, also regarding optimizations...

First, I need proficient eyes to take a look and raise flags on possible obvious errors.
Unfortunately I do not have resources to test this, so this is done kind of Beethoven style (after he went deaf).
But I think we can make it work.

here:
https://github.com/senadj/yacoin/commits/smallpos

Hello Senj,

I have been thinking about the code and wondering if one could "slow down" the PoW "attack" by requiring (or making it more "atractive") to have a PoS block between PoW blocks?

The current miner code, in the daemon & Qt code has this line in the function:
void BitcoinMiner(CWallet *pwallet, bool fProofOfStake)
{
...
if (fProofOfStake && pindexPrev->IsProofOfStake())
        {
            bool
                fFastPOS = GetArg("-fastpos", 0);

            if (!fFastPOS)
                Sleep(500);
            continue;
        }
...
}

Which suggests to me that two (consecutive/contiguous) PoS blocks aren't allowed.  Could we add a similar:
if (!fProofOfStake && !pindexPrev->IsProofOfStake())
        {
            bool
                fFastPOS = GetArg("-fastpos", 0);

            if (!fFastPOS)
                Sleep(500);
            continue;
        }
or some such, forcing a PoS block?  At the moment the average block period goes up sometimes over 5 minutes, I presume because there are few miners mining and the "difficulty" is high?  Is there too much risk that no one online can PoS and so stop the flow of blocks?  I said somewhere that perhaps being able to mine every block instead of every other block as a PoW one may be the "break-even" money point (at ~ 1minute/block average period) that makes this ploy worth doing.  If he/she/they can PoS along with someone else, would the code the rest of the nodes are running fairly allow one or the other PoS block and reject the other, even if the greedy miner adds a PoW block onto the "weaker" PoS block.  

Just musing...  on to the unit tests in a separate message

Ron

[old c coder]

Hello all,

I remember reading that the unit test for YACoin "didn't work", "needed work", etc.  So I said I can do that, since I did it for Bitcoin (0.8.6 MSVC++ and earlier versions).

Yesterday at ~9:30am EDT I finally conquered the gcc unit tests on windows!!  By that I mean being able to compile successfully!  And run!  The MSVC++ versions have been running for some time, but it would be nice to compare to the gcc flavor to verify that the code is doing the same thing with both compilers.  And it is!

I'm seeing a lot of errors in the "base58_keys_valid_parse" of the "base58_tests" test suite.  I went back and looked at the Bitcoin 0.7.2 sources and a sampling of NVC and PPC sources and the test data files are all identical.  The test code too!  Sadly YACoin up to 0.4.4 is the same too!

So the data to test an address that doesn't start with Y sure ain't going to work on code testing for it!

It seems "tautological" to use the Yacoind or qt to create an address, then put it into the test data files and then test the program to see if it agrees that that is an address?  I would think that one would like to create addresses and keys and scripts, etc. to test, with some other tool than the code itself, to actually test the code?

And all the other tests in the "base58_keys_valid_parse" and the "base58_keys_valid_gen" tests.  Anyone have any idea what the intent (there's that word again) of the test code was in this area?  Are the tests using special values to test some aspect of the bitcoin 0.7.2 code?

In any event, here is what the gcc Yacoin unit tests look like:

Running 69 test cases...
Entering test suite "Bitcoin Test Suite"
Entering test suite "wallet_tests"
Entering test case "coin_selection_tests"
Leaving test case "coin_selection_tests"; testing time: 781ms
Leaving test suite "wallet_tests"
Entering test suite "util_tests"
Entering test case "util_criticalsection"
Test case util_criticalsection did not check any assertions
Leaving test case "util_criticalsection"; testing time: 15999mks
Entering test case "util_MedianFilter"
Leaving test case "util_MedianFilter"
Entering test case "util_ParseHex"
Leaving test case "util_ParseHex"
Entering test case "util_HexStr"
Leaving test case "util_HexStr"
Entering test case "util_DateTimeStrFormat"
Leaving test case "util_DateTimeStrFormat"
Entering test case "util_ParseParameters"
Leaving test case "util_ParseParameters"
Entering test case "util_GetArg"
Leaving test case "util_GetArg"
Entering test case "util_WildcardMatch"
Leaving test case "util_WildcardMatch"
Entering test case "util_FormatMoney"
Leaving test case "util_FormatMoney"
Entering test case "util_ParseMoney"
Leaving test case "util_ParseMoney"
Entering test case "util_IsHex"
Leaving test case "util_IsHex"
Leaving test suite "util_tests"
Entering test suite "uint256_tests"
Entering test case "uint256_equality"
Leaving test case "uint256_equality"
Leaving test suite "uint256_tests"
Entering test suite "uint160_tests"
Entering test case "uint160_equality"
Leaving test case "uint160_equality"
Leaving test suite "uint160_tests"
Entering test suite "transaction_tests"
Entering test case "tx_valid"
unknown location(0): fatal error in "tx_valid": std::exception: CDataStream::read() : end of data
Leaving test case "tx_valid"; testing time: 47ms
Entering test case "tx_invalid"
unknown location(0): fatal error in "tx_invalid": std::exception: CDataStream::read() : end of data
Leaving test case "tx_invalid"
Entering test case "basic_transaction_tests"
unknown location(0): fatal error in "basic_transaction_tests": std::exception: CDataStream::read() : end of data
Leaving test case "basic_transaction_tests"
Entering test case "test_Get"
Leaving test case "test_Get"; testing time: 47ms
Entering test case "test_GetThrow"
Leaving test case "test_GetThrow"
Leaving test suite "transaction_tests"
Entering test suite "sigopcount_tests"
Entering test case "GetSigOpCount"
Leaving test case "GetSigOpCount"; testing time: 15ms
Leaving test suite "sigopcount_tests"
Entering test suite "script_tests"
Entering test case "script_valid"
Leaving test case "script_valid"; testing time: 47ms
Entering test case "script_invalid"
Leaving test case "script_invalid"; testing time: 15999mks
Entering test case "script_PushData"
Leaving test case "script_PushData"
Entering test case "script_CHECKMULTISIG12"
Leaving test case "script_CHECKMULTISIG12"; testing time: 31ms
Entering test case "script_CHECKMULTISIG23"
Leaving test case "script_CHECKMULTISIG23"; testing time: 94ms
Entering test case "script_combineSigs"
Leaving test case "script_combineSigs"; testing time: 47ms
Leaving test suite "script_tests"
Entering test suite "script_P2SH_tests"
Entering test case "sign"
Leaving test case "sign"; testing time: 78ms
Entering test case "norecurse"
Leaving test case "norecurse"
Entering test case "set"
Leaving test case "set"; testing time: 47ms
Entering test case "is"
Leaving test case "is"
Entering test case "switchover"
Leaving test case "switchover"
Entering test case "AreInputsStandard"
Leaving test case "AreInputsStandard"; testing time: 31ms
Leaving test suite "script_P2SH_tests"
Entering test suite "rpc_tests"
Entering test case "rpc_addmultisig"
Leaving test case "rpc_addmultisig"; testing time: 468ms
Leaving test suite "rpc_tests"
Entering test suite "netbase_tests"
Entering test case "netbase_networks"
test/netbase_tests.cpp(25): error in "netbase_networks": check CNetAddr("2001::8888").GetNetwork() == NET_IPV6 failed
test/netbase_tests.cpp(26): error in "netbase_networks": check CNetAddr("FD87:D87E:EB43:edb1:8e4:3588:e546:35ca").GetNetwork() == NET_TOR failed
Leaving test case "netbase_networks"
Entering test case "netbase_properties"
test/netbase_tests.cpp(33): error in "netbase_properties": check CNetAddr("::FFFF:192.168.0.4").IsIPv4() failed
test/netbase_tests.cpp(38): error in "netbase_properties": check CNetAddr("2001:0DB8::").IsRFC3849() failed
test/netbase_tests.cpp(40): error in "netbase_properties": check CNetAddr("2002::1").IsRFC3964() failed
test/netbase_tests.cpp(41): error in "netbase_properties": check CNetAddr("FC00::").IsRFC4193() failed
test/netbase_tests.cpp(42): error in "netbase_properties": check CNetAddr("2001::2").IsRFC4380() failed
test/netbase_tests.cpp(43): error in "netbase_properties": check CNetAddr("2001:10::").IsRFC4843() failed
test/netbase_tests.cpp(44): error in "netbase_properties": check CNetAddr("FE80::").IsRFC4862() failed
test/netbase_tests.cpp(45): error in "netbase_properties": check CNetAddr("64:FF9B::").IsRFC6052() failed
test/netbase_tests.cpp(46): error in "netbase_properties": check CNetAddr("FD87:D87E:EB43:edb1:8e4:3588:e546:35ca").IsTor() failed
test/netbase_tests.cpp(48): error in "netbase_properties": check CNetAddr("::1").IsLocal() failed
test/netbase_tests.cpp(50): error in "netbase_properties": check CNetAddr("2001::1").IsRoutable() failed
Leaving test case "netbase_properties"
Entering test case "netbase_splithost"
Leaving test case "netbase_splithost"
Entering test case "netbase_lookupnumeric"
test/netbase_tests.cpp(93): error in "netbase_lookupnumeric": check TestParse("::ffff:127.0.0.1", "127.0.0.1:65535") failed
test/netbase_tests.cpp(94): error in "netbase_lookupnumeric": check TestParse("::", "[::]:65535") failed
test/netbase_tests.cpp(95): error in "netbase_lookupnumeric": check TestParse("[::]:8333", "[::]:8333") failed
Leaving test case "netbase_lookupnumeric"
Entering test case "onioncat_test"
test/netbase_tests.cpp(105): error in "onioncat_test": check addr1 == addr2 failed
Leaving test case "onioncat_test"
Leaving test suite "netbase_tests"
Entering test suite "multisig_tests"
Entering test case "multisig_verify"
Leaving test case "multisig_verify"; testing time: 250ms
Entering test case "multisig_IsStandard"
Leaving test case "multisig_IsStandard"
Entering test case "multisig_Solver1"
Leaving test case "multisig_Solver1"; testing time: 15999mks
Entering test case "multisig_Sign"
Leaving test case "multisig_Sign"; testing time: 31ms
Leaving test suite "multisig_tests"
Entering test suite "mruset_tests"
Entering test case "mruset_like_set"
Leaving test case "mruset_like_set"; testing time: 31999mks
Entering test case "mruset_limited_size"
Leaving test case "mruset_limited_size"; testing time: 15ms
Entering test case "mruset_window"
Leaving test case "mruset_window"; testing time: 47ms
Leaving test suite "mruset_tests"
Entering test suite "miner_tests"
Entering test case "sha256transform_equality"
2df5e1c65ef9f8cde240d23cae2ec036d31a15ec64bc68f64be242b1da6631f3
Leaving test case "sha256transform_equality"
Leaving test suite "miner_tests"
Entering test suite "key_tests"
Entering test case "key_test1"
test/key_tests.cpp(91): error in "key_test1": check bsecret1.SetString (strSecret1) failed
test/key_tests.cpp(92): error in "key_test1": check bsecret2.SetString (strSecret2) failed
test/key_tests.cpp(93): error in "key_test1": check bsecret1C.SetString(strSecret1C) failed
test/key_tests.cpp(94): error in "key_test1": check bsecret2C.SetString(strSecret2C) failed
test/key_tests.cpp(116): error in "key_test1": check addr1.Get() == CTxDestination(key1.GetPubKey().GetID()) failed
test/key_tests.cpp(117): error in "key_test1": check addr2.Get() == CTxDestination(key2.GetPubKey().GetID()) failed
test/key_tests.cpp(118): error in "key_test1": check addr1C.Get() == CTxDestination(key1C.GetPubKey().GetID()) failed
test/key_tests.cpp(119): error in "key_test1": check addr2C.Get() == CTxDestination(key2C.GetPubKey().GetID()) failed
Leaving test case "key_test1"; testing time: 1438ms
Leaving test suite "key_tests"
Entering test suite "getarg_tests"
Entering test case "boolarg"
Leaving test case "boolarg"
Entering test case "stringarg"
Leaving test case "stringarg"
Entering test case "intarg"
Leaving test case "intarg"
Entering test case "doubledash"
Leaving test case "doubledash"
Entering test case "boolargno"
Leaving test case "boolargno"
Leaving test suite "getarg_tests"
Entering test suite "DoS_tests"
Entering test case "DoS_banning"
Leaving test case "DoS_banning"
Entering test case "DoS_banscore"
Leaving test case "DoS_banscore"
Entering test case "DoS_bantime"
Leaving test case "DoS_bantime"
Entering test case "DoS_checknbits"
Leaving test case "DoS_checknbits"
Entering test case "DoS_mapOrphans"
Leaving test case "DoS_mapOrphans"; testing time: 593ms
Entering test case "DoS_checkSig"
Leaving test case "DoS_checkSig"; testing time: 1250ms
Leaving test suite "DoS_tests"
Entering test suite "Checkpoints_tests"
Entering test case "sanity"
Leaving test case "sanity"
Leaving test suite "Checkpoints_tests"
Entering test suite "bignum_tests"
Entering test case "bignum_setint64"
Leaving test case "bignum_setint64"
Leaving test suite "bignum_tests"
Entering test suite "base64_tests"
Entering test case "base64_testvectors"
Leaving test case "base64_testvectors"
Leaving test suite "base64_tests"
Entering test suite "base58_tests"
Entering test case "base58_EncodeBase58"
Leaving test case "base58_EncodeBase58"
Entering test case "base58_DecodeBase58"
Leaving test case "base58_DecodeBase58"
Entering test case "base58_keys_valid_parse"
test/base58_tests.cpp(178): error in "base58_keys_valid_parse": !IsValid:["1AGNa15ZQXAZUgFiqJ2i7Z2DPU2J6hW62i","65a16059864a2fdbc7c99a4723a8395bc6f188eb",{"addrType":"pubkey","isPrivkey":false,"isTestnet":false}]
test/base58_tests.cpp(181): error in "base58_keys_valid_parse": addrType mismatch["1AGNa15ZQXAZUgFiqJ2i7Z2DPU2J6hW62i","65a16059864a2fdbc7c99a4723a8395bc6f188eb",{"addrType":"pubkey","isPrivkey":false,"isTestnet":false}]
test/base58_tests.cpp(178): error in "base58_keys_valid_parse": !IsValid:["3CMNFxN1oHBc4R1EpboAL5yzHGgE611Xou","74f209f6ea907e2ea48f74fae05782ae8a665257",{"addrType":"script","isPrivkey":false,"isTestnet":false}]
test/base58_tests.cpp(179): error in "base58_keys_valid_parse": isScript mismatch["3CMNFxN1oHBc4R1EpboAL5yzHGgE611Xou","74f209f6ea907e2ea48f74fae05782ae8a665257",{"addrType":"script","isPrivkey":false,"isTestnet":false}]
test/base58_tests.cpp(181): error in "base58_keys_valid_parse": addrType mismatch["3CMNFxN1oHBc4R1EpboAL5yzHGgE611Xou","74f209f6ea907e2ea48f74fae05782ae8a665257",{"addrType":"script","isPrivkey":false,"isTestnet":false}]
test/base58_tests.cpp(162): error in "base58_keys_valid_parse": !SetString:["5Kd3NBUAdUnhyzenEwVLy9pBKxSwXvE9FMPyR4UKZvpe6E3AgLr","eddbdc1168f1daeadbd3e44c1e3f8f5a284c2029f78ad26af98583a499de5b19",{"isCompressed":false,"isPrivkey":true,"isTestnet":false}]
test/base58_tests.cpp(163): error in "base58_keys_valid_parse": !IsValid:["5Kd3NBUAdUnhyzenEwVLy9pBKxSwXvE9FMPyR4UKZvpe6E3AgLr","eddbdc1168f1daeadbd3e44c1e3f8f5a284c2029f78ad26af98583a499de5b19",{"isCompressed":false,"isPrivkey":true,"isTestnet":false}]
test/base58_tests.cpp(162): error in "base58_keys_valid_parse": !SetString:["Kz6UJmQACJmLtaQj5A3JAge4kVTNQ8gbvXuwbmCj7bsaabudb3RD","55c9bccb9ed68446d1b75273bbce89d7fe013a8acd1625514420fb2aca1a21c4",{"isCompressed":true,"isPrivkey":true,"isTestnet":false}]
test/base58_tests.cpp(163): error in "base58_keys_valid_parse": !IsValid:["Kz6UJmQACJmLtaQj5A3JAge4kVTNQ8gbvXuwbmCj7bsaabudb3RD","55c9bccb9ed68446d1b75273bbce89d7fe013a8acd1625514420fb2aca1a21c4",{"isCompressed":true,"isPrivkey":true,"isTestnet":false}]
test/base58_tests.cpp(178): error in "base58_keys_valid_parse": !IsValid:["1Ax4gZtb7gAit2TivwejZHYtNNLT18PUXJ","6d23156cbbdcc82a5a47eee4c2c7c583c18b6bf4",{"addrType":"pubkey","isPrivkey":false,"isTestnet":false}]
test/base58_tests.cpp(181): error in "base58_keys_valid_parse": addrType mismatch["1Ax4gZtb7gAit2TivwejZHYtNNLT18PUXJ","6d23156cbbdcc82a5a47eee4c2c7c583c18b6bf4",{"addrType":"pubkey","isPrivkey":false,"isTestnet":false}]
test/base58_tests.cpp(178): error in "base58_keys_valid_parse": !IsValid:["3QjYXhTkvuj8qPaXHTTWb5wjXhdsLAAWVy","fcc5460dd6e2487c7d75b1963625da0e8f4c5975",{"addrType":"script","isPrivkey":false,"isTestnet":false}]
test/base58_tests.cpp(179): error in "base58_keys_valid_parse": isScript mismatch["3QjYXhTkvuj8qPaXHTTWb5wjXhdsLAAWVy","fcc5460dd6e2487c7d75b1963625da0e8f4c5975",{"addrType":"script","isPrivkey":false,"isTestnet":false}]
test/base58_tests.cpp(181): error in "base58_keys_valid_parse": addrType mismatch["3QjYXhTkvuj8qPaXHTTWb5wjXhdsLAAWVy","fcc5460dd6e2487c7d75b1963625da0e8f4c5975",{"addrType":"script","isPrivkey":false,"isTestnet":false}]
test/base58_tests.cpp(162): error in "base58_keys_valid_parse": !SetString:["5K494XZwps2bGyeL71pWid4noiSNA2cfCibrvRWqcHSptoFn7rc","a326b95ebae30164217d7a7f57d72ab2b54e3be64928a19da0210b9568d4015e",{"isCompressed":false,"isPrivkey":true,"isTestnet":false}]
test/base58_tests.cpp(163): error in "base58_keys_valid_parse": !IsValid:["5K494XZwps2bGyeL71pWid4noiSNA2cfCibrvRWqcHSptoFn7rc","a326b95ebae30164217d7a7f57d72ab2b54e3be64928a19da0210b9568d4015e",{"isCompressed":false,"isPrivkey":true,"isTestnet":false}]
test/base58_tests.cpp(162): error in "base58_keys_valid_parse": !SetString:["L1RrrnXkcKut5DEMwtDthjwRcTTwED36thyL1DebVrKuwvohjMNi","7d998b45c219a1e38e99e7cbd312ef67f77a455a9b50c730c27f02c6f730dfb4",{"isCompressed":true,"isPrivkey":true,"isTestnet":false}]
test/base58_tests.cpp(163): error in "base58_keys_valid_parse": !IsValid:["L1RrrnXkcKut5DEMwtDthjwRcTTwED36thyL1DebVrKuwvohjMNi","7d998b45c219a1e38e99e7cbd312ef67f77a455a9b50c730c27f02c6f730dfb4",{"isCompressed":true,"isPrivkey":true,"isTestnet":false}]
test/base58_tests.cpp(178): error in "base58_keys_valid_parse": !IsValid:["1C5bSj1iEGUgSTbziymG7Cn18ENQuT36vv","7987ccaa53d02c8873487ef919677cd3db7a6912",{"addrType":"pubkey","isPrivkey":false,"isTestnet":false}]
test/base58_tests.cpp(181): error in "base58_keys_valid_parse": addrType mismatch["1C5bSj1iEGUgSTbziymG7Cn18ENQuT36vv","7987ccaa53d02c8873487ef919677cd3db7a6912",{"addrType":"pubkey","isPrivkey":false,"isTestnet":false}]
test/base58_tests.cpp(178): error in "base58_keys_valid_parse": !IsValid:["3AnNxabYGoTxYiTEZwFEnerUoeFXK2Zoks","63bcc565f9e68ee0189dd5cc67f1b0e5f02f45cb",{"addrType":"script","isPrivkey":false,"isTestnet":false}]
test/base58_tests.cpp(179): error in "base58_keys_valid_parse": isScript mismatch["3AnNxabYGoTxYiTEZwFEnerUoeFXK2Zoks","63bcc565f9e68ee0189dd5cc67f1b0e5f02f45cb",{"addrType":"script","isPrivkey":false,"isTestnet":false}]
test/base58_tests.cpp(181): error in "base58_keys_valid_parse": addrType mismatch["3AnNxabYGoTxYiTEZwFEnerUoeFXK2Zoks","63bcc565f9e68ee0189dd5cc67f1b0e5f02f45cb",{"addrType":"script","isPrivkey":false,"isTestnet":false}]
test/base58_tests.cpp(162): error in "base58_keys_valid_parse": !SetString:["5KaBW9vNtWNhc3ZEDyNCiXLPdVPHCikRxSBWwV9NrpLLa4LsXi9","e75d936d56377f432f404aabb406601f892fd49da90eb6ac558a733c93b47252",{"isCompressed":false,"isPrivkey":true,"isTestnet":false}]
test/base58_tests.cpp(163): error in "base58_keys_valid_parse": !IsValid:["5KaBW9vNtWNhc3ZEDyNCiXLPdVPHCikRxSBWwV9NrpLLa4LsXi9","e75d936d56377f432f404aabb406601f892fd49da90eb6ac558a733c93b47252",{"isCompressed":false,"isPrivkey":true,"isTestnet":false}]
test/base58_tests.cpp(162): error in "base58_keys_valid_parse": !SetString:["L1axzbSyynNYA8mCAhzxkipKkfHtAXYF4YQnhSKcLV8YXA874fgT","8248bd0375f2f75d7e274ae544fb920f51784480866b102384190b1addfbaa5c",{"isCompressed":true,"isPrivkey":true,"isTestnet":false}]
test/base58_tests.cpp(163): error in "base58_keys_valid_parse": !IsValid:["L1axzbSyynNYA8mCAhzxkipKkfHtAXYF4YQnhSKcLV8YXA874fgT","8248bd0375f2f75d7e274ae544fb920f51784480866b102384190b1addfbaa5c",{"isCompressed":true,"isPrivkey":true,"isTestnet":false}]
test/base58_tests.cpp(178): error in "base58_keys_valid_parse": !IsValid:["1Gqk4Tv79P91Cc1STQtU3s1W6277M2CVWu","adc1cc2081a27206fae25792f28bbc55b831549d",{"addrType":"pubkey","isPrivkey":false,"isTestnet":false}]
test/base58_tests.cpp(181): error in "base58_keys_valid_parse": addrType mismatch["1Gqk4Tv79P91Cc1STQtU3s1W6277M2CVWu","adc1cc2081a27206fae25792f28bbc55b831549d",{"addrType":"pubkey","isPrivkey":false,"isTestnet":false}]
test/base58_tests.cpp(178): error in "base58_keys_valid_parse": !IsValid:["33vt8ViH5jsr115AGkW6cEmEz9MpvJSwDk","188f91a931947eddd7432d6e614387e32b244709",{"addrType":"script","isPrivkey":false,"isTestnet":false}]
test/base58_tests.cpp(179): error in "base58_keys_valid_parse": isScript mismatch["33vt8ViH5jsr115AGkW6cEmEz9MpvJSwDk","188f91a931947eddd7432d6e614387e32b244709",{"addrType":"script","isPrivkey":false,"isTestnet":false}]
test/base58_tests.cpp(181): error in "base58_keys_valid_parse": addrType mismatch["33vt8ViH5jsr115AGkW6cEmEz9MpvJSwDk","188f91a931947eddd7432d6e614387e32b244709",{"addrType":"script","isPrivkey":false,"isTestnet":false}]
test/base58_tests.cpp(162): error in "base58_keys_valid_parse": !SetString:["5HtH6GdcwCJA4ggWEL1B3jzBBUB8HPiBi9SBc5h9i4Wk4PSeApR","091035445ef105fa1bb125eccfb1882f3fe69592265956ade751fd095033d8d0",{"isCompressed":false,"isPrivkey":true,"isTestnet":false}]
test/base58_tests.cpp(163): error in "base58_keys_valid_parse": !IsValid:["5HtH6GdcwCJA4ggWEL1B3jzBBUB8HPiBi9SBc5h9i4Wk4PSeApR","091035445ef105fa1bb125eccfb1882f3fe69592265956ade751fd095033d8d0",{"isCompressed":false,"isPrivkey":true,"isTestnet":false}]
test/base58_tests.cpp(162): error in "base58_keys_valid_parse": !SetString:["L2xSYmMeVo3Zek3ZTsv9xUrXVAmrWxJ8Ua4cw8pkfbQhcEFhkXT8","ab2b4bcdfc91d34dee0ae2a8c6b6668dadaeb3a88b9859743156f462325187af",{"isCompressed":true,"isPrivkey":true,"isTestnet":false}]
test/base58_tests.cpp(163): error in "base58_keys_valid_parse": !IsValid:["L2xSYmMeVo3Zek3ZTsv9xUrXVAmrWxJ8Ua4cw8pkfbQhcEFhkXT8","ab2b4bcdfc91d34dee0ae2a8c6b6668dadaeb3a88b9859743156f462325187af",{"isCompressed":true,"isPrivkey":true,"isTestnet":false}]
test/base58_tests.cpp(178): error in "base58_keys_valid_parse": !IsValid:["1JwMWBVLtiqtscbaRHai4pqHokhFCbtoB4","c4c1b72491ede1eedaca00618407ee0b772cad0d",{"addrType":"pubkey","isPrivkey":false,"isTestnet":false}]
test/base58_tests.cpp(181): error in "base58_keys_valid_parse": addrType mismatch["1JwMWBVLtiqtscbaRHai4pqHokhFCbtoB4","c4c1b72491ede1eedaca00618407ee0b772cad0d",{"addrType":"pubkey","isPrivkey":false,"isTestnet":false}]
test/base58_tests.cpp(178): error in "base58_keys_valid_parse": !IsValid:["3QCzvfL4ZRvmJFiWWBVwxfdaNBT8EtxB5y","f6fe69bcb548a829cce4c57bf6fff8af3a5981f9",{"addrType":"script","isPrivkey":false,"isTestnet":false}]
test/base58_tests.cpp(179): error in "base58_keys_valid_parse": isScript mismatch["3QCzvfL4ZRvmJFiWWBVwxfdaNBT8EtxB5y","f6fe69bcb548a829cce4c57bf6fff8af3a5981f9",{"addrType":"script","isPrivkey":false,"isTestnet":false}]
test/base58_tests.cpp(181): error in "base58_keys_valid_parse": addrType mismatch["3QCzvfL4ZRvmJFiWWBVwxfdaNBT8EtxB5y","f6fe69bcb548a829cce4c57bf6fff8af3a5981f9",{"addrType":"script","isPrivkey":false,"isTestnet":false}]
test/base58_tests.cpp(162): error in "base58_keys_valid_parse": !SetString:["5KQmDryMNDcisTzRp3zEq9e4awRmJrEVU1j5vFRTKpRNYPqYrMg","d1fab7ab7385ad26872237f1eb9789aa25cc986bacc695e07ac571d6cdac8bc0",{"isCompressed":false,"isPrivkey":true,"isTestnet":false}]
test/base58_tests.cpp(163): error in "base58_keys_valid_parse": !IsValid:["5KQmDryMNDcisTzRp3zEq9e4awRmJrEVU1j5vFRTKpRNYPqYrMg","d1fab7ab7385ad26872237f1eb9789aa25cc986bacc695e07ac571d6cdac8bc0",{"isCompressed":false,"isPrivkey":true,"isTestnet":false}]
test/base58_tests.cpp(162): error in "base58_keys_valid_parse": !SetString:["L39Fy7AC2Hhj95gh3Yb2AU5YHh1mQSAHgpNixvm27poizcJyLtUi","b0bbede33ef254e8376aceb1510253fc3550efd0fcf84dcd0c9998b288f166b3",{"isCompressed":true,"isPrivkey":true,"isTestnet":false}]
test/base58_tests.cpp(163): error in "base58_keys_valid_parse": !IsValid:["L39Fy7AC2Hhj95gh3Yb2AU5YHh1mQSAHgpNixvm27poizcJyLtUi","b0bbede33ef254e8376aceb1510253fc3550efd0fcf84dcd0c9998b288f166b3",{"isCompressed":true,"isPrivkey":true,"isTestnet":false}]
test/base58_tests.cpp(178): error in "base58_keys_valid_parse": !IsValid:["19dcawoKcZdQz365WpXWMhX6QCUpR9SY4r","5eadaf9bb7121f0f192561a5a62f5e5f54210292",{"addrType":"pubkey","isPrivkey":false,"isTestnet":false}]
test/base58_tests.cpp(181): error in "base58_keys_valid_parse": addrType mismatch["19dcawoKcZdQz365WpXWMhX6QCUpR9SY4r","5eadaf9bb7121f0f192561a5a62f5e5f54210292",{"addrType":"pubkey","isPrivkey":false,"isTestnet":false}]
test/base58_tests.cpp(178): error in "base58_keys_valid_parse": !IsValid:["37Sp6Rv3y4kVd1nQ1JV5pfqXccHNyZm1x3","3f210e7277c899c3a155cc1c90f4106cbddeec6e",{"addrType":"script","isPrivkey":false,"isTestnet":false}]
test/base58_tests.cpp(179): error in "base58_keys_valid_parse": isScript mismatch["37Sp6Rv3y4kVd1nQ1JV5pfqXccHNyZm1x3","3f210e7277c899c3a155cc1c90f4106cbddeec6e",{"addrType":"script","isPrivkey":false,"isTestnet":false}]
test/base58_tests.cpp(181): error in "base58_keys_valid_parse": addrType mismatch["37Sp6Rv3y4kVd1nQ1JV5pfqXccHNyZm1x3","3f210e7277c899c3a155cc1c90f4106cbddeec6e",{"addrType":"script","isPrivkey":false,"isTestnet":false}]
test/base58_tests.cpp(162): error in "base58_keys_valid_parse": !SetString:["5KL6zEaMtPRXZKo1bbMq7JDjjo1bJuQcsgL33je3oY8uSJCR5b4","c7666842503db6dc6ea061f092cfb9c388448629a6fe868d068c42a488b478ae",{"isCompressed":false,"isPrivkey":true,"isTestnet":false}]
test/base58_tests.cpp(163): error in "base58_keys_valid_parse": !IsValid:["5KL6zEaMtPRXZKo1bbMq7JDjjo1bJuQcsgL33je3oY8uSJCR5b4","c7666842503db6dc6ea061f092cfb9c388448629a6fe868d068c42a488b478ae",{"isCompressed":false,"isPrivkey":true,"isTestnet":false}]
test/base58_tests.cpp(162): error in "base58_keys_valid_parse": !SetString:["KwV9KAfwbwt51veZWNscRTeZs9CKpojyu1MsPnaKTF5kz69H1UN2","07f0803fc5399e773555ab1e8939907e9badacc17ca129e67a2f5f2ff84351dd",{"isCompressed":true,"isPrivkey":true,"isTestnet":false}]
test/base58_tests.cpp(163): error in "base58_keys_valid_parse": !IsValid:["KwV9KAfwbwt51veZWNscRTeZs9CKpojyu1MsPnaKTF5kz69H1UN2","07f0803fc5399e773555ab1e8939907e9badacc17ca129e67a2f5f2ff84351dd",{"isCompressed":true,"isPrivkey":true,"isTestnet":false}]
test/base58_tests.cpp(178): error in "base58_keys_valid_parse": !IsValid:["13p1ijLwsnrcuyqcTvJXkq2ASdXqcnEBLE","1ed467017f043e91ed4c44b4e8dd674db211c4e6",{"addrType":"pubkey","isPrivkey":false,"isTestnet":false}]
test/base58_tests.cpp(181): error in "base58_keys_valid_parse": addrType mismatch["13p1ijLwsnrcuyqcTvJXkq2ASdXqcnEBLE","1ed467017f043e91ed4c44b4e8dd674db211c4e6",{"addrType":"pubkey","isPrivkey":false,"isTestnet":false}]
test/base58_tests.cpp(178): error in "base58_keys_valid_parse": !IsValid:["3ALJH9Y951VCGcVZYAdpA3KchoP9McEj1G","5ece0cadddc415b1980f001785947120acdb36fc",{"addrType":"script","isPrivkey":false,"isTestnet":false}]
test/base58_tests.cpp(179): error in "base58_keys_valid_parse": isScript mismatch["3ALJH9Y951VCGcVZYAdpA3KchoP9McEj1G","5ece0cadddc415b1980f001785947120acdb36fc",{"addrType":"script","isPrivkey":false,"isTestnet":false}]
test/base58_tests.cpp(181): error in "base58_keys_valid_parse": addrType mismatch["3ALJH9Y951VCGcVZYAdpA3KchoP9McEj1G","5ece0cadddc415b1980f001785947120acdb36fc",{"addrType":"script","isPrivkey":false,"isTestnet":false}]
Leaving test case "base58_keys_valid_parse"; testing time: 15999mks
Entering test case "base58_keys_valid_gen"
test/base58_tests.cpp(245): error in "base58_keys_valid_gen": mismatch: ["Y91bKDTmGfYWT9uLifCyXA5TgpaAMq6cT5","XQCQa4ZnxVdDwF6fDgaiPuNCwyXWcy3PyewnPhNe5VZmLRZgLU4m",{"addrType":"pubkey","isPrivkey":false,"isTestnet":false}]
test/base58_tests.cpp(245): error in "base58_keys_valid_gen": mismatch: ["1AGNa15ZQXAZUgFiqJ2i7Z2DPU2J6hW62i","65a16059864a2fdbc7c99a4723a8395bc6f188eb",{"addrType":"pubkey","isPrivkey":false,"isTestnet":false}]
test/base58_tests.cpp(245): error in "base58_keys_valid_gen": mismatch: ["3CMNFxN1oHBc4R1EpboAL5yzHGgE611Xou","74f209f6ea907e2ea48f74fae05782ae8a665257",{"addrType":"script","isPrivkey":false,"isTestnet":false}]
test/base58_tests.cpp(220): error in "base58_keys_valid_gen": result mismatch: ["5Kd3NBUAdUnhyzenEwVLy9pBKxSwXvE9FMPyR4UKZvpe6E3AgLr","eddbdc1168f1daeadbd3e44c1e3f8f5a284c2029f78ad26af98583a499de5b19",{"isCompressed":false,"isPrivkey":true,"isTestnet":false}]
test/base58_tests.cpp(220): error in "base58_keys_valid_gen": result mismatch: ["Kz6UJmQACJmLtaQj5A3JAge4kVTNQ8gbvXuwbmCj7bsaabudb3RD","55c9bccb9ed68446d1b75273bbce89d7fe013a8acd1625514420fb2aca1a21c4",{"isCompressed":true,"isPrivkey":true,"isTestnet":false}]
test/base58_tests.cpp(245): error in "base58_keys_valid_gen": mismatch: ["1Ax4gZtb7gAit2TivwejZHYtNNLT18PUXJ","6d23156cbbdcc82a5a47eee4c2c7c583c18b6bf4",{"addrType":"pubkey","isPrivkey":false,"isTestnet":false}]
test/base58_tests.cpp(245): error in "base58_keys_valid_gen": mismatch: ["3QjYXhTkvuj8qPaXHTTWb5wjXhdsLAAWVy","fcc5460dd6e2487c7d75b1963625da0e8f4c5975",{"addrType":"script","isPrivkey":false,"isTestnet":false}]
test/base58_tests.cpp(220): error in "base58_keys_valid_gen": result mismatch: ["5K494XZwps2bGyeL71pWid4noiSNA2cfCibrvRWqcHSptoFn7rc","a326b95ebae30164217d7a7f57d72ab2b54e3be64928a19da0210b9568d4015e",{"isCompressed":false,"isPrivkey":true,"isTestnet":false}]
test/base58_tests.cpp(220): error in "base58_keys_valid_gen": result mismatch: ["L1RrrnXkcKut5DEMwtDthjwRcTTwED36thyL1DebVrKuwvohjMNi","7d998b45c219a1e38e99e7cbd312ef67f77a455a9b50c730c27f02c6f730dfb4",{"isCompressed":true,"isPrivkey":true,"isTestnet":false}]
test/base58_tests.cpp(245): error in "base58_keys_valid_gen": mismatch: ["1C5bSj1iEGUgSTbziymG7Cn18ENQuT36vv","7987ccaa53d02c8873487ef919677cd3db7a6912",{"addrType":"pubkey","isPrivkey":false,"isTestnet":false}]
test/base58_tests.cpp(245): error in "base58_keys_valid_gen": mismatch: ["3AnNxabYGoTxYiTEZwFEnerUoeFXK2Zoks","63bcc565f9e68ee0189dd5cc67f1b0e5f02f45cb",{"addrType":"script","isPrivkey":false,"isTestnet":false}]
test/base58_tests.cpp(220): error in "base58_keys_valid_gen": result mismatch: ["5KaBW9vNtWNhc3ZEDyNCiXLPdVPHCikRxSBWwV9NrpLLa4LsXi9","e75d936d56377f432f404aabb406601f892fd49da90eb6ac558a733c93b47252",{"isCompressed":false,"isPrivkey":true,"isTestnet":false}]
test/base58_tests.cpp(220): error in "base58_keys_valid_gen": result mismatch: ["L1axzbSyynNYA8mCAhzxkipKkfHtAXYF4YQnhSKcLV8YXA874fgT","8248bd0375f2f75d7e274ae544fb920f51784480866b102384190b1addfbaa5c",{"isCompressed":true,"isPrivkey":true,"isTestnet":false}]
test/base58_tests.cpp(245): error in "base58_keys_valid_gen": mismatch: ["1Gqk4Tv79P91Cc1STQtU3s1W6277M2CVWu","adc1cc2081a27206fae25792f28bbc55b831549d",{"addrType":"pubkey","isPrivkey":false,"isTestnet":false}]
test/base58_tests.cpp(245): error in "base58_keys_valid_gen": mismatch: ["33vt8ViH5jsr115AGkW6cEmEz9MpvJSwDk","188f91a931947eddd7432d6e614387e32b244709",{"addrType":"script","isPrivkey":false,"isTestnet":false}]
test/base58_tests.cpp(220): error in "base58_keys_valid_gen": result mismatch: ["5HtH6GdcwCJA4ggWEL1B3jzBBUB8HPiBi9SBc5h9i4Wk4PSeApR","091035445ef105fa1bb125eccfb1882f3fe69592265956ade751fd095033d8d0",{"isCompressed":false,"isPrivkey":true,"isTestnet":false}]
test/base58_tests.cpp(220): error in "base58_keys_valid_gen": result mismatch: ["L2xSYmMeVo3Zek3ZTsv9xUrXVAmrWxJ8Ua4cw8pkfbQhcEFhkXT8","ab2b4bcdfc91d34dee0ae2a8c6b6668dadaeb3a88b9859743156f462325187af",{"isCompressed":true,"isPrivkey":true,"isTestnet":false}]
test/base58_tests.cpp(245): error in "base58_keys_valid_gen": mismatch: ["1JwMWBVLtiqtscbaRHai4pqHokhFCbtoB4","c4c1b72491ede1eedaca00618407ee0b772cad0d",{"addrType":"pubkey","isPrivkey":false,"isTestnet":false}]
test/base58_tests.cpp(245): error in "base58_keys_valid_gen": mismatch: ["3QCzvfL4ZRvmJFiWWBVwxfdaNBT8EtxB5y","f6fe69bcb548a829cce4c57bf6fff8af3a5981f9",{"addrType":"script","isPrivkey":false,"isTestnet":false}]
test/base58_tests.cpp(220): error in "base58_keys_valid_gen": result mismatch: ["5KQmDryMNDcisTzRp3zEq9e4awRmJrEVU1j5vFRTKpRNYPqYrMg","d1fab7ab7385ad26872237f1eb9789aa25cc986bacc695e07ac571d6cdac8bc0",{"isCompressed":false,"isPrivkey":true,"isTestnet":false}]
test/base58_tests.cpp(220): error in "base58_keys_valid_gen": result mismatch: ["L39Fy7AC2Hhj95gh3Yb2AU5YHh1mQSAHgpNixvm27poizcJyLtUi","b0bbede33ef254e8376aceb1510253fc3550efd0fcf84dcd0c9998b288f166b3",{"isCompressed":true,"isPrivkey":true,"isTestnet":false}]
test/base58_tests.cpp(245): error in "base58_keys_valid_gen": mismatch: ["19dcawoKcZdQz365WpXWMhX6QCUpR9SY4r","5eadaf9bb7121f0f192561a5a62f5e5f54210292",{"addrType":"pubkey","isPrivkey":false,"isTestnet":false}]
test/base58_tests.cpp(245): error in "base58_keys_valid_gen": mismatch: ["37Sp6Rv3y4kVd1nQ1JV5pfqXccHNyZm1x3","3f210e7277c899c3a155cc1c90f4106cbddeec6e",{"addrType":"script","isPrivkey":false,"isTestnet":false}]
test/base58_tests.cpp(220): error in "base58_keys_valid_gen": result mismatch: ["5KL6zEaMtPRXZKo1bbMq7JDjjo1bJuQcsgL33je3oY8uSJCR5b4","c7666842503db6dc6ea061f092cfb9c388448629a6fe868d068c42a488b478ae",{"isCompressed":false,"isPrivkey":true,"isTestnet":false}]
test/base58_tests.cpp(220): error in "base58_keys_valid_gen": result mismatch: ["KwV9KAfwbwt51veZWNscRTeZs9CKpojyu1MsPnaKTF5kz69H1UN2","07f0803fc5399e773555ab1e8939907e9badacc17ca129e67a2f5f2ff84351dd",{"isCompressed":true,"isPrivkey":true,"isTestnet":false}]
test/base58_tests.cpp(245): error in "base58_keys_valid_gen": mismatch: ["13p1ijLwsnrcuyqcTvJXkq2ASdXqcnEBLE","1ed467017f043e91ed4c44b4e8dd674db211c4e6",{"addrType":"pubkey","isPrivkey":false,"isTestnet":false}]
test/base58_tests.cpp(245): error in "base58_keys_valid_gen": mismatch: ["3ALJH9Y951VCGcVZYAdpA3KchoP9McEj1G","5ece0cadddc415b1980f001785947120acdb36fc",{"addrType":"script","isPrivkey":false,"isTestnet":false}]
Leaving test case "base58_keys_valid_gen"
Entering test case "base58_keys_invalid"
Leaving test case "base58_keys_invalid"; testing time: 15ms
Leaving test suite "base58_tests"
Entering test suite "base32_tests"
Entering test case "base32_testvectors"
Leaving test case "base32_testvectors"
Leaving test suite "base32_tests"
Entering test suite "allocator_tests"
Entering test case "test_LockedPageManagerBase"
Leaving test case "test_LockedPageManagerBase"
Leaving test suite "allocator_tests"
Entering test suite "accounting_tests"
Entering test case "acc_orderupgrade"
Leaving test case "acc_orderupgrade"; testing time: 1188ms
Leaving test suite "accounting_tests"
Leaving test suite "Bitcoin Test Suite"


If anyone would like to see the MSVC++ versions I could post them too, but they are similar.  The gcc is of interest to me since I can't seem to get any response on https://bitcointalk.org/index.php?topic=149479.msg12510445#msg12510445 asking how to do it, so I posted the bitcoin unit test there

Can anyone tell me how to get makefile.mingw in the src directory to actually create a test_*coind.exe?

I did it, but as I said it is a bit of a hack, but it works!

AFAIK, YACoin is the first and only PoS coin that has a running (gcc on windows) unit test

Ron

[senj]

...
https://github.com/senadj/yacoin/commits/smallpos

Hello Senj,

I have been thinking about the code and wondering if one could "slow down" the PoW "attack" by requiring (or making it more "atractive") to have a PoS block between PoW blocks?

The current miner code, in the daemon & Qt code has this line in the function:
void BitcoinMiner(CWallet *pwallet, bool fProofOfStake)
...

Changing how particular peer mines blocks does not change much - bad miners can edit code, build their own release and produce blocks as they please.
True fix has to be implemented in rules peers use for filtering and accepting those blocks.

My commits do that in two ways (will be three eventually):

• by sharply raising expected difficulty after consecutive PoW block count exceeds ( I refer to this event as overstep ) adjusted PoW/PoS ratio. Here.
• by giving PoW blocks after PoS block higher trust value - higher than currently here (not implemented yet, but it should be only a small change)
• by cutting each overstepped block's trust value in half. Here.

That means branch with less PoS blocks not only scores less chaintrust, but it will be also harder to mine.

[old c coder]

...
https://github.com/senadj/yacoin/commits/smallpos

Hello Senj,

I have been thinking about the code and wondering if one could "slow down" the PoW "attack" by requiring (or making it more "atractive") to have a PoS block between PoW blocks?

The current miner code, in the daemon & Qt code has this line in the function:
void BitcoinMiner(CWallet *pwallet, bool fProofOfStake)
...

Changing how particular peer mines blocks does not change much - bad miners can edit code, build their own release and produce blocks as they please.

Agreed.  But what if we added a rule in accept block or add block or whatever it is called that didn't allow consecutive PoW blocks?  Is there code in those areas to prevent consecutive PoS blocks, or is it only in the mining code?

True fix has to be implemented in rules peers use for filtering and accepting those blocks.

My commits do that in two ways (will be three eventually):

• by sharply raising expected difficulty after consecutive PoW block count exceeds ( I refer to this event as overstep ) adjusted PoW/PoS ratio. Here.
• by giving PoW blocks after PoS block higher trust value - higher than currently here (not implemented yet, but it should be only a small change)
• by cutting each overstepped block's trust value in half. Here.

That means branch with less PoS blocks not only scores less chaintrust, but it will be also harder to mine.

These changes, I presume, have to be run by all the peers(full nodes) to "reject" submitted blocks that don't "measure up"?

Ron

[senj]

...
Changing how particular peer mines blocks does not change much - bad miners can edit code, build their own release and produce blocks as they please.

Agreed.  But what if we added a rule in accept block or add block or whatever it is called that didn't allow consecutive PoW blocks?  Is there code in those areas to prevent consecutive PoS blocks, or is it only in the mining code?

Yacoin is based on Novacoin and that means fast proof-of-stake algorithm - the goal was to eventually accomodate as many PoS blocks as possible kept one minute apart on average. But also to keep PoW blocks at 10 minute spacing. That would one day accomplish ultimate decentralization with proof-of-work "checkpointing" every 10 minutes.
If I am not mistaken, here is how pocopoco's source basically controls it and that didn't change from launch.

Fixes I made also strive towards that goal.

Last time I checked there were near 11x more PoW blocks than PoS blocks. Making PoW-PoS-PoW-PoS order mandatory would probably cause long delays while waiting for PoS block.
There could be other problems too, depending on addressing issues with small PoS blocks.

These changes, I presume, have to be run by all the peers(full nodes) to "reject" submitted blocks that don't "measure up"?

Yes, hard fork is needed. I am certain we can't fix all problems without it.

[Beave162]

To the people who are buying YAC right now, you are just feeding the beast... We need mining power!

[old c coder]

Hi Senj,

...
Changing how particular peer mines blocks does not change much - bad miners can edit code, build their own release and produce blocks as they please.

Agreed.  But what if we added a rule in accept block or add block or whatever it is called that didn't allow consecutive PoW blocks?  Is there code in those areas to prevent consecutive PoS blocks, or is it only in the mining code?

Yacoin is based on Novacoin and that means fast proof-of-stake algorithm - the goal was to eventually accomodate as many PoS blocks as possible kept one minute apart on average. But also to keep PoW blocks at 10 minute spacing. That would one day accomplish ultimate decentralization with proof-of-work "checkpointing" every 10 minutes.

How, in code could one accomplish a 10 minute average PoW block period, I wonder?  If the desire is 9 (up to 9?) PoS blocks, then the code would have to sense the 8 (9 -1) minutes since the last PoW block, and then start PoW-ing on the latest PoS block and on the average, solve for it in 1 minute?

That seems like a 'tall order' to me.  I would think miners would code as soon as they see 1 PoS block.  Now if consecutive (up to 9) PoS blocks had more "weight" than the same number of PoW blocks, perhaps the miners could be "influenced"?

If I am not mistaken, here is how pocopoco's source basically controls it and that didn't change from launch.

Fixes I made also strive towards that goal.

Last time I checked there were near 11x more PoW blocks than PoS blocks. Making PoW-PoS-PoW-PoS order mandatory would probably cause long delays while waiting for PoS block.

I seem to remember that in the past, before this miner and one of the previous versions of YACoin IIRC, that we would have consecutive PoS blocks quite often.  Perhaps the code could "cook" a PoS block if no PoS (or PoW) one appeared after one minute, "randomly" rewarding someone or no one with a minimum PoS amount, whatever that is?  Perhaps a minimum reward to the development team to goad them on to greater heights so that the coin will become popular enough that the minimum reward blocks would not be necessary? Perhaps those rewards could go towards funding a new feature, like the built in explorer or the live price display (LOL).

There could be other problems too, depending on addressing issues with small PoS blocks.

What probelems are there with PoS blocks that are too small?  Is it some kind of flooding the block chain with "dust" as it were?

These changes, I presume, have to be run by all the peers(full nodes) to "reject" submitted blocks that don't "measure up"?

Yes, hard fork is needed. I am certain we can't fix all problems without it.

Just some more idle musings...

Ron

[senj]

...
 the goal was to eventually accomodate as many PoS blocks as possible kept one minute apart on average. But also to keep PoW blocks at 10 minute spacing. That would one day accomplish ultimate decentralization with proof-of-work "checkpointing" every 10 minutes.

How, in code could one accomplish a 10 minute average PoW block period, I wonder?  If the desire is 9 (up to 9?) PoS blocks, then the code would have to sense the 8 (9 -1) minutes since the last PoW block, and then start PoW-ing on the latest PoS block and on the average, solve for it in 1 minute?

Such type of block spacing calculation is already coded. Again, Link. It's just that blocks sequences with fair, community composition don't score enough chaintrust to be considered "main" by peers.

...
Perhaps the code could "cook" a PoS block if no PoS (or PoW) one appeared after one minute, "randomly" rewarding someone or no one with a minimum PoS amount, whatever that is?  Perhaps a minimum reward to the development team to goad them on to greater heights so that the coin will become popular enough that the minimum reward blocks would not be necessary? Perhaps those rewards could go towards funding a new feature, like the built in explorer or the live price display (LOL).

Cooking can be referred to mining or minting. We could also proof-of-stake cook more often, if our blocks wouldn't be ignored.
And what if main chef decides to ignore transactions?

There could be other problems too, depending on addressing issues with small PoS blocks.

What probelems are there with PoS blocks that are too small?  Is it some kind of flooding the block chain with "dust" as it were?

Described here. I am just not sure if presumption about PoS blocks with more stake ever got more trust than those with small stake.

[old c coder]

...
 the goal was to eventually accomodate as many PoS blocks as possible kept one minute apart on average. But also to keep PoW blocks at 10 minute spacing. That would one day accomplish ultimate decentralization with proof-of-work "checkpointing" every 10 minutes.

How, in code could one accomplish a 10 minute average PoW block period, I wonder?  If the desire is 9 (up to 9?) PoS blocks, then the code would have to sense the 8 (9 -1) minutes since the last PoW block, and then start PoW-ing on the latest PoS block and on the average, solve for it in 1 minute?

Such type of block spacing calculation is already coded. Again, Link

Looking at that link, that line in GetNextTargetRequired(...) is calculating nTargetSpacing for both PoS and PoW blocks.  And is a constant for PoS blocks.

I don't quite understand what (60 seconds)*(1 + pindexLast->nHeight - pindexPrev->nHeight) represents for PoW blocks only? Because I don't really know what the context of pindexLast and pindexPrev are themselves?  Or in relation to each other?
Then later, the return value of the function for both PoW and PoS uses the same PoW limit number bnTargetLimit as an upper limit.  Seems "strange", superfluous or wrong, to do it for PoS blocks?  Or am I missing something.  Your proposed changes in this area maintain that "strangeness" at the end of the function.

I would prefer to see a clear block of code for PoS and another for PoW, even if they share some similarity.  Compilers for a long time, I believe, can factor and reduce common sections with no trouble.

Looking at GetNextTargetRequired(), I see that it is called twice by CreateNewBlock(...), first with a PoS block and then with either a PoS or PoW blocks.  And lastly in CBlock::AcceptBlock() for either block.  I can't quite see how all these things are related!  And of course there is no bitcoin documentation!  So your changes in this area are just as opaque to me as the original code.  I predict that I cannot predict the behavior of the old code or your new code!!  Even if all peers/nodes switched tomorrow, I have no clue how this "consensus" code would fare against a miner running his own "ignore PoS blocks" consensus code, or some other exploit!? (LOL)

. It's just that blocks sequences with fair, community composition don't score enough chaintrust to be considered "main" by peers.

...
Perhaps the code could "cook" a PoS block if no PoS (or PoW) one appeared after one minute, "randomly" rewarding someone or no one with a minimum PoS amount, whatever that is?  Perhaps a minimum reward to the development team to goad them on to greater heights so that the coin will become popular enough that the minimum reward blocks would not be necessary? Perhaps those rewards could go towards funding a new feature, like the built in explorer or the live price display (LOL).

Cooking can be referred to mining or minting. We could also proof-of-stake cook more often, if our blocks wouldn't be ignored.
And what if main chef decides to ignore transactions?

There could be other problems too, depending on addressing issues with small PoS blocks.

What probelems are there with PoS blocks that are too small?  Is it some kind of flooding the block chain with "dust" as it were?

Described here.

Looking at that link I see the phrase:

However after recent 51% attack it is not clear yet if pure PoW chain takes less time to make than hybrid chain due to PoW difficulty getting raised after each PoS block.

I thought the change was to up the PoW difficulty after (two) consecutive PoW blocks? Perhaps you meant trust instead of difficulty?  I'm confused since it seems to be the same, PoW difficulty++ after either PoW or PoS block??

I am just not sure if presumption about PoS blocks with more stake ever got more trust than those with small stake.

I guess all I can say is that if we do do these changes, they would have to be "synchronized" by some date-time and or block number or some such so that all s/w switches together.  The bitcoin-ers seem to talk about this a lot, lately, as they contemplate a block size limit change upwards.

Ron

[senj]

GetNextTargetRequired method is used to generate nBits (target in compact format) twice:

1. when creating new block
2. when checking if nBits of a block (could be any block in a tree) conforms to algorithm


When creating PoW block (1), pIndexPrev is a pointer to last PoW block in best chain. If there is PoW block at the tip of the chain, then pIndexPrev = pIndexLast, otherwise we have to search for it backwards with GetLastBlockIndex method. pIndexPrevPrev is a pointer to PoW block preceeding pIndexPrev.


When checking if nBits of a PoW block conforms to block generation rule (2) then pIndexPrev is a pointer to PoW block preceeding it. And as before, pIndexPrevPrev is a pointer to PoW block preceeding pIndexPrev.


The same principle is used for PoS blocks. Just replace all occurences of PoW with PoS in text above.



What "(60 seconds)*(1 + pindexLast->nHeight - pindexPrev->nHeight)" does in case of proof-of-work blocks, it multiplies number of PoS blocks between last PoW block and the one before with 1 minute. If there are no PoS blocks between, then
pindexLast = pindexPrev and height difference in equation equals 0. PoW target spacing is then set to 1 minute.


Yacoin has 1 minute PoS block target spacing.
But PoW block target spacing always was dynamic and it get's wider (PoW difficulty gets higher) in proportion to PoS blocks between last two PoW blocks. It stops growing when 12 sequential PoS blocks are let in.

After PoS block is accepted, target of next PoW block gets adjusted towards 2 minute. Change in difficulty is incremental (exponential retargeting). Nevertheless, selfish miner can mine on lower PoW difficulty if he ignores PoS blocks.


Overall, setting block spacing is only one part of operation. In essence it prescribes block targets for a valid branch.
Currently there are bigger problems with chaintrust calculation - giving correct score to multiple valid branchees thus making possible for peers to choose the best one.

[old c coder]

Hello Senj,

GetNextTargetRequired method is used to generate nBits (target in compact format) twice:

1. when creating new block
2. when checking if nBits of a block (could be any block in a tree) conforms to algorithm


When creating PoW block (1), pIndexPrev is a pointer to last PoW block in best chain

I thought it was the previous block, PoS or PoW.  So pIndexPrev is a special pIndexPrev , actually a pIndexPrevPoW.  I come from a bitcoin mentality where there are only PoW blocks.

. If there is PoW block at the tip of the chain, then pIndexPrev = pIndexLast, otherwise we have to search for it backwards with GetLastBlockIndex method. pIndexPrevPrev is a pointer to PoW block preceeding pIndexPrev.

So pIndexPrevPrev is really a pIndexPrevPrevPoW!  Things get confusing really fast when bitcoin code is taken, modified, and the names of important items (methods, pointers, functions, etc. etc.) aren't changed.

When checking if nBits of a PoW block conforms to block generation rule (2) then pIndexPrev is a pointer to PoW block preceeding it. And as before, pIndexPrevPrev is a pointer to PoW block preceeding pIndexPrev.


The same principle is used for PoS blocks. Just replace all occurences of PoW with PoS in text above.

Not quite sure I understand how to do that?  If pIndexPrevPrev i is really a pIndexPrevPrevPoW , how does that help me find a PoS block(s)?  I seem to be missing something.  That is why I said that it would be nice to have two separate pieces of code, perhaps with lots of commonality, but it would be clearer.  Also better names!  Doesn't everyone's IDE have (prompted for safety)global search and replace?  Or is it only my free MSVC++ Express

What "(60 seconds)*(1 + pindexLast->nHeight - pindexPrev->nHeight)" does in case of proof-of-work blocks, it multiplies number of PoS blocks between last PoW block and the one before with 1 minute. If there are no PoS blocks between, then
pindexLast = pindexPrev and height difference in equation equals 0. PoW target spacing is then set to 1 minute.


Yacoin has 1 minute PoS block target spacing.
But PoW block target spacing always was dynamic and it get's wider (PoW difficulty gets higher) in proportion to PoS blocks between last two PoW blocks. It stops growing when 12 sequential PoS blocks are let in.

But if it is PoW easier to have less PoS blocks (PoW harder to have more PoS blocks) doesn't that play into the hands of GM ("greedy miner")?

After PoS block is accepted, target of next PoW block gets adjusted towards 2 minute.

But isn't time counted (on the average) from the moment of the PoS block acceptance?  Seems to me that is still 1 minute to the next block.  Isn't the PoS Merkle etc. part of the "best chain" at this moment?  Or am I missing something?

Change in difficulty is incremental (exponential retargeting). Nevertheless, selfish miner can mine on lower PoW difficulty if he ignores PoS blocks.

I would think that an "inducement" to keep PoS blocks by reversing the above change in PoW difficulty, would "entice" GM to take the current best chain with PoS block(s) since it's PoW difficulty would be trending down.  A question would be how to keep a flood of "cheap" PoS blocks from happening?  If GM can "propose" PoS blocks that are "better" (whatever the criteria are) then so be it.  But if another PoS block of "better worth" is simultaneously "proposed" (broadcasted), I would think that the "consensus" s/w should pick the better one.

Overall, setting block spacing is only one part of operation. In essence it prescribes block targets for a valid branch.
Currently there are bigger problems with chaintrust calculation - giving correct score to multiple valid branchees thus making possible for peers to choose the best one.

I have no idea what that means (LOL).  Correct score? Trust calculation? What and where are those items?

Ron

[senj]

Things get confusing really fast when bitcoin code is taken, modified, and the names of important items (methods, pointers, functions, etc. etc.) aren't changed.

I agree figuring out what the code does can be difficult. I've been analyzing it for almost a year, since I was made aware of it's flaws.
Perhaps it would make more sense if I mentioned method's signature:

Code:

unsigned int static GetNextTargetRequired(const CBlockIndex* pindexLast, bool fProofOfStake)

Second input parameter also determines block type on which pIndexPrev and pIndexPrevPrev point. When you generate nBits for PoW block, you pass false. pIndexPrev then points to PoW block as does pIndexPrevPrev.

That is why I've written:

The same principle is used for PoS blocks. Just replace all occurences of PoW with PoS in text above.

That really means: "Just pass true for fProofOfStake"   

...But isn't time counted (on the average) from the moment of the PoS block acceptance?...

Time is taken into account later in the same function. First nTargetSpacing is calculated. Then real time difference is thrown into equation. If those two blocks pointed by pIndexPrev and pIndexPrevPrev are less than nTargetSpacing apart, difficulty is raised (nBits get's lowered).

I have no idea what that means (LOL).  Correct score? Trust calculation? What and where are those items?

Chaintrust is what I had in mind. It's all over there.

[aso118b]

You guys are throwing a round a lot of good stuff - most of which is over my head.  I'm glad to see that both of you are activity working on fixing the outstanding issues.  I hope see them resolved soon!

[old c coder]

Things get confusing really fast when bitcoin code is taken, modified, and the names of important items (methods, pointers, functions, etc. etc.) aren't changed.

I agree figuring out what the code does can be difficult. I've been analyzing it for almost a year, since I was made aware of it's flaws.
Perhaps it would make more sense if I mentioned method's signature:

Code:

unsigned int static GetNextTargetRequired(const CBlockIndex* pindexLast, bool fProofOfStake)

Second input parameter also determines block type on which pIndexPrev and pIndexPrevPrev point. When you generate nBits for PoW block, you pass false. pIndexPrev then points to PoW block as does pIndexPrevPrev.

That is why I've written:

The same principle is used for PoS blocks. Just replace all occurences of PoW with PoS in text above.

That really means: "Just pass true for fProofOfStake"   

It seems to me that the underlying imperative of this (original?) code is to save (.exe) file space by compressing code and reusing functions for multiple uses.  Here GetNextTargetRequired(...) is used for both PoW and PoS blocks.  This results in actually slower code (potentially, unless the optimizer can save the day) and more opaque/obscure code to boot!

I see that that 2nd argument fProofOfStake is tested over and over again.  That is why I suggested that this PoW & PoS coin should have two separate sections inside GetNextTargetRequired() and probably inside GetLastBlockIndex(...) too!  If this is called a lot, I see it called by CBlock::AcceptBlock(), which is called by ProcessBlock(...) I would think we could improve performance a wee bit by not testing something that isn't changing, over and over again!

I don't even understand the comment for GetLastBlockIndex(...)
// ppcoin: find last block index up to pindex
const CBlockIndex* GetLastBlockIndex(const CBlockIndex* pindex, bool fProofOfStake)

What is pindex, and what is the last block index that this is finding?  For PoS and PoW flags and the type of the blocks pointed to by pindex?  Or should I know what type that is already?  This comment (documentation???) doesn't really help me at all (LOL)  No wonder it has taken you a year to grok this!  And no wonder the bitcoin source code, after 6 years (!), still isn't really understood by anyone in an understandable way!   And that is why the changes are so glacially slow.  There is no "consensus" library code (.a, .dll, .lib etc.) because no one knows WTF is going on

...But isn't time counted (on the average) from the moment of the PoS block acceptance?...

Time is taken into account later in the same function. First nTargetSpacing is calculated. Then real time difference is thrown into equation. If those two blocks pointed by pIndexPrev and pIndexPrevPrev are less than nTargetSpacing apart, difficulty is raised (nBits get's lowered).

I don't thionk I can even attempt to understand your paragraph above until I can understand the (sub)function GetLastBlockIndex(..)

I have no idea what that means (LOL).  Correct score? Trust calculation? What and where are those items?

Chaintrust is what I had in mind. It's all over there.

Yikes!  More ill-documented functions, InvalidChainFound(...)
CBlockIndex::GetBlockTrust()
IsSuperMajority(...)

I think it is more important to document and  rename (refactor if you will) ill named variables (nouns) and functions (verbs) so that one can read the code and not have to constantly translate what it says into what it means!  It is impossible to do that if one doesn't know what it means!! 

I have no problem with changes, but at least clean up and clarify (make more transparent, understandable, clear) what surrounds your changes.

Actually I'd like to do it to do it to all of the bitcoin source and the source of every other crypto currency.  I would like it if Yacoin was the first to do it!

It would be so easy then to make replaceable libraries, build new GUIs, add features, etc. etc., but hey, nobody reads Martin Fowler, Joel Spolsky, ... anymore.  Or even knows who they are! 

Ron

[Roister01]

Hi folks,

Does anyone know why my minted coins are not confirming? They arrive, get to one confirmation, then get rejected...This has happened quite a few times. What should I do?

Cheers,

Roister