for future use, here is the graviex.com listing request form:
https://docs.google.com/forms/d/e/1FAIpQLSeFC98OclfkdMKcmwntfTOayung5CgykG_SBxbedCm8NLprWw/formResponse
Topic: [ANN] NDL - The coin for Pastafarians - Flying Spaghetti Monster Cryptocurrency! - page 15. (Read 125161 times)
November 04, 2018, 09:23:16 AM
November 04, 2018, 06:03:59 AM
@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.
November 04, 2018, 03:51:41 AM
@Chicago. I am confused, what is the the negative thing/result that you are concerned with?
November 04, 2018, 12:17:16 AM
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
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.
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.
Then later in code, if the block header doesn't contain the required version we see the blocks are rejected.
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
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
November 03, 2018, 02:54:53 PM
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.
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.
November 03, 2018, 01:41:13 PM
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.
November 02, 2018, 10:44:46 PM
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.
November 01, 2018, 02:43:29 AM
Quote
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?
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.
November 01, 2018, 01:49:58 AM
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?
November 01, 2018, 01:46:40 AM
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.
October 31, 2018, 10:43:10 PM
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:
Same values as the previous versions of the Noodlyappendagecoin wallet.
That's my cluster of noodles....anyone have any ideas as to the cause?
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(1,53);
base58Prefixes[SCRIPT_ADDRESS] = std::vector(1,5);
base58Prefixes[SCRIPT_ADDRESS2] = std::vector(1,53);
base58Prefixes[SECRET_KEY] = std::vector(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?
October 28, 2018, 07:18:56 PM
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
Heave ho and use a passphrase of 10 or more random characters, or eight or more words" 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.
October 28, 2018, 07:07:52 PM
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
October 28, 2018, 07:04:50 PM
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.
October 28, 2018, 06:59:36 PM
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.
October 28, 2018, 06:53:55 PM
Quote
i also simply donot have the time to do this sort of juggling act. coins.dognose.net will have to cease NDL support.
I was unaware that it was that significant. This is a beta and part of that beta process is discovering these things before it goes fully live. I'll will prioritize stratum support.
October 28, 2018, 06:50:24 PM
It just means you have to use a miner that supports longpolling. Cpuminer is one of the ones that can do that. Its possible your current external mining program likely supports longpolling, so you aren't losing that mining method. Which miner are you using?
i use in-wallet cpu mining for NDL to avoid overwhelming the network.
i have a stratum-only daemon providing interface to all the altcoins i support at coins.dognose.com
i do not run external standalone mining software, my asic boxes talk to the stratum daemon ports using the software their
manufacturer provides internally to the box.
i'm already using nearly 19gig of a 24gig linux system supporting all the various mining tools, daemons, explorers, database
interfaces, etc. i dont intend on running more software just to support NDL, i still want to support several other
older altcoins. my system cannot support more crap running.
i also simply do not have the time to do this sort of juggling act. coins.dognose.net will have to cease NDL support.
October 28, 2018, 06:42:00 PM
You just have to use
-Wallet no longer supports in-wallet Mining
-Wallet no longer supports "Stratum" mining
deal breaker. the only two ways i mine. especially in-wallet cpu mining because any ASIC will overwhelm the current network size.
It just means you have to use a miner that supports longpolling. Cpuminer is one of the ones that can do that. Its possible your current external mining program likely supports longpolling, so you aren't losing that mining method. Which miner are you using?
-Wallet no longer supports in-wallet Mining
-Wallet no longer supports "Stratum" mining
deal breaker. the only two ways i mine. especially in-wallet cpu mining because any ASIC will overwhelm the current network size.
It just means you have to use a miner that supports longpolling. Cpuminer is one of the ones that can do that. Its possible your current external mining program likely supports longpolling, so you aren't losing that mining method. Which miner are you using?
October 28, 2018, 06:37:29 PM
-Wallet no longer supports in-wallet Mining
-Wallet no longer supports "Stratum" mining
deal breaker. the only two ways i mine. especially in-wallet cpu mining because any ASIC will overwhelm the current network size.
and dont give me that "avoiding false-postiives from antivirus software" bullpucky. altcoins have been surving that issue for
years now. THAT problems likes with the antivirus vendors and people should not raise their asses up to accomodate AV
lazy heuristics.
October 28, 2018, 04:37:56 PM
The Noodlyappendagecoin Wallet 16.3 (BETA) has several new details:
THIS IS A BETA! BE CAREFUL!
-Old NDL paperwallet addresses are no longer importable through the console, though it does seem to work with old wallet.dat files just fine.
-You can see a visual list of nodes in the console and right click to ban them as you see fit
-Support for BIP34,BIP65, and BIP66 will initiate at block 1365000 (approximately November 17-20, 2018)
-Support for BIP68, BIP112, BIP113, SegWit (BIP141, BIP143, BIP147) deployment to begin November 22, 2018 (subject to network consensus)
-Potential change of the pchMessageStart to "NDLY"
-"HD" Private Key Generation code has been added but not enabled
-Wallet no longer supports in-wallet Mining
-Wallet no longer supports "Stratum" mining
-Wallet now supports "Long-polling" mining (this typically requires that you will have to specify the address to which the mining amount will be sent to; a new address will no longer be auto generated)
-Noodlyappendagecoin balance can be shown in Noodlyappendagecoins, Noodles, and tips. (1 NDL, 1/10 NDL, 1/100 NDL)
-All transactions now require a payment of 0.001 NDL/kb (and is clearly displayed in the "Send" tab)
-Probably other things I can't think of right now.
THIS IS A BETA! BE CAREFUL!
-Old NDL paperwallet addresses are no longer importable through the console, though it does seem to work with old wallet.dat files just fine.
-You can see a visual list of nodes in the console and right click to ban them as you see fit
-Support for BIP34,BIP65, and BIP66 will initiate at block 1365000 (approximately November 17-20, 2018)
-Support for BIP68, BIP112, BIP113, SegWit (BIP141, BIP143, BIP147) deployment to begin November 22, 2018 (subject to network consensus)
-Potential change of the pchMessageStart to "NDLY"
-"HD" Private Key Generation code has been added but not enabled
-Wallet no longer supports in-wallet Mining
-Wallet no longer supports "Stratum" mining
-Wallet now supports "Long-polling" mining (this typically requires that you will have to specify the address to which the mining amount will be sent to; a new address will no longer be auto generated)
-Noodlyappendagecoin balance can be shown in Noodlyappendagecoins, Noodles, and tips. (1 NDL, 1/10 NDL, 1/100 NDL)
-All transactions now require a payment of 0.001 NDL/kb (and is clearly displayed in the "Send" tab)
-Probably other things I can't think of right now.
Jump to: