[ANN] NDL - The coin for Pastafarians - Flying Spaghetti Monster Cryptocurrency!

[number435398]

THIS IS A BETA!  BE CAREFUL!

side issue:
 have you modified the  messages from this new code to use various permutations of Priate Talk and FSM references?

the FUN aspect in the coin, imho, is critical to its acceptance.

No, I haven't.  Though I am open to any contributions you may have to offer.

[1713576232]

1713576232

[1713576232]

1713576232

[1713576232]

1713576232

[1713576232]

1713576232

[dnp]

THIS IS A BETA!  BE CAREFUL!

side issue:
 have you modified the  messages from this new code to use various permutations of Priate Talk and FSM references?

the FUN aspect in the coin, imho, is critical to its acceptance.

No, I haven't.  Though I am open to any contributions you may have to offer.

look at the old code

[number435398]

THIS IS A BETA!  BE CAREFUL!

side issue:
 have you modified the  messages from this new code to use various permutations of Priate Talk and FSM references?

the FUN aspect in the coin, imho, is critical to its acceptance.

No, I haven't.  Though I am open to any contributions you may have to offer.

look at the old code

Like ""Enter a new wallet passphrase yer pox-faced bilge-rat<br/>Heave ho and use a passphrase of <b>10 or more random characters</b>, or <b>eight or more words</b>" from askpassphrasedialogue.cpp?

I saw a few others in that file, but that's all I've found so far.  Are there other phrases you're thinking of that you've seen there?  I'm really not all that creative with such things and I'm having a hard enough time finding time to work on the wallet as it is.

[number435398]

Could use some input from you guys.  Having problems w the addresses in the new wallet.  I can't create a new address w/o having a problem.  Using an old wallet.dat file works fine, but creating new addresses does not.

Try this.  The new wallet generates the address Ne69bEY7oWttrWDmQVY15qhrjzSv8giheN within the "receiving addresses" window.  Then, when typing "dumpprivkey" it states: "Private key for address Ne69bEY7oWttrWDmQVY15qhrjzSv8giheN is not known (code -4)"

When I try "dumpwallet" I find that the address (based upon the label) is really "NDyZSu4cL529rAqzgdbFt8VPPJLsfeiuDp".  When I mine to that dumpwallet address and check the explorer, it states that nothing went there.  So I tried to mine it while tracking it closely.

Tried it a few times, but just tried and created block 1336387 which contains tx "c11ae4a88729c56ace369f4ece5255098ca9ae9b0066e6b34669eb344794e7e0".  Which is the coinbase transaction for the address: "NdKAS1Mu3FV2fbz5i3vaNFmB1obpJzprM4".  The wallet does not acknowledge the mined transaction as being part of my list.  If I "dumpprivkey" the address specified in the "wallet" it gives me the privkey, yet this address is not reflected in my "receiving addresses".

But get this, I can mine to the original "Ne69bEY7oWttrWDmQVY15qhrjzSv8giheN", as confirmed by the explorer, but it doesn't show up in the wallet.  Perhaps one could say, why should it if the wallet doesn't have the private key for it?

I used:

Code:

base58Prefixes[PUBKEY_ADDRESS] = std::vector<unsigned char>(1,53);
base58Prefixes[SCRIPT_ADDRESS] = std::vector<unsigned char>(1,5);
base58Prefixes[SCRIPT_ADDRESS2] = std::vector<unsigned char>(1,53);
base58Prefixes[SECRET_KEY] =     std::vector<unsigned char>(1,181);

Same values as the previous versions of the Noodlyappendagecoin wallet.

That's my cluster of noodles....anyone have any ideas as to the cause?

[dnp]

That's my cluster of noodles....anyone have any ideas as to the cause?

no actual clue, but with encryption type stuff in general perhaps
there is a salt/seed/initial value somewhere used by the base58 routines that is different for LTC than
for NDL.

[dnp]

That's my cluster of noodles....anyone have any ideas as to the cause?

no actual clue, but with encryption type stuff in general perhaps
there is a salt/seed/initial value somewhere used by the base58 routines that is different for LTC than
for NDL.

i also seem to have a fuzzy recollection that LTC supported a legacy address that started with "3" instead of "L"
perhaps that legacy code is influencing things somehow?

[number435398]

i also seem to have a fuzzy recollection that LTC supported a legacy address that started with "3" instead of "L"
perhaps that legacy code is influencing things somehow?

To the extent that I understand it, that's in the second line of the code I showed.  The (1,5).  That's in NDL code too.  I think its for multi-sig addresses.

[number435398]

The only thing I can see that is keeping the new wallet from being fully deployable is the address problem.  Anyone who has any ideas, even if its one I will simply shoot down, may be of help.  Once the address problem is addressed and the wallet is deployed, we can implement the appropriate BIPs so that we can be traded.

[dnp]

The only thing I can see that is keeping the new wallet from being fully deployable is the address problem.  Anyone who has any ideas, even if its one I will simply shoot down, may be of help.  Once the address problem is addressed and the wallet is deployed, we can implement the appropriate BIPs so that we can be traded.

i wont have real free time until the end of november, but i can probably fit 1 or 2 hours a week until then.
so, should be able to solve the problem within a week lol...
[dammit EGO, get back in your box!]

where can i download your current source version?
where can i download the LTC base source that you used?
give a clear description of the problem, please avoid short forms and slang since we are probably
not of the same generation or country.

[number435398]

Litecoin 16.3, I'm trying something new right now though.  What I'm thinking is that by changing some parts of the code, somehow I disabled the proper address equation (which I didn't think was the case before).

I took the most recent iteration I had of the wallet and changed the addresses back to the litecoin values...and it also failed.  Leading me to the conclusion that its either some inherent error in the litecoin code, or by changing something like "LTC" to "NDL" or "Litecoin" to "Noodlyappendagecoin" somehow altered the address code value....don't ask me how the hell that would do that, but that appears to be the case.

[Chicago]

Hello,

    Here's my take on Litecoin and derivatives of the Bitcoin 0.16 branch (or really anything newer than the 0.13 branch).

    The part I have the most concern with in the 16.3 code starts here:
    https://github.com/bitcoin/bitcoin/blob/49e34e288005a5b144a642e197b628396f5a0765/src/chainparams.cpp#L80-L83

Code:

consensus.BIP34Height = 227931;
consensus.BIP34Hash = uint256S("0x000000000000024b89b42a942fe0d9fea3bb44ab7bd1b19115dd6a759c0808b8");
consensus.BIP65Height = 388381; // 000000000000000004c2b624ed5d7756c508d90fd0da2c7c679febfa6c4735f0
consensus.BIP66Height = 363725; // 00000000000000000379eaa19dce8c9b722d46ae6a57c2f1a988119488b50931

    The way I understand it, consensus.BIP34Height, consensus.BIP34Hash, consensus.BIP65Height and consensus.BIP66Height indicate where in the blockchain you may find the new features having been activated through the IsSuperMajority() method.

    In other words, IsSuperMajority() evaluates the criteria for when the soft-forks became active.
    Prior to the 0.14 branch, consensus.BIP65Height and consensus.BIP66Height did not even occur in code and the IsSuperMajority() method is how the wallet knew to enforce new protocol.

    Right now, we are producing version 2 blocks. Here is an example getblock call from the RPC.

Code:

{
    "hash" : "4897b09eacd83654797e02b2d4b150db1c609dcbfe87c65657624aff33fd597b",
    "confirmations" : 1,
    "size" : 189,
    "height" : 1317286,
    "version" : 2,
    "merkleroot" : "2981da99a400e59a43f8b65f18ce9167d2755d840c616e87836b99a62176c172",
    "tx" : [
        "2981da99a400e59a43f8b65f18ce9167d2755d840c616e87836b99a62176c172"
    ],
    "time" : 1541303715,
    "nonce" : 469045,
    "bits" : "1e0fffff",
    "difficulty" : 0.00024414,
    "previousblockhash" : "aaab82bf6e31a42bfe3e8cd8885b9a412b9cd1b0b8c770efcd07e8a615caebc9"
}

    The way IsSuperMajority() works is that once a percentage threshold of blocks with the newer version number have been added to the chain; then BIP34, BIP66 and BIP65 would become active.
    Here is the code from src/main.cpp for reference.

Code:

    // Enforce block.nVersion=2 rule that the coinbase starts with serialized block height
    // if 750 of the last 1,000 blocks are version 2 or greater (51/100 if testnet):
    if (block.nVersion >= 2 && IsSuperMajority(2, pindexPrev, consensusParams.nMajorityEnforceBlockUpgrade, consensusParams))
    {
        CScript expect = CScript() << nHeight;
        if (block.vtx[0].vin[0].scriptSig.size() < expect.size() ||
            !std::equal(expect.begin(), expect.end(), block.vtx[0].vin[0].scriptSig.begin())) {
            return state.DoS(100, false, REJECT_INVALID, "bad-cb-height", false, "block height mismatch in coinbase");
        }
    }

    // Start enforcing the DERSIG (BIP66) rules, for block.nVersion=3 blocks,
    // when 75% of the network has upgraded:
    if (block.nVersion >= 3 && IsSuperMajority(3, pindex->pprev, chainparams.GetConsensus().nMajorityEnforceBlockUpgrade, chainparams.GetConsensus())) {
        flags |= SCRIPT_VERIFY_DERSIG;
    }

    // Start enforcing CHECKLOCKTIMEVERIFY, (BIP65) for block.nVersion=4
    // blocks, when 75% of the network has upgraded:
    if (block.nVersion >= 4 && IsSuperMajority(4, pindex->pprev, chainparams.GetConsensus().nMajorityEnforceBlockUpgrade, chainparams.GetConsensus())) {
        flags |= SCRIPT_VERIFY_CHECKLOCKTIMEVERIFY;
    }

    Then later in code, if the block header doesn't contain the required version we see the blocks are rejected.

Code:

    // Reject outdated version blocks when 95% (75% on testnet) of the network has upgraded:
    for (int32_t version = 2; version < 5; ++version) // check for version 2, 3 and 4 upgrades
        if (block.nVersion < version && IsSuperMajority(version, pindexPrev, consensusParams.nMajorityRejectBlockOutdated, consensusParams))
            return state.Invalid(false, REJECT_OBSOLETE, strprintf("bad-version(0x%08x)", version - 1),
                                 strprintf("rejected nVersion=0x%08x block", version - 1));

    More simply, unless some other code is used to create block versions greater than 2, it would appear we could expect blocks to be rejected after any arbitrary hard-coded heights in src/chainparams.cpp.

    I don't know whether my concerns are well founded.

    I suspect since consensus.vDeployments[Consensus::DEPLOYMENT_CSV].nStartTime will lead to a block version greater than 2 being created that perhaps whatever height you are hard-coding into src/chainparams.cpp should be far enough into the future that it will occur well after consensus.vDeployments[Consensus::DEPLOYMENT_CSV].nStartTime starts producing blocks.

Best Regards,
-Chicago
   

[number435398]

@Chicago.  I am confused, what is the the negative thing/result that you are concerned with?

[Chicago]

@Chicago.  I am confused, what is the the negative thing/result that you are concerned with?

I'm afraid of the potential outcome where the two BIP9 deployments fail in v0.16.3 and as a consequence, there would not be enough greater than version 2 blocks to enforce ISM for BIP66 and BIP65.
The first reason to upgrade the network is for BIP66.

It should be the primary goal.
Creating a Noodlyappendagecoin based on upstream Bitcoin v0.13.0 would do it.

[layer1gfx]

for future use, here is the graviex.com listing request form:
https://docs.google.com/forms/d/e/1FAIpQLSeFC98OclfkdMKcmwntfTOayung5CgykG_SBxbedCm8NLprWw/formResponse

[nxtraordinary]

for future use, here is the graviex.com listing request form:
https://docs.google.com/forms/d/e/1FAIpQLSeFC98OclfkdMKcmwntfTOayung5CgykG_SBxbedCm8NLprWw/formResponse

If I have seen it right, their 3000000 GIO Coins requested for listing would cost abt. 1300 USD at the moment of writing (depending also on the btc spot - if it falls through the side-range during the next days or few weeks - which is what I believe - it could be less).

The graviex team is from russia and acting from Malta. Hm. How perfect this is for a fun Coin! ;-)

____

I only hope the programming efforts by you brave ones here won't destroy or split the coin over the next weeks. I am not sure if I should further mine it, because I am not sure, if the chain of our block explorer still is the only one, or if another one is actually being prepared in the background.

Anyway, I am ready to support the guys in that thread by noodly touches where ever I can. By the way: That DOESN'T mean that we should keep up the illusion of a pressure in time - there's enough time, while we still are in a rough bear market outside! So, why that hard pace? So:

30.000.000 NDL coins for a well tested NDL wallet Version (and yes, - a testnet is indeed helpful, everyone acting proffessional uses one, to ensure his coins survival, instead of any unwanted headless acting). And - if two or three persons work on it together - each of them will get that amount.
But, please: Really think and work TOGETHER. So far this has been never a problem in this thread, but it might be one in the future, if anyone feels too much pressure to succeed fast without need.


Greez,
n.

[number435398]

I only hope the programming efforts by you brave ones here won't destroy or split the coin over the next weeks. I am not sure if I should further mine it, because I am not sure, if the chain of our block explorer still is the only one, or if another one is actually being prepared in the background.

Even with my wallet, there is no such fork.  The wallet, as currently programmed (where it has some address problems) will not fork the network for several weeks from now, but its just a beta anyhow.  The current block explorer will not accept that fork anyhow.  Once I finish it, I will hardcode another checkpoint to ensure the explorer is correct.  This does mean, however, that if someone is on some other fork, that fork will be ignored. 

I am following the explorer for the main network.  If you think you are on a fork that does not correlate with the explorer, then I would advise taking steps to connect it to the explorer so that whichever fork is strongest will take hold.  Even if that means running my old one that I called "0.0.3".  Or even running my beta wallet right now; it connects to the explorer too.  Just be weary of any addresses my new wallet makes; still working on that.

[number435398]

I am still learning how the GitHub desktop works.  For months it wouldn't even run for me, so I'm a bit behind on that.

I have uploaded my source code:

https://github.com/number435398/Noodlyappendagecoin-project


To build it, if you have all the dependencies type ./trythis; or edit the trythis file and you'll see the necessary commands, whichever you prefer.  Just make sure trythis, autogen.sh, configure.ac and /share/genbuild.sh are set to "Allow executing file as program".  For some reason I have to continually change that.

As is the wallet creates valid addresses, but will not track the addresses it creates on the balance sheet (I don't know why that is).  It will track, however, any existing addresses on a wallet.dat file.

[dnp]

I am still learning how the GitHub desktop works.  For months it wouldn't even run for me, so I'm a bit behind on that.

I have uploaded my source code:

https://github.com/number435398/Noodlyappendagecoin-project

in src/validation.cpp you added a type reference "u_int64" in a couple places
this is not a standard type.

this particular source package uses uint64_t everywhere else, even within validation.cpp

and if you do need to reference a non-basic type for a new variable, make sure the configure script
has a recipe to test for its existence, and if not exists, unleash a sutiable definition in a .h
file somewhere.


your 'trythis' script mentions doing a make while in the 'depends' folder. there is no Makefile in that folder.

it also does an 'apt' get. not all versions of linux or bsd support apt as a package manager (mine does not), if you want to make sure a certain package is installed the configure script is the appropriate place to put a test recipe and a message to the user to fetch the damn thing themselves if the library and/or headers are missing. (or perhaps simply state the package is missing -- with less colourful language than i am prone to.)

by the way, i was not doing a Mingw type build but a native linux non-gui daemon build. i find debugging is much easier without GUI api stuff getting in the way.
i'm guessing u_int64 is a Mingw-ism ? (aka Micorsoft-ism?)

[number435398]

I am still learning how the GitHub desktop works.  For months it wouldn't even run for me, so I'm a bit behind on that.

I have uploaded my source code:

https://github.com/number435398/Noodlyappendagecoin-project

in src/validation.cpp you added a type reference "u_int64"
this is not a standard type.

this particular source package uses uint64_t everywhere else,
and if you do need to reference a non-basic type for a new variable, make sure the configure script
has a recipe to test for its existence, and if not exists, unleash a sutiable definition in a .h
file somewhere.


your 'trythis' script mentions doing a make while in the 'depends' folder. there is no Makefile in that folder.
it also does an 'apt' get. not all versions of linux or bsd support apt as a package manager (mine does not), if you want to make sure a certain package is installed the configure script is the appropriate place to put a test recipe and a message to the user to fetch the damn thing themselves if the library and/or headers are missing. (or perhaps simply state the package is missing -- with less colourful language than i am prone to.)

I have had no problems with the source I uploaded with regards to the validation.cpp.  Are you suggesting I establish that as a "uint64_t" as a general rule or are you having problems?  Block 1 will not validate if that is not accepted, and I have experienced no problems therewith.

To confirm, you are concerned about the following code:

Code:

static const u_int64 TOTAL_GENERATION = MAX_MONEY;
static const double FSM_FUNDS = 0.03;
u_int64 nSubsidy = 10000 * COIN;

Yes, you're right on the 'apt get', I meant to remove that.

Line 8 is "cd .." which takes one out of the depends folder for "make".

[dnp]

I have had no problems with the source I uploaded with regards to the validation.cpp.  Are you suggesting I establish that as a "uint64_t" as a general rule or are you having problems?  Block 1 will not validate if that is not accepted, and I have experienced no problems therewith.

To confirm, you are concerned about the following code:

Code:

static const u_int64 TOTAL_GENERATION = MAX_MONEY;
static const double FSM_FUNDS = 0.03;
u_int64 nSubsidy = 10000 * COIN;

Yes, you're right on the 'apt get', I meant to remove that.

Line 8 is "cd .." which takes one out of the depends folder for "make".

yes, use uint64_t, do not use u_int64.
it will NOT compile in a non-Mingw environment (both linux and Mac)

the cd in the copy of trythis i got from github occurs AFTER the call to 'sudo make -j4 HOST=x86_64-w64-mingw32'. (ie: make is line 7, cd is line 8, another make without args on line 11