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

number435398

jr. member

Activity: 260

Merit: 6

Quote from: dnp on October 16, 2018, 12:57:55 AM

Quote from: number435398 on October 15, 2018, 05:39:16 AM

Many of your presented adjustments may help with the network but the real way its supposed to be done is through the pchMessage.

btw, whatever future/new value of pch you have chosen, how have you determined it's not already taken by some other altcoin?
anyhow, i'd find it amusing if the hex ascii equivalent of NDLY was used Cheesy

even more amusing if the EBCDIC values of NDLY were used Cheesy

I was planning on using the ascii for it (contrary to what I previously posted). The EBCDIC...well...I guess we could. Wasn't what I was plannin'.

And, no, I don't know that another altcoin isn't using the same pchmessage code. But that's one reason to use the ascii; if other people follow that same logic then they wouldn't match ours.

Chicago

sr. member

Activity: 592

Merit: 259

Hello,

In my experiment, I set the Network ID to FSM1.

It wasn't too much effort to render a linear bootstrap.dat using the new Network ID.

After that was done, I used His Holy Noodliness's code and made the following updates.

- Update Gitian Recipes
- Upgrade UPnP Support
- Set Client Version to Noodlyappendagecoin v0.8.6.2
- Update Copyright Year to 2014-2018
- Set Checkpoint at Height 1314626
- Main Network 0x46534d01
- Test Network 0x46534d02
- Remove Legacy DNS Seeds
- Remove pnSeed Array

The source code is in the 4Q18 branch here.

I have also produced Windows binaries.
These Windows binaries use Berkeley DB v5.3.

Here is how to try the "new peer swarm network".

You must backup your current wallet.dat and data directory.
Keep your backups!

Next, move your current data directory someplace out of the way so you can sync the chain using the new FSM Network ID.
You may use the newly prepared FSM bootstrap.dat to load the blocks from disk during the initial sync.

Noodlyappendagecoin v0.8.6.2 for Windows is available here.

It is noted as EXPERIMENTAL on the the repository releases page.

There is one full node only and it is not mining.
addnode=23.253.205.134
addnode=[2001:4801:7825:102:be76:4eff:fe10:3d29]

If you would like to participate, just run the new code and start your miner.

I am hoping this solves the network problems we discussed over the weekend and acts as a stop-gap until we perform another network upgrade to implement BIP 34 and BIP 66.

This interim client should make things easier on future development so there are less exceptions written into the code.
This interim client is not meant to hinder other development efforts.

This client is a clean break from the v0.8.6.1 network.
There was approximately a 12 hour difference between the snapshot at height 1314626 and this public release.

If I picked the wrong fork of the chain, let me know and we can do this experiment again with another chain.
I selected this chain because it is the one which His Holy Noodliness's code identifies with in the peer swarm.

Best Regards,
-Chicago

dnp

full member

Activity: 401

Merit: 110

Quote from: number435398 on October 15, 2018, 05:39:16 AM

Many of your presented adjustments may help with the network but the real way its supposed to be done is through the pchMessage.

btw, whatever future/new value of pch you have chosen, how have you determined it's not already taken by some other altcoin?
anyhow, i'd find it amusing if the hex ascii equivalent of NDLY was used Cheesy

even more amusing if the EBCDIC values of NDLY were used Cheesy

number435398

jr. member

Activity: 260

Merit: 6

Quote from: Chicago on October 15, 2018, 11:33:12 AM

I created a linear bootstrap.dat for the chain I'm synced with near height 1314626.

You can download it here.

Next, I'll see about trying that thing with the Network ID change as a proof-of-concept.

I have found no code that allows the pchMesssage to be changed after compilation. If its there, then great.

I've already tested changing the pchmessage code. It works (maybe I should have mentioned that like a week or so ago). All nodes not in line with it don't work with a wallet compiled with it, though the blockchain is still fine. The wallet doesn't even consider any nodes w/o the same code.

Chicago

sr. member

Activity: 592

Merit: 259

I created a linear bootstrap.dat for the chain I'm synced with near height 1314626.

You can download it here.

Next, I'll see about trying that thing with the Network ID change as a proof-of-concept.

Chicago

sr. member

Activity: 592

Merit: 259

Okay, so I seem to remember a way to seamlessly change the network magic under special circumstances.

I'm just going from memory here so if I'm wrong, then I'll actually go do it again so I can report more accurately.

Basically you start with a fully sync'd node.
Then you stop it and go change the Network ID, recompile and start the wallet.

All of the blocks on disk are already trusted, so no problem.

Then you run the linearize script which hits the RPC and builds a bootstrap.dat which has the new Network ID in it.

Since our mining difficulty is so very low - there clearly is an opportunity to just take the current sources; add in the patch exclude invalid client versions; add a checkpoint; set a DNS seed and then run the builds through Gitian to produce some Windows and Linux binaries.

Disruption would be minimal to the small handful of people holding the network together.

This would then let us actually have a more stable base network before proceeding with further network upgrades towards the latest and greatest code.

DaveF

legendary

Activity: 3500

Merit: 6320

Crypto Swap Exchange

Quote from: number435398 on October 15, 2018, 05:39:16 AM

Edit: wait, was it segwit that splintered the bitcoin community or was is the increase in block size? I don't recall.

Both.
-Dave

number435398

jr. member

Activity: 260

Merit: 6

Many of your presented adjustments may help with the network but the real way its supposed to be done is through the pchMessage.

Here's the Litecoin version:
https://github.com/litecoin-project/litecoin/blob/master/src/chainparams.cpp#L116-L119

Code:

pchMessageStart[0] = 0xfb;
pchMessageStart[1] = 0xc0;
pchMessageStart[2] = 0xb6;
pchMessageStart[3] = 0xdb;

Here's the Bitcoin version:
https://github.com/bitcoin/bitcoin/blob/master/src/chainparams.cpp#L104-L107

Code:

pchMessageStart[0] = 0xf9;
pchMessageStart[1] = 0xbe;
pchMessageStart[2] = 0xb4;
pchMessageStart[3] = 0xd9;

As you can see, they are different because that is the way its supposed to be done.

If we don't make that adjustment soon, what if we decide we need to make the adjustment later when we have 100 or 1k people taking part in Noodlyappendagecoin? It will be much harder to do then than it will be to do now. The smaller the community and the earlier we make big jarring changes, the better. Look at what happened to bitcoin when they tried to do segwit...it broke the community because of how big and polarized it had become. Hell, I wouldn't even mind setting larger block sizes now instead of later due to the same concern.

Edit: wait, was it segwit that splintered the bitcoin community or was is the increase in block size? I don't recall.

dnp

full member

Activity: 401

Merit: 110

Quote from: Chicago on October 13, 2018, 11:28:29 PM

There are ways you can tell the wallet to only allow connections when the client version identifies in a particular way.

Here is how Litecoin handled it.
https://github.com/litecoin-project/litecoin/blob/9d11a2dc6cb782767064b81eee908746cd20c261/src/main.cpp#L3688

looks like litecoin looks for 'bad' subvers, while the code i posted a couple days ago looks for 'good' subvers. pretty much the same idea but from opposite directions

the problem with looking for bad ones, is you have to know who they are in advance.
those 'seeder' nodes (which i noticed connecting to dognose as well) may be a big clue as to the root source of the plague however.

dnp

full member

Activity: 401

Merit: 110

Quote from: Chicago on October 13, 2018, 11:28:29 PM

I don't think changing the Network ID is a good idea yet.

We don't know who runs the dognose nodes and if they don't upgrade then everything falls apart without a seed.

i be dognose.
i wont have real free time until december. maybe possibly late november.

i'm too busy to figure what fork i may have wandered down, but this is my current state of the daemon.
i do not have any of those nasty altcoin connections since i'm running that code i posted a couple days ago.

Code:

{
    "version" : "v0.8.6.50-unk-dnp",
    "protocolversion" : 70002,
    "walletversion" : 60000,
    "client" : "/Noodly-dnp:0.8.6.50/",
    "berkeleydb_version" : "Berkeley DB 4.8.30: (April  9, 2010)",
    "openssl_version" : "OpenSSL 1.0.2p  14 Aug 2018",
    "boost_version" : "1_59",
    "compiler_version" : "5.5.0 (5.5.0)",
    "build_date" : "2018-10-13 22:49:01 -0400",
    "balance" : 1205499.87000000,
    "al_dente" : 0.00000000,
    "immature" : 30000.00000000,
    "blocks" : 1313963,
    "lastblock_time" : 1539574422, (Oct 14 23:33:42 2018 -0400)
    "timeoffset" : -1,
    "connections" : 6,
    "proxy" : "",
    "ip_address" : "23.233.2.252",
    "port" : 40021,
    "rpc_port" : 40022,
    "difficulty" : 0.00054808,
    "next_block" : {
        "height_next" : 1313964,
        "difficulty_next" : 0.00054808
    },
    "testnet" : false,
    "keypoololdest" : 1539525759, (Oct 14 10:02:39 2018 -0400)
    "keypoolsize" : 101,
    "paytxfee" : 0.00000000,
    "mininput" : 0.00001000,
    "generate" : true,
    "threads/cores" : 2,
    "errors" : "URGENT: Alert key compromised, upgrade required"
}

Code:

[
    {
        "addr" : "74.113.33.65:40021",
        "services" : "00000003",
        "lastsend" : 1539574585, (Oct 14 23:36:25 2018 -0400)
        "lastrecv" : 1539574492, (Oct 14 23:34:52 2018 -0400)
        "bytessent" : 992049,
        "bytesrecv" : 672331,
        "blocksrequested" : 682,
        "conntime" : 1539485439, (Oct 13 22:50:39 2018 -0400)
        "version" : 70002,
        "subver" : "/Satoshi:0.8.6.1/",
        "inbound" : false,
        "startingheight" : 1312487,
        "banscore" : 0,
        "syncnode" : true
    },
    {
        "addr" : "188.99.44.158:54782", (dslb-188-099-044-158.188.099.pools.vodafone-ip.de)
        "services" : "00000003",
        "lastsend" : 1539574514, (Oct 14 23:35:14 2018 -0400)
        "lastrecv" : 1539574400, (Oct 14 23:33:20 2018 -0400)
        "bytessent" : 817679,
        "bytesrecv" : 496281,
        "blocksrequested" : 1145,
        "conntime" : 1539489038, (Oct 13 23:50:38 2018 -0400)
        "version" : 70002,
        "subver" : "/Satoshi:0.8.6.1/",
        "inbound" : true,
        "startingheight" : 1312486,
        "banscore" : 0
    },
    {
        "addr" : "188.99.44.158:58773", (dslb-188-099-044-158.188.099.pools.vodafone-ip.de)
        "services" : "00000003",
        "lastsend" : 1539574493, (Oct 14 23:34:53 2018 -0400)
        "lastrecv" : 1539574513, (Oct 14 23:35:13 2018 -0400)
        "bytessent" : 1103190,
        "bytesrecv" : 243716,
        "blocksrequested" : 1697,
        "conntime" : 1539502578, (Oct 14 03:36:18 2018 -0400)
        "version" : 70002,
        "subver" : "/Satoshi:0.8.6.1/",
        "inbound" : true,
        "startingheight" : 1312265,
        "banscore" : 0
    },
    {
        "addr" : "188.99.44.158:52593", (dslb-188-099-044-158.188.099.pools.vodafone-ip.de)
        "services" : "00000003",
        "lastsend" : 1539574399, (Oct 14 23:33:19 2018 -0400)
        "lastrecv" : 1539574585, (Oct 14 23:36:25 2018 -0400)
        "bytessent" : 731746,
        "bytesrecv" : 339180,
        "blocksrequested" : 584,
        "conntime" : 1539503274, (Oct 14 03:47:54 2018 -0400)
        "version" : 70002,
        "subver" : "/Satoshi:0.8.6.1/",
        "inbound" : true,
        "startingheight" : 1312789,
        "banscore" : 0
    },
    {
        "addr" : "188.99.44.158:55015", (dslb-188-099-044-158.188.099.pools.vodafone-ip.de)
        "services" : "00000003",
        "lastsend" : 1539574586, (Oct 14 23:36:26 2018 -0400)
        "lastrecv" : 1539574399, (Oct 14 23:33:19 2018 -0400)
        "bytessent" : 261746,
        "bytesrecv" : 199291,
        "blocksrequested" : 513,
        "conntime" : 1539525882, (Oct 14 10:04:42 2018 -0400)
        "version" : 70002,
        "subver" : "/Satoshi:0.8.6.1/",
        "inbound" : true,
        "startingheight" : 1313157,
        "banscore" : 0
    },
    {
        "addr" : "76.16.12.81:43892", (c-76-16-12-81.hsd1.in.comcast.net)
        "services" : "00000003",
        "lastsend" : 1539574601, (Oct 14 23:36:41 2018 -0400)
        "lastrecv" : 1539574602, (Oct 14 23:36:42 2018 -0400)
        "bytessent" : 147416906,
        "bytesrecv" : 39445802,
        "blocksrequested" : 353502,
        "conntime" : 1539570369, (Oct 14 22:26:09 2018 -0400)
        "version" : 70002,
        "subver" : "/Satoshi:0.8.6.1/",
        "inbound" : true,
        "startingheight" : 0,
        "banscore" : 0
    }
]
5 inbound 1 outbound = 6 total connections

DaveF

legendary

Activity: 3500

Merit: 6320

Crypto Swap Exchange

I have been kind of quiet as of late. Work has just been non stop busy and my time for side projects has dropped to almost zero.
But there only seems to be 4 or 5 of us here on a regular basis.
Looking at the low number of "real" nodes and the low amount of mining I think number435398 has the correct idea:

Push forward with a new client and see if we can get any traction anywhere for exchanges or anything else. If we keep this thread active if there are any other people who don't know what is going on if their nodes stop syncing and they care I would think this thread would be the 1st place they look.

As far as I know dnp runs the dognose nodes

Since I am running the explorer and the .net website I *DO NOT* want to be in the position of making *ANY* decisions. That would make it look too much like I am forcing what I want on the community.

-Dave

Chicago

sr. member

Activity: 592

Merit: 259

Okay so it turns out part of the issue with addresses comes form this code.

https://github.com/His-Holy-Noodliness/noodlyappendagecoin/blob/1393e84397788417500a49349f1d41f7bc40759d/src/net.cpp#L1247-L1324

It is triggered because ndlseed.noodlyappendagecoin.com is offline.
https://github.com/His-Holy-Noodliness/noodlyappendagecoin/blob/1393e84397788417500a49349f1d41f7bc40759d/src/net.cpp#L1194-L1197

number435398

jr. member

Activity: 260

Merit: 6

Wow, I really set off a lot of responses.

Regarding the Current Fork: Whichever fork has the most work and conforms to the most recent checkpoint is the proper fork.

Dognose node: I'd love to keep that, though my wallets have been working wo that particular node just fine. But no, I won't change the network ID yet.

How litecoin handled it: Even with a 16.3 version of litecoin I had modified, I did not notice it doing a good job of keeping out other nodes; in fact it wasn't. Or maybe it did keep some out and there were still so many it didn't seem like it was doing anything. I saw the same nodes you guys have been seeing in your wallets, in my v16.3 wallet.

Hard forks: I've already coded them to occur by consensus at a particular date. The date is currently set to Nov 22 which can absolutely be changed, this is just a beta. The pchMessage code is not setup to be able to occur at a particular block since its supposed to be for downloading the blocks to determine when to apply other code.

Community Consensus: All for it, I kinda thought I already kinda had that....guess I was wrong; wasn't trying to step on anyone's toes or exclude anyone.

Test Net: I have not established a test net, I don't know for what aspect I would establish one. Maybe I'm wrong, but I don't see the full need for it, please feel free to explain it to me. I've never released a major upgrade to a wallet before so I'm not familiar with all the details.

Perhaps I'm too eager to get this going, but that's why I have you guys to help keep my enthusiasm in check Wink

nxtraordinary

jr. member

Activity: 100

Merit: 1

Pool for Future-Airdrops already at 9.000.000 NDL

Quote from: DaveF on October 11, 2018, 08:14:59 PM

This is actually a worry of mine. One day the node that the explorer talks to is going to walk away on another chain and not come back.
-Dave

Again: Actually we do HAVE a fork with at least two confirming networks, one chain is at 1312776 and confirmed, the other one at 1312265 and confirmed.
After some time, the latter one gets unconfirmed, while one connection suddenly misses and the wallet then jumps to the other chain - just to where it forked from in time.

Now: Which one is the right chain? Blockexplorer is on the first one. The faster one ... .

n.

Chicago

sr. member

Activity: 592

Merit: 259

I don't think changing the Network ID is a good idea yet.

We don't know who runs the dognose nodes and if they don't upgrade then everything falls apart without a seed.
There are ways you can tell the wallet to only allow connections when the client version identifies in a particular way.

Here is how Litecoin handled it.
https://github.com/litecoin-project/litecoin/blob/9d11a2dc6cb782767064b81eee908746cd20c261/src/main.cpp#L3688

dnp

full member

Activity: 401

Merit: 110

Quote from: number435398 on October 13, 2018, 09:37:17 PM

UPDATE:
I seem to have made a new working version of the wallet! I need to dot a few "i"'s and cross a few "t"'s and then I'll upload and release it in the next few days. It seems to have no problem with old wallet.dat files, though it doesn't import current paper wallets of NDL for some reason. May have to update the paperwallet code. This new version will distinguish us on the network and not even bother with nodes that don't conform to the new pchMessage code I've implemented. So it will mean everyone will have to update to the new wallet. Plus it'll include an upgrade to all the BIPs we need to be traded and, I think, even be setup for SegWit to go live in a couple of weeks.

this is called a hard fork, perhaps first a release without the pchVersion change to test everything else in your wallet first?

also, when done, the hardfork/pchVersion change should occur at some future block number or date to give time for people to install the new wallet.

hardforks should have a bit of community consensus...

have you established a testnet?

number435398

jr. member

Activity: 260

Merit: 6

Quote from: Chicago on October 13, 2018, 08:24:25 PM

It seems like you're skipping a few important changes leading the new code to make connections to old hard-coded IP addresses and legacy DNS seeders.

https://github.com/bitcoin/bitcoin/blob/v0.13.0/src/chainparamsseeds.h
https://github.com/bitcoin/bitcoin/blob/a402396dce64c42ea73535b7dde4a9164d430438/src/chainparams.cpp#L117-L122
https://github.com/bitcoin/bitcoin/blob/a402396dce64c42ea73535b7dde4a9164d430438/src/chainparams.cpp#L211-L214

Have a look at those and the associated scripts in https://github.com/bitcoin/bitcoin/tree/v0.13.0/contrib/seeds

Together they work to help you build the set initial connection attempts made by the wallet code.

Nope, I'm well beyond that. The existing problem on the Noodlyappendagecoin network is:

https://github.com/bitcoin/bitcoin/blob/a402396dce64c42ea73535b7dde4a9164d430438/src/chainparams.cpp#L105-L108

All the wallet codes you see, have the same pchMessage setup. That's not supposed to be how someone makes a new coin. Each coin should have its own unique code.

The current network spam can only be overcome by changing that code. Which I'm ready to do with the new beta version of the wallet I'm going to be releasing, hopefully, in the next day or two.

UPDATE:
I seem to have made a new working version of the wallet! I need to dot a few "i"'s and cross a few "t"'s and then I'll upload and release it in the next few days. It seems to have no problem with old wallet.dat files, though it doesn't import current paper wallets of NDL for some reason. May have to update the paperwallet code. This new version will distinguish us on the network and not even bother with nodes that don't conform to the new pchMessage code I've implemented. So it will mean everyone will have to update to the new wallet. Plus it'll include an upgrade to all the BIPs we need to be traded and, I think, even be setup for SegWit to go live in a couple of weeks.

Chicago

sr. member

Activity: 592

Merit: 259

It seems like you're skipping a few important changes leading the new code to make connections to old hard-coded IP addresses and legacy DNS seeders.

https://github.com/bitcoin/bitcoin/blob/v0.13.0/src/chainparamsseeds.h
https://github.com/bitcoin/bitcoin/blob/a402396dce64c42ea73535b7dde4a9164d430438/src/chainparams.cpp#L117-L122
https://github.com/bitcoin/bitcoin/blob/a402396dce64c42ea73535b7dde4a9164d430438/src/chainparams.cpp#L211-L214

Have a look at those and the associated scripts in https://github.com/bitcoin/bitcoin/tree/v0.13.0/contrib/seeds

Together they work to help you build the set initial connection attempts made by the wallet code.

dnp

full member

Activity: 401

Merit: 110

Quote from: number435398 on October 13, 2018, 05:21:10 PM

All the same height likely means that its all litecoin wallets. Or maybe someone made their own wallet and didn't know what they were doing and named it differently, but its still a litecoin wallet.

I've got a new idea I'm going to try to apply this weekend to the new version of the wallet I'm trying to make. If I'm successful I would really like to give it a new pchMessage setting so as to immediately reject all those other nodes.

besides LitecoinCore versions, i've seen multiple instances (different ip#) of

all with the same starting height

once is happenstance, twice is coincidence, three times is enemy action to quote a bond movie

even valid nodes with same wallet generally dont have the same starting height, that's why they connect -- to catch up.

number435398

jr. member

Activity: 260

Merit: 6

Quote from: dnp on October 13, 2018, 05:31:33 PM

Quote from: number435398 on October 13, 2018, 05:21:10 PM

Quote from: dnp on October 13, 2018, 02:27:16 PM

Quote from: number435398 on October 11, 2018, 09:30:53 PM

Quote from: DaveF on October 11, 2018, 08:14:59 PM

This is actually a worry of mine. One day the node that the explorer talks to is going to walk away on another chain and not come back.
-Dave

Naw, the other alt coins aren't on the same blockchain. They merely act as a distraction; our wallets see them and consider them, but ultimately our wallets reject them because they don't conform to fundamental NDL chain

why are these other alts connecting at all? someone mispublish a port number somewhere? willful attack?

i'm thinking willful attack, i just notice that even though they identify as various differnent altcoins they all
seem to have the same startingheight

All it takes is one person's wallet to connect to one of these other coins, then those wallets tell our wallets about its other wallets etc. The current wallet is programmed to connect to all wallets with the proper pchMessage code. Since, when Noodlyappendagecoin was created, it was programmed with the same pchMessage code as Litecoin (and other alt-coins that weren't modified properly), our wallets see these as valid nodes until they realize that they aren't on the same blockchain (which can take a while). Our wallets may give each node several hours to try to provide proper blockchain info, but during that time our wallets will incorporate all that other wallets' nodes to our list of nodes. In other words, its a mess.

still seems like a willful attack using this vulneratbility.
it's very odd (suspicious) that all the 'different' altcoins have the same blockchain height (total number of blocks.)

All the same height likely means that its all litecoin wallets. Or maybe someone made their own wallet and didn't know what they were doing and named it differently, but its still a litecoin wallet.

I've got a new idea I'm going to try to apply this weekend to the new version of the wallet I'm trying to make. If I'm successful I would really like to give it a new pchMessage setting so as to immediately reject all those other nodes.

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