Well, that would be a plot twist.

I only have Linux.

Some history:

Way back in 2016 I did not make any progress in building bitcoin when I tried to get help from the bitcoin/bytecoin related FreeNode groups.

So I ended up making my own environment.  I put it up on GitHub in 2017, and have not really looked at it since.

I believe that this is a bunch of scripts that will build a virtual machine and then build a local copy of Bytecoin that I codenamed IOUnote.  I have not reviewed it today, or since 2017.

This was a bit fragile and a little too customized for the immediate task at hand, but it did work for me and nothing else did.  It builds the GitHub version by Ahmed Bodhi, the one that he cloned, and my branch that I call IOUnote.  These are all 0.8.x versions.

Somewhere in the build process there is a call from the virtual machine out to the VirtualBox host, and this is a Ubuntu command.  It is probably an ssh call, I don't remember.  If you are running VirtualBox on windows, I expect that things will break there.

Many newer bitcoin versions use a different build environment and I have not mastered these new environments.

The build is very specific to Trusty Tahar, with exactly the installs in the scripts.  All sorts of surprising things cause it to break, it is really fragile, so this is very constrained both in the bitcoin version and also in the Ubuntu version.

https://github.com/a-mcintosh/Trusty-preseed


Anyway, please feel free to look this over.  After I get a bit oriented as to what I did, I will make some decisions about what to do next.

I'm swamped with day job for a few more weeks.  Then I have time.

I can probably put together a VirtualBox appliance that will work.  It stretched my ability to get a good compile environment, and both Ubuntu updates and Bitcoin updates break things that take me weeks to fix.

Should not be.  Do you know of any problems?

Beginning at block 58464, a new block will have to be 3204 seconds newer than the median time of the previous 11 blocks for my node to accept it.

This is a change.  Previously, it only had to be 1 second newer.

This is 6 block-times of 534 seconds each.  This allows the difficulty to rise at 12.3% each interval (2016 blocks).  This is the historical rise calculated from the genesis block to block 469573 of the bitcoin chain.  At a target time of 600 seconds per block, the block would be 3600 seconds newer.

You may wish to allocate your hashpower with this in mind.

In addition, the timestamp cannot be more than 1 minute in the future.  Previously, this limit was 2 hours.

These are some preliminary changes toward Hard Turtle technology.

I will monitor the situation for the unexpected.

You might notice that this thread is annotated BTE.  It is not about BCN.
BTE was released on April 1, 2013.
Despite what the chart says, you may have a difficult time finding any public verifiable information about BCN prior to April 1, 2013.

Oh, I have never been able to make reliable time-frame estimates.  I can pretty much turn on the Hard Turtle extensions now, but they are not fully tested.  The problem is that there is no windows client.  I have spent my time on the extensions, and assume that someone else can compile a windows client when the time comes, and if not I can do it at the end.

So long as we are the steadfast miners, all we have to do is refuse to honor strip mined blocks, and I can do that manually, so I am not really very worried.

I mined these blocks with a slightly modified version of the Ahmed-Bodi code that I modified about 18 months ago.  This is the same code that all of you have connected with on my server.  The version that actually produced and accepted blocks had some preliminary ideas for Hard Turtle technology.  Originally I had activated them at block 58414.  I no longer remember why I chose that block number, but at the time it seemed safely far in the future.  This was not a complete solution and it rejected some blocks.

I pushed the activation block back to 58463, the end of the current interval, so they are now de-activated.  This preliminary technology is mostly obsolete, but that version of the client does have some programming jigs in place to let me get a better view of how the code works.

This past month I made a version of the client that works with cpuminer from https://github.com/pooler/cpuminer.git and allows anyone to put their bytecoin 8-address in as either "user" or "pass."  This version exposes the getblocktemplate (GBT) interface.  Last month I bought a mining contract on eBay to test this before I made an announcement, and the test failed.  This left me with a client that anyone could use with a cpu miner, but not with an ASIC.  This may be advantageous as we are fighting against strip-mining, but I still wanted to be able to use contract miners.

I decided to look for a stratum server and test whether it would work with a contract from eBay and my modifications.  The  mining of blocks 58414 to 58421 was a test of the ckpool stratum server with bytecoin.  I bought an 8 hour mining contract on eBay.  The ckpool server is on a linode, so that my personal equipment is not exposed to lots of mischief.  This test succeeded in a solo-mining configuration as you saw, but has some other problems.

I haven't decided whether to look for other stratum servers, or make some modifications to ckpool.  I haven't found a good forum to discuss these choices, so I am going much of this project alone.  
----

Sigh, this is my first major C++ project.  At this point I think I have pretty good comprehension of the block-chain structure, the code of the source client, the trade offs involved in the various decisions, a specialized application concept for the near future, and I have made "Hello World" on the Android.  

My current thought is to completely re-mine the bytecoin block-chain leaving it at difficulty 1, with all existing transactions intact, and compatible with both the legacy client and the Hard Turtle client, forking at the next interval or so.  I believe this can be accomplished in a single evening using an eBay mining contract.  There are some administrative / design decisions that go along with this.  I may re-mine the block-chain several times, once for each decision, then "let the market decide."

I think I am at the point where I can publish some of the design alternatives for comment.  I wanted to be sure I was clear headed on the ideas before I did this, and also that I was knowledgeable enough that I could finish coding faster than someone with a hostile  agenda.

I mean, the code I am running treats some things differently after for block 58463 and before vs 58464 and after.  Previously the limit was 58414, I had forgotten that, and it made a problem.

I built an instance of ckpool and connected a 1.15 TH/s miner to it.  I mined 7 blocks in 8 hours.  This was configured as a standalone miner, so it was not suitable as a mining pool with many users.

I identified a configuration problem that created difficulties at block 58414.  I have pushed that problem back to block  58463.

The database support, ckdb, did not build effortlessly so I can't bring up multi-user support at the moment.

Procedure diff_from_nbits in file libckpool.c clamps the minimum difficulty to approximately 256.  I removed that code and it works correctly with a difficulty 1 network.

Thanks for your reply.  My current approach with bitcoin is to try to understand virtually every line of code on the version I started with,
then move to the future.  At the moment, I'm marooned pretty far in the past at 0.8.1.  Real Soon Now I will leapfrog forward.

Offhand, do you know the oldest bitcoin version that is supported?

I am looking at the code below, with a small modification that I made.


Oh, and as for Bitbucket, it's just yet another login / password / interface to deal with.  I'll deal with it.

I want to set up an isolated lab where I read the software sources, execute for a bit, and see what happens.

In my particular scenario I will use an earlier version of the reference bitcoin client and download about 10,000 blocks.  The difficulty will be 1 at this point.

I will use cgminer and ckpool as well, to develop what skill I can at understanding stratum and how to configure the servers and what they do.

Toward that end I have made the most recent version of ckpool, and started it with
  ckpool -l 7 -A -H

and ckpool.conf points only to my local setup.

I appear to retreive getblocktemplates, pass info up to cpuminer/minerd, do the magic and send results back to ckpool.  ckpool.log and the consoles for cpuminer and ckpool make sense to me.

I don't grok how to get the new block submitted to my local bitcoind.

For what it's worth, I am looking at line 6225 of stratum.c.  That seems to be one place where I might expect a submitblock to happen, but it does not.

My understanding of "upstream" and whether it is necessary / possible to set up a proxy to make this happen is a bit wobbly.

Oh, and while I am posting, I thought I would mention that I am pretty familiar with GitHub, but not so much with the repository where ck has his source located.  Is there a GitHub bridge (fork) to his efforts, or do I need to figure out the new repository as part of all this effort.

I have rented a machine at linode, and have set up a node for some testing there.

You may put your address in as the user.  This can be either a bitcoin address, or a bytecoin address.

I have not been successful with the rent-an-ASIC miners with this setup.  I am able to use the J.Garzik cpu miner.  You should be able to CPU mine at the moment.

It is not defined whether I will keep or discard any blocks mined at this time.





If you make an otherwise empty .bytecoin directory and add the following to your bytecoin.conf file you should be able to follow the progress as the blocks are mined.



There will be problems.  I don't know what they will be.  This is a test.

In my current testing, I am running 2 instances of cpuminer with variations of the configuration file shown below.
The user is different in the two configuration files.

If the test is successful, the payout in the coinbase will match a correct Bytecoin address that
is provided for the user in the file.  This will open the possibility that I can run a mining server in the future.

You may wish to have a version of cpuminer operational and ready to reconfigure. 
You should be able to test it on your own machine, using the existing
client that you have.
 
This setup supports getblocktemplate.  It does not support stratum.  The current difficulty is 1.

You may also wish to submit some address to the Google form referenced above.  The submitted addresses will be tested so that they are valid, and they have received payment in a coinbase transaction.

No.  Things should work for anyone who mines.  At the current difficulty, you have to have an ASIC.  I calculate that my 83 GHz/s Avalon will take maybe 15 hours to find a block, so there may not be many willing miners at the moment.

If you absolutely want a block, you should be able to rent-a-miner online, run your own client synced up to mine, and get satisfaction.

That is the last block that I have here, Sun Aug 26 12:00:06 2018

I typically have 5 to 7 connections at any time, so I assume this is the actual state for the network.

My interpretation is that no one is mining at the moment.

Do you want to mine?

What is the last block number or hash that you have?

I just realized a significant short-cut that I can take.  I am doing that silly thing of programming with urgency, brewing much coffee, and putting off sleep.  I hope it works.

The short-cut will eliminate the need to solve a difficult problem during the transition from BTE to BTE-HT. 

I am in the flush of thinking everything is now solved.  If you have programmed very long, you will recognize this phase, and laugh.

However, some questions have a new urgency.

1.  Can anyone build the windows client?  If not, I can learn how, but it will cause a delay.
2.  How much is my effort worth, in coins?
3.  What is the name and symbol of the forked coin?  BHT, for Bytecoin-Hard Turtle, comes to mind but there is a name collision with the BitHub exchange.  I think that keeping the same name after a hard-fork will cause confusion.

I have artwork and another name ready to go, but I want to hear from the community.