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

[number435398]

Does anyone object to moving to my new wallet?

I am glad you have been working on a wallet upgrade. I'm sure in time we will be ready to abandon the 0.8 branch code we inherited from His Holy Noodliness. Right now, I can't endorse your repository for production use, sorry.

If you want to work together on a repository based on v0.13.0, then I'll set things up for us to start building it.

What is so intriguing about v 0.13.0 vs v 0.15.1?

[1714105779]

1714105779

[1714105779]

1714105779

[1714105779]

1714105779

[Chicago]

What is so intriguing about v 0.13.0 vs v 0.15.1?

The v0.13.0 code elegantly introduces the features to upgrade the network right up to the point before SegWit.
The v0.15.1 code comes with the assumption SegWit and the earlier Super Majority soft-forks have already activated.

Basically, the protocol changed way too much between 0.8 and 0.15.
We can do 0.8 to 0.13 without much disruption, but anything newer than 0.13.0 will lead to issues.

[number435398]

What is so intriguing about v 0.13.0 vs v 0.15.1?

The v0.13.0 code elegantly introduces the features to upgrade the network right up to the point before SegWit.
The v0.15.1 code comes with the assumption SegWit and the earlier Super Majority soft-forks have already activated.

Basically, the protocol changed way too much between 0.8 and 0.15.
We can do 0.8 to 0.13 without much disruption, but anything newer than 0.13.0 will lead to issues.

What issues?  I already ran a test network where the forks occurred and there were no discernible issues.  I have also given people time to verify this themselves or bring up any concerns.

[Chicago]

What issues?

Code newer than 0.13.0 uses feeler connections and won't talk to more than one node on the old protocol.
Code newer than 0.13.0 assumes BIP66, BIP65, CSV and SegWit have already been activated.
This is why it is asking in chainparams.cpp for the height and hash where activation occurs.

[number435398]

What issues?

Code newer than 0.13.0 uses feeler connections and won't talk to more than one node on the old protocol.

That just means everyone will have to be using the newer setup.  Problem solved.

Code newer than 0.13.0 assumes BIP66, BIP65, CSV and SegWit have already been activated.

I think your characterization is off but either way, what problem does this present?  I had no problems when testing.

This is why it is asking in chainparams.cpp for the height and hash where activation occurs.

You don't have to provide the "hash", that's more of a subsequent note.  But it does need to know which height so that it knows at which block to begin accounting for the new rules.  If you don't have the height then how would any wallet know when to apply the new rules?

[Chicago]

If you don't have the height then how would any wallet know when to apply the new rules?

We already covered this. I posted the code for the IsSuperMajority() function so you could read it and understand.

[number435398]

If you don't have the height then how would any wallet know when to apply the new rules?

We already covered this. I posted the code for the IsSuperMajority() function so you could read it and understand.

Yes, we did.  I did understand.  This was something you said in that same post:

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

I don't find your concerns to be well founded.  I've already tested your concerns and found no issues.  I've asked for you and others to test my setup to see if I am wrong.  No one has informed me of such concerns in actual practice, not you, nor anyone else.

[Chicago]

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

I don't find your concerns to be well founded.

The difference is that my approach has a builtin fail safe and is done in accordance with the upstream best practices.

[LoveStory]

Hey tim, I can't find any information about this project, can you help me to provide the correct website link, because I can not open the site link of the website which are listed in the initial thread.

[dnp]

  I have also given people time to verify this themselves or bring up any concerns.

time? too funny ...less than a week.

[number435398]

 I have also given people time to verify this themselves or bring up any concerns.

time? too funny ...less than a week.

Well no one's responded; it actually seemed like no one was even bothering.  No one has specified an amount of time, no one has communicated anything.  What did you want to test that would take more than a week?  How long would you suggest we test for?  I can't work with you guys if you don't talk to me.

edit:  not to mention I've been testing it constantly and trying various manipulations.

[number435398]

Hey tim, I can't find any information about this project, can you help me to provide the correct website link, because I can not open the site link of the website which are listed in the initial thread.

www.noodlyappendagecoin.net

[number435398]

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

I don't find your concerns to be well founded.

The difference is that my approach has a builtin fail safe and is done in accordance with the upstream best practices.

What built in "fail safe?  What "up stream best practices"?

I'm concerned that you keep coming up with weird reasons we can't use my code, but you won't test those reasons. 

Its not like I changed 900 lines of code, added 67 lines with 3 new functions etc.  I just tweaked a widely accepted coin (litecoin) wallet to work with our coin.

I'm concerned you're just throwing out hypotheticals about what could go wrong and claiming that means we should scrap everything without even verifying if your concerns are relevant.

DNP raised a point I can't dismiss; he was concerned there wasn't enough time for testing.  Fine, fair enough, that's something we can talk about.  But you just suggest we should scrap everything and that doesn't make any sense. 

I tried for months to get someone to code for this wallet, DaveF tried a lot longer than I did.  Most coders want hundreds of dollars up front and will charge upwards of a couple thousand dollars by the time they're done.  But no one in this community was willing to pay (sans those who may have paid already).  Finally, I started working on it (without compensation) and after months of testing and troubleshooting and coding it, I finally did it.  Now you're saying we should scrap the thing we've been waiting for for upwards of a couple of years without even testing it because something you're afraid of "might" go wrong?  I find fault with your logic.

[Chicago]

What built in "fail safe?  What "up stream best practices"?

I'm concerned that you keep coming up with weird reasons we can't use my code, but you won't test those reasons. 

Its not like I changed 900 lines of code, added 67 lines with 3 new functions etc.  I just tweaked a widely accepted coin (litecoin) wallet to work with our coin.

I'm concerned you're just throwing out hypotheticals about what could go wrong and claiming that means we should scrap everything without even verifying if your concerns are relevant.

DNP raised a point I can't dismiss; he was concerned there wasn't enough time for testing.  Fine, fair enough, that's something we can talk about.  But you just suggest we should scrap everything and that doesn't make any sense. 

I tried for months to get someone to code for this wallet, DaveF tried a lot longer than I did.  Most coders want hundreds of dollars up front and will charge upwards of a couple thousand dollars by the time they're done.  But no one in this community was willing to pay (sans those who may have paid already).  Finally, I started working on it (without compensation) and after months of testing and troubleshooting and coding it, I finally did it.  Now you're saying we should scrap the thing we've been waiting for for upwards of a couple of years without even testing it because something you're afraid of "might" go wrong?  I find fault with your logic.

Hi number435398,

    Thanks for your candor.
    I am glad we're getting this all out in the open.

    I am sure if it were trivial to perform a non-disruptive protocol upgrade from 0.8 to 0.15 then everybody would be doing it.
    I've already seen one reckless attempt for this on another coin where a developer came and went and then left consensus in a broken state.
    Its true that after the BIPs activate, none of the 0.8 clients will be viable for mining or signing transactions which will require strict DER signatures.

    After studying the code for a year, I have simply arrived at a different conclusion then you have.
    The options I see moving forward include a 0.13.0 rebase with a hard fork to improve our difficulty adjustment algorithm.

    You can try to discuss actual elements of the code or features in the client, but simply calling my criticisms bullshit will not result in a better network.

Best Regards,
-Chicago
   

[number435398]

What built in "fail safe?  What "up stream best practices"?

I'm concerned that you keep coming up with weird reasons we can't use my code, but you won't test those reasons. 

Its not like I changed 900 lines of code, added 67 lines with 3 new functions etc.  I just tweaked a widely accepted coin (litecoin) wallet to work with our coin.

I'm concerned you're just throwing out hypotheticals about what could go wrong and claiming that means we should scrap everything without even verifying if your concerns are relevant.

DNP raised a point I can't dismiss; he was concerned there wasn't enough time for testing.  Fine, fair enough, that's something we can talk about.  But you just suggest we should scrap everything and that doesn't make any sense. 

I tried for months to get someone to code for this wallet, DaveF tried a lot longer than I did.  Most coders want hundreds of dollars up front and will charge upwards of a couple thousand dollars by the time they're done.  But no one in this community was willing to pay (sans those who may have paid already).  Finally, I started working on it (without compensation) and after months of testing and troubleshooting and coding it, I finally did it.  Now you're saying we should scrap the thing we've been waiting for for upwards of a couple of years without even testing it because something you're afraid of "might" go wrong?  I find fault with your logic.

Hi number435398,

    Thanks for your candor.
    I am glad we're getting this all out in the open.

    I am sure if it were trivial to perform a non-disruptive protocol upgrade from 0.8 to 0.15 then everybody would be doing it.
    I've already seen one reckless attempt for this on another coin where a developer came and went and then left consensus in a broken state.
    Its true that after the BIPs activate, none of the 0.8 clients will be viable for mining or signing transactions which will require strict DER signatures.

    After studying the code for a year, I have simply arrived at a different conclusion then you have.
    The options I see moving forward include a 0.13.0 rebase with a hard fork to improve our difficulty adjustment algorithm.

    You can try to discuss actual elements of the code or features in the client, but simply calling my criticisms bullshit will not result in a better network.

Best Regards,
-Chicago
   

I'm not the dev you referenced.  I know old clients won't work anymore.  Never hid that; we can't upgrade to the new BIPs to become eligible for exchanges without that.  Absolute worst case scenario blockchains can be rolled back, but my testing does not indicate any problems at all.  I resolved all address issues I could find.

You've come to a "different conclusion"?  All you've referenced are "concerns", not actual issues.  I get another dev makes you gun-shy but you still have to ground your concerns in actual measurable issues.  If you identified a measurable issue, that'd be completely different.  If my wallet was constantly deleting your wallet.dat file, yes, that'd be an issue, but that's not happening.

You are still failing in one point; you have yet to demonstrate any fault with my code.  You continue to speak of hypothetical worries you have instead of specifically identifying actual issues.

I've posted the code, I've posted the exe's, its all there.  Try it.

Worrying that something could go wrong and saying we shouldn't move forward where we can because of your worries is not productive.  It's distracting.  Pointing out an actual flaw; that'd be productive. 

Think of how many things you could have tested on my wallet in the time it's taken you to converse with me regarding your mere hypothetical worries.

[Chicago]

Dude... first you tell us you're magically corrupting files when transferring them from Windows to Linux.
Then I see your repository starts with the 0.16 code and that you just added the 0.15 code on top of it.
Then you tell us "its all okay except it can't keep track of your balance or import a paper wallet"
Then I see you've selected yet another network ID to further disrupt consensus.
Add to that not actually using Super Majority for BIP 66 and BIP 65.
Add to that not using Gitian to produce deterministic builds.

I don't want to start nitpicking, but look here.

Then look at this output and tell me why 1537616302 is in your code.

noodlyappendagecoind getblock d28dd9b4ae980c409440dfbd2d743696a88901dfc3520d70e8d69cb0416053ba
{
    "hash" : "d28dd9b4ae980c409440dfbd2d743696a88901dfc3520d70e8d69cb0416053ba",
    "confirmations" : 18904,
    "size" : 189,
    "height" : 1300000,
    "version" : 2,
    "merkleroot" : "d0244b9a2aca4d81c918fc0a8064bbaa91656c79b8743f4f7fb516cb0c0e4981",
    "tx" : [
        "d0244b9a2aca4d81c918fc0a8064bbaa91656c79b8743f4f7fb516cb0c0e4981"
    ],
    "time" : 1538619046,
    "nonce" : 21270,
    "bits" : "1e0a3b9c",
    "difficulty" : 0.00038173,
    "previousblockhash" : "e506e0fed6f5922ec8cedf68df41ad0ab0c11aef9c10e3e3e631ad9783f10ab1",
    "nextblockhash" : "16d37abd4cbbfe12b289c82f2c0e8e3e7a72da31059141b2ea298d62a4ff4c0e"
}

[number435398]

Dude... first you tell us you're magically corrupting files when transferring them from Windows to Linux.

No, that was a flash drive I was using that was corrupting my files.  It wasn't me.

At this time, this concern of yours has no measurable bearing on the functionality of my wallet.

Then I see your repository starts with the 0.16 code and that you just added the 0.15 code on top of it.
Then you tell us "its all okay except it can't keep track of your balance or import a paper wallet"

Yes, I was keeping you apprised of my progress and issues I was working out.  I was keeping you guys in the loop.  Should I not have done that?  Version 16 has a lot more code tweaks I couldn't account for and there were measurable issues.  So I changed it.  Therefor I stopped using it to avoid the measurable problems I had with it and began using v15 instead so that those issues no longer existed and I could release a functional wallet.

At this time, this concern of yours has no measurable bearing on the functionality of my wallet.

Then I see you've selected yet another network ID to further disrupt consensus.

"Yet another"?  I've been talking about changing the pchmessage code for a while now.  At least since October 6th, before you released your fork.  You were the one who changed it the first time, without consensus.  You arbitrarily changed it for your own little fork, but if we're all updating to new wallets, it won't matter anyhow.  We can change it to whatever we want and with only the new wallets working with the forks to begin with, its a perfect and rather ideal time to change the pchmessage code to something not shared by litecoin.

At this time, this concern of yours has no measurable bearing on the functionality of my wallet.

Add to that not actually using Super Majority for BIP 66 and BIP 65.

So, what measurable harm is that doing?  Nothing, as far as I can see.

At this time, this concern of yours has no measurable bearing on the functionality of my wallet.

Add to that not using Gitian to produce deterministic builds.

That is in the category of "bells and whistles" and has no bearing on the functionality of the wallet or the blockchain itself and therefor not cause to dump my new version.  Not to mention that can be done at a later time without impacting the wallet or releasing a new version.

At this time, this concern of yours has no measurable bearing on the functionality of my wallet.

I don't want to start nitpicking, but look here.

Then look at this output and tell me why 1537616302 is in your code.

noodlyappendagecoind getblock d28dd9b4ae980c409440dfbd2d743696a88901dfc3520d70e8d69cb0416053ba
{
    "hash" : "d28dd9b4ae980c409440dfbd2d743696a88901dfc3520d70e8d69cb0416053ba",
    "confirmations" : 18904,
    "size" : 189,
    "height" : 1300000,
    "version" : 2,
    "merkleroot" : "d0244b9a2aca4d81c918fc0a8064bbaa91656c79b8743f4f7fb516cb0c0e4981",
    "tx" : [
        "d0244b9a2aca4d81c918fc0a8064bbaa91656c79b8743f4f7fb516cb0c0e4981"
    ],
    "time" : 1538619046,
    "nonce" : 21270,
    "bits" : "1e0a3b9c",
    "difficulty" : 0.00038173,
    "previousblockhash" : "e506e0fed6f5922ec8cedf68df41ad0ab0c11aef9c10e3e3e631ad9783f10ab1",
    "nextblockhash" : "16d37abd4cbbfe12b289c82f2c0e8e3e7a72da31059141b2ea298d62a4ff4c0e"
}

I don't mind nitpicking, as long as its valid.  In the realm of functionality; this is not valid nitpicking and not significant to the concerns you have expressed.

Or are you just trying to dramatize the fact that I put the wrong time stamp in for the block?  I think that's because I originally had a different "most recent" checkpoint block than 1300000, and then when I changed it to 1300000 I forgot to update it.  It's a trivial error that has no functional impact on the wallet or the blockchain.  I have updated the code to reflect the correct timestamp.  When finalizing it with a much more recent block I would have changed it anyhow, but either way, that is an objective existing error you caught and I have fixed it.

At this time, this concern of yours has no measurable bearing on the functionality of my wallet (nor did it before I fixed it).

Nothing, thus far presented, negatively impacts the wallet or the blockchain in any measurable way.  Therefor, there is no measurable reason to scrap my new wallet as of yet. 

And if you're testing my wallet now, go ahead; wipe the noodlyappendagecoin folder clean and start it anew and make it download the whole blockchain.  Takes a while, but some errors only crop up if you make it download the whole blockchain anew.  How do I know?  Because I had those errors and fixed them.  Because I've already spent substantial amounts of time testing my wallet.  Downloaded the whole blockchain over a dozen times.  Why?  To find the errors before others do; to streamline the process.  Because I'm not trying to half-ass this thing like the dev that so concerned you with that "other" alt-coin. 

[Chicago]

Files that are supposed to be executable aren't executable in your repository.

For example, autogen.sh needs to be executable but it isn't.
Also, /share/genbuild.sh needs to be executable but it isn't.

I suspect others will also run into Issue 510.

[number435398]

Files that are supposed to be executable aren't executable in your repository.

For example, autogen.sh needs to be executable but it isn't.
Also, /share/genbuild.sh needs to be executable but it isn't.

I suspect others will also run into Issue 510.

You are correct.

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.

I referenced that as an issue that I was unaware of a solution to.  You have to right click them, go to properties, then permissions, then select the "Execute file as program" check-box on each of those 4 files in ubuntu.  You may have to do that to trythis as well as configure.ac.  I'm guessing it *could* be some sort of security thing in ubuntu, I'm not really sure.  If I take my main folder that contains the files and change them, then copy them to ubuntu, the copies lose that designation for some reason.

Edit:  If you know an easy way to fix that, I would be happy to implement the fix.

[Chicago]

Using unmodified Litecoin v0.15.1 as follows, there is no build error.
Hence, something must have become broken sometime between your clone and your commit to GitHub.

Code:

git clone https://github.com/litecoin-project/litecoin
cd litecoin/
git checkout v0.15.1
./autogen.sh 
./configure
make -j13
make check