Pages:
Author

Topic: [ANN] NDL - The coin for Pastafarians - Flying Spaghetti Monster Cryptocurrency! - page 9. (Read 125323 times)

jr. member
Activity: 260
Merit: 6
so why not starting a new thread? i think you are the main driving force since a while so it would be ok i think if you just start a new ANN with the newest version including relevant info from the old post. what do the other pirates think?

I won't say much right now, but let's just say there are some things in the works.  DaveF has done and continues to do a lot behind the scenes too.
member
Activity: 324
Merit: 79
so why not starting a new thread? i think you are the main driving force since a while so it would be ok i think if you just start a new ANN with the newest version including relevant info from the old post. what do the other pirates think?
jr. member
Activity: 260
Merit: 6
arrrrr
nice to see some of you chefs keep refining the recipe of the holy ramen soup.
how about starting with a new thread since so much has been changed already since the first post of this one?

Been thinking of that a bit myself.
legendary
Activity: 2128
Merit: 1109
Graphic Design & Translation - BTC accepted here!
arrrrr
nice to see some of you chefs keep refining the recipe of the holy ramen soup.
how about starting with a new thread since so much has been changed already since the first post of this one?
legendary
Activity: 3500
Merit: 6320
Crypto Swap Exchange
I updated the website to use the new wallets and added a link to the number435398 github.
If anyone sees anything wrong please post here to let me know.
I think I have everything but more eyes are always useful.

-Dave
jr. member
Activity: 260
Merit: 6
Looks like the forks went through without a hitch!  So now we can start looking into being traded as we have all the up to date protocols that are required in this day and age of cryptocurrency trading!
jr. member
Activity: 260
Merit: 6

If you don't mind, specifically, which lines in which files did you have to change?  I can at least compare what you changed to the saved state of the linux VM I used to compile the linux binaries with.

compare a fresh complete checkout of your own github with your saved VM.
looking at the 3 files i changed probably wont find all the differences.

presumably the saved VM was 'working' code base
make your github match exactly what you sucessfully build.


Because there shouldn't be any differences.  I'm skeptical to the idea that I changed the files at all, but it's been so long I don't remember.  The easiest way to verify that would be to see if I made the same changes you did and just didn't remember.  If my files aren't changed the way yours are then that would suggest its merely our different setups.  I don't even know of an easy way to compare the folder in my vm to my github.  Every time I get into that stuff it turns into some nightmare.

Edit:
When I compiled these I wasn't working.  Now I work 7 days a week.  I don't have the time I had when I was building these.
dnp
full member
Activity: 401
Merit: 110

If you don't mind, specifically, which lines in which files did you have to change?  I can at least compare what you changed to the saved state of the linux VM I used to compile the linux binaries with.

compare a fresh complete checkout of your own github with your saved VM.
looking at the 3 files i changed probably wont find all the differences.

presumably the saved VM was 'working' code base
make your github match exactly what you sucessfully build.
jr. member
Activity: 260
Merit: 6
dnp
full member
Activity: 401
Merit: 110
[putting on grumpy old man retired compiler developer hat]

okay, i'll try to explain the source code situation (that deserves one or more litecoin developers to be slapped.)

first, a lesson on C/C++ coding and the language sourcefile preprocessor.

you can have included/header files of various definitions, they are referenced in source
by one of two syntaxes:
  #include
or
  #include "filename"

they basically do the same thing. but don't. they find the referenced filename by a set of "search rules"
on which system and local project folders to look for them and in what order.
some locations are built into the preprocessor command as defaults for the language standard include
files. other locations may be supplied on the compile time invocation of C/C++ (and buried in a maze
of bulky text in the Makefile structure for these larger projects.)

the thing is, the defaults for order of search folders is slightly different between the and "f" syntax.

for general sanity, one should use the syntax for external packages and system/compiler supplied stuff, and the "f" syntax for the current project's code.

lesson over, now what happened:

some litecoin 'coder' foolishly decided it was okay to have multiple files in the same code project have the same filename. they just were in slightly different subfolders.
a couple of these files were the include files referenced by #include directives.

the source files needing them found them by using the syntax of #include -- which is not so much wrong and just avoided by people who know the potential pain.
the local project should be using the "f" syntax for referencing its own local header files.

now it appears that number435398 'fixed' these OCD aggravating #include references to use double quotes instead of the angle brackets.
but that resulted in the *other* (wrong) version of the same file name being found and used -- which led to compile time syntax errors.

specifically, file rpc/util.h and wallet/init.h clashed with files of the same name in the higher level source folder.

just to make things work, i edited the #include directives to say "../util.h" instead of "util.h" and likewise for init.h

the correct solution would be to rename the following files
  rpc/util.cpp  --> rpc/rpcutil.cpp
  rpc/util.h     --> rpc/rpcutil.h
  wallet/init.cpp --> wallet/walletinit.cpp
  wallet/init.h  --> wallet/walletinit.h

and of course edit any references to them along with cleaning up any #include directives which really should be #include "f" format.

curiously, only files near/needing these two same named header files seem to have used the offputting version of the #include syntax -- almost as if the litecoin developer felt forced to do so to "make the stuff work." obviously someone not quite understanding how #include search rules work -- and the coding traditions that exist to avoid such issues.

the referencing files that would fail to build were rpc/server.cpp , rpc/protocol.cpp, and wallet/rpcwallet.cpp

other files may erroneously have references to util.h and init.h but dont actually need/use the data they contain and so did not create build/compile time errors. i havent taken the time to go hunting for them.

i'm inclined to suspect the coder who originated this mess simply lacked experience (and possibly not doing much more than a copy/paste from some other codebase such as bitcoin.)
i am more worried about the sod who accepted the code into the official git repository for litecoin. either they didnt know better (bad), or just too lazy to actually look at what was being checked-in (very bad.)
perhaps they had faith in the coder who supplied the changes.
this to me has long term security implications. faith and/or laziness will eventually lead to disaster in financial software.

oh, and because those files could not build is why i do not believe the published noodly github source matches the published binaries (kinda trust breaking.)
jr. member
Activity: 260
Merit: 6
i strongly suspect the source on github is not *precisely* the source use to build the binaries.
i had to make a minor edit to #include directives in three source files to get a clean build.
Hrmmm...I'll have to test it on my machine.  I do recall having to add some includes, but I think that was with the version 16.3 that I ended up abandoning

Quote
i'm also thinking there are brain-dead litecoin developers who set up a source boobytrap.

I actually think that's why I wasn't able to get version 16.3 working; they added something that you have to look for really really hard to find and if you don't it glitches out and won't work properly.

Quote
but i have it built and it appears to be functioning at addnode=coins.dognose.net

I see that, awesome!

Both explorers are showing up on the network!
dnp
full member
Activity: 401
Merit: 110
i strongly suspect the source on github is not *precisely* the source use to build the binaries.
i had to make a minor edit to #include directives in three source files to get a clean build.

i'm also thinking there are brain-dead litecoin developers who set up a source boobytrap.

but i have it built and it appears to be functioning.
jr. member
Activity: 260
Merit: 6
Alright guys, time to switch to the new wallet.  If you have the new wallet, its time to turn it off and turn it back on so it switches to the appropriate pch message code!  If you run into any issues, let me know!
jr. member
Activity: 260
Merit: 6

Regarding compiling you may just need the additional dependencies at:


the configure step is suppose to catch missing dependencies.

i built the current dogecoin (based on recent litecoin) in the fall without problem, so i suspect dependencies arent really the problem.
unless an obscure one has been introduced into the code base.

oh, and no apt-get on Slackware linux Smiley it has its own package manager...


Yeah, probably an obscure one.  To find those commands I listed I fired up the Linux VM I used to compile the linux binaries and those were the commands I used prior to the ./autogen and ./configure commands and the subsequent successful make.  So, for better or for worse, those were the packages I had to install myself to achieve success.
dnp
full member
Activity: 401
Merit: 110

Regarding compiling you may just need the additional dependencies at:


the configure step is suppose to catch missing dependencies.

i built the current dogecoin (based on recent litecoin) in the fall without problem, so i suspect dependencies arent really the problem.
unless an obscure one has been introduced into the code base.

oh, and no apt-get on Slackware linux Smiley it has its own package manager...
jr. member
Activity: 260
Merit: 6
well, looks like i wont have the luxury of a 'quck install'
and, no, i will not use a premade binary - besides trust issues, i need to move over some source
mods necessary for my own internal sysadmin functions.

i did a ./autogen.sh, then a ./configure, then make

i'll eventually get around to making it work, but i will be out of town all day jan.31st
so i guess my node goes offline, probably for the best i avoid the instability of the first day anyway Smiley


            

Totally understand. 

Regarding compiling you may just need the additional dependencies at:

https://github.com/number435398/Noodlyappendagecoin-project/blob/master/doc/build-unix.md#dependency-build-instructions-ubuntu--debian

such as
Code:
sudo apt-get install libqt5gui5 libqt5core5a libqt5dbus5 qttools5-dev qttools5-dev-tools libprotobuf-dev protobuf-compiler
sudo apt-get install libqrencode-dev
sudo apt-get install libdb4.8-dev libdb4.8++-dev
sudo apt-get install software-properties-common
sudo apt-get repository ppa:bitcoin/bitcoin
sudo apt-get update
dnp
full member
Activity: 401
Merit: 110
well, looks like i wont have the luxury of a 'quck install'
and, no, i will not use a premade binary - besides trust issues, i need to move over some source
mods necessary for my own internal sysadmin functions.

i did a ./autogen.sh, then a ./configure, then make

i'll eventually get around to making it work, but i will be out of town all day jan.31st
so i guess my node goes offline, probably for the best i avoid the instability of the first day anyway Smiley


root@carpdiem:/usr/local/src/_coins/ndl/noodly-0.15.2# gcc --version
gcc (GCC) 5.5.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

root@carpdiem:/usr/local/src/_coins/ndl/noodly-0.15.2# uname -a
Linux carpdiem 4.4.14 #2 SMP Fri Jun 24 13:38:27 CDT 2016 x86_64 AMD FX(tm)-8320 Eight-Core Processor AuthenticAMD GNU/Linux

root@carpdiem:/usr/local/src/_coins/ndl/noodly-0.15.2# cat /etc/os-release
NAME=Slackware
VERSION="14.2"
ID=slackware
VERSION_ID=14.2
PRETTY_NAME="Slackware 14.2"
ANSI_COLOR="0;34"
CPE_NAME="cpe:/o:slackware:slackware_linux:14.2"
HOME_URL="http://slackware.com/"
SUPPORT_URL="http://www.linuxquestions.org/questions/slackware-14/"
BUG_REPORT_URL="http://www.linuxquestions.org/questions/slackware-14/"

root@carpdiem:/usr/local/src/_coins/ndl/noodly-0.15.2# make
...
  CXX      rpc/libbitcoin_server_a-net.o
  CXX      rpc/libbitcoin_server_a-rawtransaction.o
  CXX      rpc/libbitcoin_server_a-server.o
rpc/server.cpp: In function 'void RPCTypeCheckArgument(const UniValue&, UniValue::VType)':
rpc/server.cpp:80:132: error: 'strprintf' was not declared in this scope
         throw JSONRPCError(RPC_TYPE_ERROR, strprintf("Expected type %s, got %s", uvTypeName(typeExpected), uvTypeName(value.type())));
                                                                                                                                    ^
rpc/server.cpp: In function 'void RPCTypeCheckObj(const UniValue&, const std::map, UniValueType>&, bool, bool)':
rpc/server.cpp:92:79: error: 'strprintf' was not declared in this scope
             throw JSONRPCError(RPC_TYPE_ERROR, strprintf("Missing %s", t.first));
                                                                               ^
rpc/server.cpp:96:73: error: 'strprintf' was not declared in this scope
                 uvTypeName(t.second.type), t.first, uvTypeName(v.type()));
                                                                         ^
rpc/server.cpp:107:67: error: 'strprintf' was not declared in this scope
                 std::string err = strprintf("Unexpected key %s", k);
                                                                   ^
rpc/server.cpp: In function 'uint256 ParseHashV(const UniValue&, std::string)':
rpc/server.cpp:134:125: error: 'strprintf' was not declared in this scope
         throw JSONRPCError(RPC_INVALID_PARAMETER, strprintf("%s must be of length %d (not %d)", strName, 64, strHex.length()));
                                                                                                                             ^
...blah blah blah

Makefile:5833: recipe for target 'rpc/libbitcoin_server_a-server.o' failed
make[2]: *** [rpc/libbitcoin_server_a-server.o] Error 1
make[2]: Leaving directory '/usr/local/src/_coins/ndl/noodly-0.15.2/src'
Makefile:9345: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/usr/local/src/_coins/ndl/noodly-0.15.2/src'
Makefile:746: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1

            
jr. member
Activity: 260
Merit: 6
of course ndl never had any intrinsic or planned value other than novelty.

that novelty comes from the spaghetti monster graphics and 'pirate talk' wallet messages.

without those in a new wallet, there is now zero instead of next-to-zero attraction to this coin.



You have a point.  I wasn't particularly drawn due to those dynamics, but they did help with the theme.  The images are supposed to be all the same as were in the previous wallet, I copied those directly over.  I have asked for assistance regarding the msg's but haven't received any help.  Coming up with those messages are not my strong point.  As far as I could find, when looking for it, there were only a few messages that were customized.  I can update that in a new version of the wallet that doesn't require the same drama as this new one as it won't have to do with a hard fork of any sort. 

The "value" of this coin (sans actual traded value) is definitely something to think about.  Its something a lot of coins have to grapple with.  Its something that we need to grapple with.  I've been trying to wrack my brain around it for months.  Yes, we could be seen as a fun coin or a novelty coin, but we're also a religious coin.  Probably one of the first.  Most religions would likely be inclined to view a coin based upon them as offensive but I think The Church of the Flying Spaghetti Monster wouldn't begrudge us.  Its even possible we might be able to work with them too.  Thoughts? 
dnp
full member
Activity: 401
Merit: 110
of course ndl never had any intrinsic or planned value other than novelty.

that novelty comes from the spaghetti monster graphics and 'pirate talk' wallet messages.

without those in a new wallet, there is now zero instead of next-to-zero attraction to this coin.

jr. member
Activity: 260
Merit: 6

(...)

Previous wallets will no longer function at that point.   Even if an older wallet is coded with the new pchmessage, all blocks generated by it will be rejected and a small percentage of its sent transactions will actually be accepted (due to DER encoding).

(...)


I am still not sure what truely happens here. To everyone here: The old members do get more and more quiet, as there is heavy (and plausible) uncertainty, what will happen to existing funds (despite that ones of one person) in the future.


I will explain what happens.  All wallets have a "pchmessage" code.  This code is generally used to keep wallets from other coins from interacting with wallets of other coins.

Currently, we have the same "pchmessage" code as Litecoin (you can see this discussion in previous posts).  

As a result, if we added the ip address of a node to the NDL wallet that was the ip address for a node of a Litecoin wallet, both that Litecoin wallet and our wallet will think they're talking to a wallet of the same coin.  This is why our network is inundated with alt-coin wallet nodes.  Because as soon as those two wallets confirm they've got the same "pchmessage" code, they'll start sending each other their list of other nodes.  So a single Litecoin node added to our wallets will result in our wallets asking that Litecoin wallet for all of its nodes regardless of whether the blockchain is our chain or not.  Our wallet just wants to know the nodes.  Only after our wallet gets the nodes will it begin to check the blockchains on those nodes and confirm that they are not on our blockchain.  So one Litecoin ip address added to our wallets will result in our wallets getting inundated with the hundreds, if not thousands, of other nodes that have the same "pchmessage" code, including Litecoin and other alt-coin wallets.  Eventually our wallets will reject all of them because they're not on the same blockchain, but it still takes up a lot of processing time and power and is ultimately just messy.  

The original Dev for Noodlyappendagecoin forgot to change the pchmessage code to something other than the one used by Litecoin.  By changing that code, our wallets will only interact with other nodes with the same pchmessage.  Since old Noodlyappendagecoin wallets will have the old pchmessage code (the same as litecoin) they will stop connecting to the new wallets.

This was not an issue previously because no one had input an ip address for a Litecoin node until recently.  That's when our network started to get messy.  As explained; all it takes is a single Litecoin node to cause a cascade of disruption.

Regarding the new DER encoding.  All transactions have an R and and S value in them, used for the signature verification.  With the new encoding, it was decided that the "S" value couldn't be less than or higher than some specified value  (I don't recall the exact specifics).  The theory was this would eliminate some problems with people tweaking the transactions as technically there are normally 2 valid "S" values for every transaction and changing this mitigated it to some extent.  Its been a while since I've looked it up.  The result is that a wallet that doesn't take into consideration the new "valid" values of the "S" value will send transactions that don't conform to this rule and the new wallets will therefor reject those transactions.  Some may still make it through since the S value correlates with a random number and can change each time you try to send a transaction.

The application of DER encoding is standard at this point in cryptocurrencies.  Bitcoin uses and Litecoin uses it and they both had to transition to the DER encoding thereby effectively disabling old wallets.  This transition is not some arbitrary decision on my part, its normal.

Additionally, as a result of the aforementioned dynamics, old wallets will try to submit blocks to the blockchain that have the now-determined-to-be invalid S values, which would result in that block being rejected.  This would prevent old wallets from being able to mine once the fork goes into effect.  This is the same set of "growing pains" that Bitcoin and Litecoin experienced when adding the DER encoding; its nothing new.


To reference your insinuation of my funds:

There is no code to change existing wallets' funds.

There's no modification of funds of any wallet.  There's only one hard coded allocation of funds and that's the original address for the first block that the original dev setup.  You can see it at:

https://github.com/number435398/Noodlyappendagecoin-project/blob/a4e384415428af9747ba569871e8366880919c13/src/validation.cpp#L1041-L1052

Code:
static const uint64_t TOTAL_GENERATION = MAX_MONEY;
static const double FSM_FUNDS = 0.03;
uint64_t nSubsidy = 10000 * COIN;


CAmount GetBlockSubsidy(int nHeight, const Consensus::Params& consensusParams)
{
    if(nHeight == 1)
    {
   nSubsidy = TOTAL_GENERATION * FSM_FUNDS;
// return nSubsidy + nFees;
        return nSubsidy;
    }

The original code shows the same:

https://github.com/His-Holy-Noodliness/noodlyappendagecoin/blob/1393e84397788417500a49349f1d41f7bc40759d/src/main.cpp#L1067-L1076

Code:
int64 static GetBlockValue(int nHeight, int64 nFees)
{
// standard block payouts are 10000 coins
    int64 nSubsidy = 10000 * COIN;


      if(nHeight == 1)
      {
nSubsidy = TOTAL_GENERATION * FSM_FUNDS;
return nSubsidy + nFees;
      }

This can be further confirmed at http://explorer.noodlyappendagecoin.net/block/a7d3e05f3f9e39a4676ea3e58a41718027786a4e05f37201e55c7f9b5713b706

If I had tried to change that it would alter the entire blockchain and the entire block chain would get rejected.  I actually had that problem early on when I hadn't set Block 1 to the proper amount that was already in the blockchain; the new wallet would reject the entire blockchain beginning with Block 1.

Quote

Shortly: Just why should ANYONE ELSE look at this inception as it would be an improvement?



According to standard exchanges, NDL is "worthless".  If we upgrade it to the new protocols it can then be traded and therefor will be considered to have worth.  I'd say that's quite valuable.  Your 30 million NDL is currently worth $0.00.  If there are no bugs with the new wallet, then that 30 million NDL becomes worth $1050 if NDL trades for 1 satoshi each.  For every satoshi of value that an NDL increases it multiplies that $1050 by the number of satoshi.  

I don't know what uncertainty there could be.  The code is available for perusal, and has been for months, but its just a mod of the Litecoin wallet, which is standard.  I have also consistently advocated people backup their wallets.  I, myself, have multiple old folders that are time and date stamped for the purpose of archiving old variations on the blockchain if it is needed for subsequent reference.  If there's some massive bug we've overlooked; we'll roll it back.  But we can't just sit around and refuse to go outside because something might happen to us; we have to grow.


Quote
I only am citing from the above:

Quote
"Previous wallets will no longer function at that point.   Even if an older wallet is coded with the new pchmessage, all blocks generated by it will be rejected and a small percentage of its sent transactions will actually be accepted (due to DER encoding)."

Now: What is the implication that should be a benefit to NDL-Holders, is this a win-win case or another robbery?
So far there has not been a single positive argument for the less negative cases, so I still don't know what to think about it, - and because of that: Please everyone do your own dd.



So, because there is "no positive argument for the less negative case" people should be running for the hills?  I don't even know what statement, that hasn't already been made, would fit your criteria.  The repository is there if you want to go over it.  If you're so concerned that I'm making some irreversible, malicious, and or inappropriate changes, then go through the code, and or keep a backup copy of the current chain and your current wallet.  I've always advocated backing up one's wallet.

Then you're accusing me of robbery?  You're accusing me of spending around a year of being in this forum and months of programming in an attempt to try to rip off a very small community of a coin that doesn't even have value, that is also, by some, considered to be "dead" and that may still end up being worth nothing even after all this effort on my part and DaveF's part.  The last time this coin was traded, I think it was worth around 5 NDL per 1 satoshi, so your 30 million would be worth a mere $210 and the entire current coin supply would be worth around $75,000, assuming someone would be willing to buy the whole coin supply.

You're accusing me of similar plans to Jon Stewart's hypothetical terrorist in this video: http://www.cc.com/video-clips/gn2sjr/the-daily-show-with-jon-stewart-friends-without-benefits---9-11-responders
Its from the Zadroga Bill; the bill to help pay 9/11 first responders' medical bills.  This was necessary since so many of them were dying from strange cancers and even selling off their homes and all their possessions just to be able to afford to pay their medical bills for their cancers that were caused by them helping people and helping clean up on 9/11.  Someone wanted to add an amendment to the bill that stated that terrorists couldn't receive payments to cover their medical bills from 9/11, but, that doesn't make sense because no terrorist would have helped save people and clean up on 9/11 to get lung cancer just to take advantage of medical benefits from the federal government.  Its not worth it nor is it realistic to assume anyone would do such.  The same thing applies here.  When you consider the hundreds of hours I've spent (yes, hundreds when you consider programming, compiling dozens of exes for testing, etc) versus what the coin is worth, I'd be a freaking moron to do that.  It wouldn't be worth it.  

I now have the knowledge and the experience to program a brand new wallet for a brand new coin if that's what I really wanted; I don't need Noodlyappendagecoin.  I want Noodlyappendagecoin.  

You're like the homeless guy claiming I want to steal your old ratty blanket as I drive up in a brand new BMW.  I'm not asking you to give me your blanket and such paranoia is really weird.  And unlike your ratty old blanket, with Noodlyappendagecoin you can always roll it back if it got bad enough.

I haven't changed the algorithm, I haven't changed the difficulty adjustment equation, I haven't changed the encryption, I haven't changed the block times, I haven't changed the difficulty change time.  I think I did add some light transaction fees (its been like 2-3 months since I released this version so I'd have to go back and double check to be exact).  I felt that making a change to the difficulty algorithm (as some suggested) was going too far for this version upgrade AND was not necessary for the growth of the coin at this time AND there was no consensus as to what to change it to.  Everything else was already programmed for me by the Bitcoin Developers, that was then modified by the Litecoin developers, which I then modified.  My changes are standard for the "industry" if you will.

Quote
PPS: By the way, my announcement of sending 30 Million NDL to someone who creates an up to date wallet for this coin is still alive. It only should be a benefit for everyone involved benefitely ... so, perhaps we will have two chains in near future.

Besides your grammer/syntax being a bit odd; I don't even remotely understand how that would result in two chains or why you would try to break this community apart for a mere wallet upgrade.  Admittedly I wanted to increase the block size, but I didn't, as I was concerned that might be too much for me to arbitrarily do that didn't conform to the criteria of "necessary".  If there's a specific thing that actually and truly harms things, then point it out.  Right now its as if you're just trying to be a doomsayer without evidence.  If you want to be a doomsayer, that's fine, go for it.  But show evidence.  If you're claiming Planet X is about to collide with the earth, then tell us the coordinates of your observations in the sky so we can confirm your suspicions.  

If you've been burned before with regards to other coins and you're apprehensive, fine, I totally get that, but explain that.  Keep a backup of your current chain and wallet; just make a copy the Noodlyappendagecoin folder in your Users> (insert user here) > AppData > Roaming folder and rename it to reference the date that you're copying it.  That way if there's a need to roll it back, you have it ready.

I've put hundreds of hours into this trying several different versions of the wallets to find which one works best etc.

I find your evidence-lacking-anti-my-new-wallet perspective to be insulting.  I've put substantial amounts of time into this project without compensation and so has DaveF.  Maybe you're comfortable with sitting around with this project not having any exchange value for 4 years and, frankly, going nowhere, but I know I'm not and I doubt DaveF is okay with that either.  I'm moving the project forward without any attack on anyone who's been involved in the project.  I even offered the original dev a substantial stake if he'd come back and remake the wallet (before I did).  He didn't respond.  

I've put tons of work into this coin.  It should be moving forward and adapting, not sitting around gathering dust.  You saw me offering 100 million NDL for someone to make the wallet.  No one took the offer.  So I did it.  We need to move forward.  Sans any major issues, I don't plan a lot of changes after this particular update either; this is the minimum necessary to garner value for this project and get traded.  We can't even fund anything regarding this project because NDL isn't worth anything so we can't even trade it or sell it to fund itself.

If you want to say you don't trust me or you're just not convinced of trust, fine, then say that.  At least clearly preface your doom-saying so that others don't think you're privy to something that you're not.

I also wonder and ask, if you're going to dismiss me as you have for all the work I've put into this, even if I disappeared, how would you treat anyone else who tried to get involved in the project, would you treat them the same way?  If you did, how long do you think they'd stay?

PS.  If I was going to steal people's NDL, then why have I been, and continue to mine to wallet address NLfFUfsgBB5GsriyzFrSAdhpT4VhGBqLgs?  Info located at http://explorer.noodlyappendagecoin.net/address/NLfFUfsgBB5GsriyzFrSAdhpT4VhGBqLgs

Going at least as far back as block 1351264 (http://explorer.noodlyappendagecoin.net/block/f98250c84982d0458217b34d84d996790e89848329966e8c8c251044ac5b690b), with hash f98250c84982d0458217b34d84d996790e89848329966e8c8c251044ac5b690b with the tx hash of 578c196cd4d42a9d6750905e1b93e5d5912179f96f29e85e1382929a27431155 (http://explorer.noodlyappendagecoin.net/tx/578c196cd4d42a9d6750905e1b93e5d5912179f96f29e85e1382929a27431155).  Why would I do that?  It'd be a waste of my time and computing power to do that if I was going to scam everyone out of their coins.
Pages:
Jump to: