I think it is prudent to be skeptical of all things blockchain.

Having said that, I notice these things:

The coin was strip-mined.
It was stagnant for a really long time.
Without change, it remains vulnerable to a strip-mining attack when we revive it.
I own several existing coins.  The blockchain needs to be viable for them to have value.
This is a serious matter.  A coin that does not produce blocks for 18 months is effectively dead.

I have thought since 2014 about how to protect against strip mining.  I am convinced I have a solution, and I have been coding with strong focus and watching the calendar.  I want my solution to work well enough when I release it, and I don't want to release enough information that someone can scoop me with an implementation that goes in a direction that is philosophically incompatible to me.  That is a delicate dance in cryptocoin country.

So I am releasing my ideas fairly slowly, when the horizon to release an implementation is within view.  I think that, any time now, I can make a code release to GitHub and things will be transparent.  Then the community can make an informed decision.  A bit of my work is on gitgub now, including the mechanism to build a VM to compile the code in, a mechanism to report the SHA-256 of the resulting binaries for crowd-sourced validation.  I do need to clean up the VM generation a bit to solve the "genesis VM" problem.  I was working on that when PersonalLife took some attention, and no one has seemed very interested, so it is on the ToDo list starved for attention.

What I can say for now is that there is a live testing block chain at bte.vima.austin.tx.us:26333  As detailed in an earlier post, the existing client can download this blockchain.  N.B. "As detailed in an earlier post."  As a testing block chain, it has warts and knotholes and changes whimsically.  As soon as I get the code located at https://github.com/a-mcintosh/expt-block1 back ported into the 0.8.1 BTE client's mining code and supported in the getblocktemplate command I will take a few day breather.  I may make a code release then, or I may decide to get the distributed mining pool working first.  LOL.  My estimate for that is "last month."

I have the opinion that 3 factors should go into the difficulty adjustment.
This opinion is captured in new technology I am calling Hard Turtle.


1.  The long term mining rate of the coin.

• 600 sec / block since genesis
• adjust the difficulty_0 according to this factor

2.  The interval mining rate of the coin.  This is the standard difficulty adjustment after 2016 blocks, difficulty or difficulty_1.
3.  The time since MedianPrevTime. 

• This should also be 600 sec/block. 
• The value of those difficulty increases (will be) in a calculated table, and called difficulty_2.
• The actual behavior is described very well by a Poisson distribution.  See the link several posts above.
• This can be control without an audit trail by changing the target hash reported in getminingtemplate
• The value of those difficulty increases (will be) in a calculated table, and called difficulty_2.

4.  The new difficulty will be the cube root of difficulty_0 * difficulty_1 * difficulty_2. 

• This is easy to calculate using nBits.
• After calculation, it will be clipped to a factor of 4x change, as is the current practice.

5.  These changes will dovetail very nicely with a distributed mining pool. 

• The difficulty items are nearing the end of development and testing.
• The mining pool has some development work.

6.  The old client will work with these changes for a few Intervals (epochs of 2016 blocks) but as the difficulty starts to steady out, the nBits numbers will eventually differ and cause a hard fork.

7.  I am making the hard fork stronger, and repairing the entire blockchain. 

• This will result in the same transactions as before, but a blockchain with a difficulty near 1.
• It will take fewer hashes to mine 58,000 blocks at difficulty 1 than 300 blocks at difficulty 1,000,000.
• No data will be lost.
• Timestamps will be very similar.
• It took a devil of a long time to work out the logic of mining blocs nunc pro tunc.
• The blockchain repair will occur with a client that also supports the mining pool.  Alternate blocks will generate new rewards, so it will be earn as you repair.

8.  It turns out, I can include a coinbase block for a bitcoin block as well, while I am doing the repair.  Go to the survey a few postings above, and include any bitcoin address that you have been paid to in a coinbase block :-).

I can put you in the dns entry at seed.bte.vima.austin.tx.us if you give permission.


edited 2018-03-29

I decided your post was permission enough.  I have added your address to the
DNS entry.  It is live and tested with dig.

So, I recommend using the following line in your bytecoin.conf or the command line.

I'll look for some.  Meanwhile, manually move those files out of the directory that they are in. 
Someone who can check a windows environment, please post the details of where that directory is located.

In Linux, you might start an investigation session with

Then, it should create a new peers.dat that only has the peers it gets from my node.

Then you can search debug.log for
"trying connection"

and that should show the nodes it is trying to connect to.

My electricity was off for a few hours today.  When I booted back up just now, some new nodes connected, and my block count went from 58122 to 58126.  However, there was a re-organization back 16 blocks, and the newest block now is back to Sat Aug 27 01:26:49 2016 instead of last week.  Apparently the nodes have been fragmented for some time.

I think it is important that everyone try to accept connections from each other as well as reach out to each other.  If I get hit by a truck or something and no one else allows each other to connect, the network is still vulnerable.

There are IP addresses that show up in my debug.log that my node can't connect back to.  I think the software automatically shares all the IPs that it learns about, so that the blocks get distributed and are safe.  I think we need more active nodes and connections at the moment.

So, some commands that you might want to AVOID except under special circumstances are

listen=0 
connect=<ip>
noconnect
connect=0

You can type 'help' on the internal command line, and it will give a list of commands.

getpeerinfo

will give information on the currently connected peers.

I do have a new connection, perhaps this is you.  The new connection advertises 58126 blocks, but it never delivers them to my node.

If I run
getblockhash 58122
I get back
0000000000000664b482018d10447f73ba9fdb675740494c73635505d8a46418


If you did rename or delete peers.dat, as I instructed, before you started up your node, it should begin connecting to all the nodes that my node thinks are active the next time you connect.

If you add

logtimestamps=1

to your bytecoin.conf file, there should be timestamps (in GMT) in your logfile.

I run on the standard port, and your rpcport line is ok.

None of those addresses from your attempted connections show up in my log.  I wonder if you have an old peers.dat file.  You might rename it to something else, to be sure that it initializes to the nodes that were recently good on my machine.

I have also given the command
addnode bte.vima.austin.tx.us onetry
on the internal command line after the client has started.

If you are running Linux, I wish you would post the output of the following command.  Perhaps someone else can post the windows command equivalent. 
It turns out that you cannot use onlynet=ipv6 & seednode= at the same time, the client only tries IPv4 seednodes.


dig seed.bte.vima.austin.tx.us


In addition, you may post your address, either IPv4 or IPv6, and I or someone can try to connect to you.  You may private message this to me if, for some reason, you do not want to post it.  Of course, this option works best if you leave the client running for a while.

Also, dig through debug.log and look for things that have [2001:470:b8ac:: or 67.198.113.220 in them.

Testing is going well, but slowly.  I am developing on Ubuntu, and I don't have any idea which operating systems people are actively using.  Here's a survey to help me find out.

https://docs.google.com/forms/d/e/1FAIpQLSee_fE7gUBgU2r2jjc-vAERrN5jiz9WALJW0HG0cR6_akK5KA/viewform?usp=pp_url&entry.2092041095=Linux+--+Ubuntu

My test blockchain is frequently exposed
  bte.vima.austin.tx.us:26333



Some intersting items for your bytecoin.conf file:


In case you compile your own source:
This number changes from time to time.

I wonder if there are many stagnant coins that are very similar to BTC. 

Stagnant might mean fewer than 25 blocks mined in the past 3 months.

Some points of similarity would be:

• Block Time of 10 min.
• Initial Block Reward of 50 coins
• Total Issuance of 21,000,000
• SHA256

I won't post someone else's addresses without permission.  Some people are touchy about that.
Try my address again, I'm monitoring it today to be sure it is stable.

I am just moving toward all IPv6.  No change on Bytecoin's part.  I do have an IPv4 port open, however.

I show a connection from a new IP at 2018-03-04 11:43:22 (GMT) this morning that has 58126 blocks.  It disconnected without sending its new blocks to me.  Perhaps that was you.  It is not accepting reconnect requests from my node.

The old seed nodes are dead.  I think new node information has to be given to get connected.  You can do that on command line or the bytecoin.conf file, either one.

There is something a little unstable in my IPv6 configuration, and I drop the address sometimes.
Please try again, or PM (DM) me your ip and I'll see if I can connect to you.

I am repairing the Bytecoin (BTE) block-chain.  That is, I am re-calculating the block headers, but keeping all the transactions, and keeping the timestamps similar.  The process is not ready to release yet.  However, you can peek in and see the progress.  This repaired block-chain will occasionally be deleted and re-created during the forthcoming development and testing.

• I will have multiple streams of blocks in the repaired chain.  
• The Legacy blocks will be there, but the timestamps will be adjusted so that they appear to occur not significantly faster than each 10 minutes.  
• The Legacy blocks, in order to prevent double-spend attacks, will not be usable in transactions until the entire repair is finished.
• A stream of new blocks, not yet present, will be there.  When I get the stratum pool up and running, this stream will act pretty much like any other coin, and you can mine and spend from it.
• I have not made a final decision, but I may keep the difficulty at 1 for the entire repaired chain.
• There will be a transition from the time that the chain is repaired, to business as usual on the fully repaired chain.

To peek in:

• make an empty directory ~/.bytecoin/26332
• add a custom bytecoin.conf
• do not add peers.dat
• Encrypt your wallet.  Back it up.  Be cautious.
• please don't use addnode, or otherwise connect to clients running the legacy block-chain.

I have code named my technology Hard Turtle.  

I am online 24/7 with about 85% uptime.  I have 1 steady peer connection, also an IPv6 address.  I received block 58120 dated Wed Feb 28 09:58:31 2018 (CST, UTC-6)

You can use the address seed.bte.vima.austin.tx.us to try to seed some addresses.  When people give permission to me, I will add their address to this seed list.

Add the following line to your bytecoin.conf file:

seednode=seed.bte.vima.austin.tx.us

I'm considering this path.
http://iounote.vima.austin.tx.us

I am doing some testing.  When I am satisfied, I will put the source on GitHub and make an announcement in this thread.  I hoped to be finished by last April.

No.  All of the approaches that try to adjust the difficulty after the fact are working in the wrong part of the system.
I tentatively have a way to exclude blocks that are strip mined, and never include them in the block chain at all.  Then the difficulty does not have such wild excursions.