I have done some analysis on the early blockchain, with a view of preventing strip-mining.

A .png of some of the graphs are at the link below.

I am confident that I am on good theoretical footing, and I am midway through modifying the client.

https://plus.google.com/u/0/photos/115426745065196075335/album/6519521612516431713/6519521612265200578?authkey=CK2wi7Gd3uaRwwE

The current block is 58,114
The difficulty is 1,056,741
I assume you mine at 12.8 Mhash/s


So it will take:

>>> (2**48 / 0xffff) * 1056741 / 12.8e6 / 60 /60 / 24 / 365.25
11.236242643851176 years, on average.

Will you take a minute and ask that question a different way?

I believe that BCN is completely unrelated to this coin.
By the way, there are a few nodes active, and sporadic blocks being mined for this coin, BTE.

Do you think anyone else ever asked that?

blockexplorer.bte.vima.austin.tx.us

The DNS entry is live now.  I did not reach a block explorer when I tried.

I have an environment that will build a VirtualBox machine, build Ubuntu Trusty 14.04, install support software, and build the Satoshi client for Ubuntu.  Some of this is correctly pushed to my git.

While this is good for individual work and good preparation for a public cooperative effort, it needs more.  The bitcoin developers have an environment that builds the clients and checks the sha256 checksums of the binaries so that the group can authenticate a build from public sources.

I got their environment to work once, but I can't seem to duplicate that process now that some time has passed.

Much of this is on my git.  If you have experience with the bitcoin development environment, I wish you would help produce scripts that will build the Linux, Windows, and other clients so that a group of developers can verify the authenticity of our Bytecoin binaries.  As of summer 2017, the bitcoin developers were using Trusty.  I spent many weeks getting a preseed file to work with Trusty, and never created one for 16.04 that satisfied me, so please don't publicly "modernize" my process to 16.04.  However, if you successfully do so privately I would love to correspond with you.

There is a considerable difference in the build environment between bitcoin 0.8.1 and 0.9.x  The latest public Bytecoin build that I have learned of is as below.  I am using this triple of (minerd, eloipool, bytecoin) commits, circa Jan 2014, to develop and test.  My wife died that month and I took a break.  I think I can move the client to 0.9.x relatively quickly, but again, I am working in Trusty 14.04 and 0.8.1.

I have not checked whether successive clean builds from the same git branch produce the same sha256.  I really should do that today.  The question in my mind is whether the time-of-day ends up changing the binaries somehow.




I also have eloipool and minerd, a triple of software that work together in my environment.  Minerd is appropriate when I make a laboratory test chain with low difficulty to test software.

I am preparing an announcement.  As part of that preparation, I hope there is a place where people can download the software.  If you know of such a place, please post current information here.

Possibly useful items are:

1.  The Satoshi client
2.  A block explorer
3.  Any current mining pools.

When I make the announcement, it will be very quiet, but also very clearly public.  I will not answer questions before the announcement.

I think the coin died because of strip-mining.  I think I have fixed that vulnerability.

Hmm.  Looks like some parts of my IPv6 setup are not being nice with each other.  Thanks for the heads up.

I'm pretty old school:  I do things from fundamentals.  I make a VirtualBox by a script, install Ubuntu from a standard public image, download the git repository, apply my patches, do a build from my own scripts.  If there were coherent public build scripts that I comprehended I would change my process to use them.

Before I would use Vagrant, I would dissect what it did.  There is a standard make process in the current Bitcoin group (Gentian?) and I did get it to work once, but in a badly limping way, and it does not work way back on Bitcoin 8.9 or so, the thing bytecoin first branched from.  I have lots of trouble getting non condescending answers to various questions from the developers, and I spent equal amounts of time rolling my own process and trying to understand the accepted build process, and I got my process working first.

Eventually I will make all of my project available on github, but I wanted to be sure that my installation of eloipool wasn't going to embarrass me.  I haven't decided whether I will release stuff when I only have a Linux version working, or if I will wait until I also have Windows and Android working.

I am willing to put the Linux client binary on my webpage immediately, but I suspect that a binary without source would be met with suspicion.

There are some items at https://github.com/a-mcintosh right now, but they are work in progress.

I have a somewhat automated environment that builds a VirtualBox, then downloads and compiles a Linux version of the client.  I have made some patches that address the strip-mining problem.  I would like some help to build a windows client.  I have built in the current bitcoin build environment using Debian, but I want something with better documentation.

My node has pretty good uptime.  The last block that I know of is Sep 3, 2016 #58114
I propose to use this address as a seed node.

The DNS name is seed.bte.vima.austin.tx.us

[2001:470:b8ac::2013:401]
67.198.113.220




--- edit ---
if you want to run a node as a seed node, let me know and I will add it to the DNS lookup for seed.bte.vima.austin.tx.us

I administer the DNS tables for vima.austin.tx.us.  I set up this subdomain.  The way DNS works, if you do a lookup for a name with multiple A or AAAA records, the records are returned in round-robin order.  Bitcoin & relatives use this to look up a seed node to, um, seed things.  There are 2 addresses that may be of interest to this group.  To find out what is in them at any specific moment, see below.

on unix:  
  dig  seed.bte.vima.austin.tx.us ANY
  dig old-seed.bte.vima.austin.tx.us ANY

in your config file:
  seednode=seed.bte.vima.austin.tx.us

for ahmed:
  in net.cpp strMainNetDNSSeed
     {"seed.bte.vima.austin.tx.us", "seed.bte.vima.austin.tx.us"},


if you control your own IPv6 address, ::2013:401 is an easily recognized number.

BTE is not BCN.

BTE has a post that dates to April 2, 2013.
BCN has a post that dates to Mar 14, 2014.

I propose to change the name of Bytecoin (BTE) to IOUnote (IOU)

Do you mean Bytecoin BTE released April 1, 2013?

I want a new procedure or so added to a private copy of the satoshi client 0.8.1. 

When finished, there should exist a new RPC call not unlike
    getcoinbasepayouts <hash> [n=1]
where n is the number of blocks to accumulate totals over.  This shall work even if the block-hash is a chain-tip that is stale.  The default for n is 1.

The output from this RPC call shall give the list of all bitcoin addresses and their corresponding amounts that were paid in coinbase transactions by block-hash and the previous n-1 blocks.  It should not be stylistically jarring compared to the other RCP responses.

Please feel free to produce a quote on producing the diff files which produce working source when applied to
    git clone https://github.com/bryan-mills/bytecoin
This alt-coin client is virtually identical to the 0.8.1 bitcoin client.  You may or may not be able to develop your code from the core 0.8.1 bitcoin client on the bitcoin block-chain if you already have that on hand.

I am still undecided whether this alt-coin was an April fool's prank or not, I am aware that the last block was mined on or near last September 2016, and that there may not be any active nodes, other than my intermittent one.

The terms will be fixed bid, pay on acceptance.  I do not think there is a large amount of work for someone already up to speed.  This request is valid for delivery by April 1, 2017, but may be re-issued.

Bitcoin is transitioning to the epoch where the block reward is small, and the block is at maximum size.  As bitcoin enters this epoch, the transaction fees become important for those transactions that are time sensitive.  This is part of the original design arc of bitcoin.  The transaction backlog has been fluctuating between 4,000 and 50,000 transactions during the past few weeks.  As is usual in the bitcoin world, the comments regarding this vary wildly in connection to reality and paranoia content.

You may wish to know the current backlog and fee recommendations when you submit a payment. As I write this, that recommendation is 160 satoshis / byte for inclusion in the next block.  That is the same as 0.00160000 BTC / kb.

The block explorer is showing about 2,000 transactions each block, and about 999 kb for each block, so the system itself is chugging along like a well oiled machine.  You are just stuck in traffic while the HOV lane moves past you.

If your user is sophisticated, they can construct a transaction to spend their output from the stuck transaction, and include a large enough fee to sweep both your transaction and theirs into an early confirmation.  Actually, anyone who has an output from the transaction can do this.  It is difficult to give more detailed commentary without a TxID to review.  They probably should not make their first attempt at this on a 25 BTC transaction.

Your transaction is 402 bytes in size.  At the moment, the recommended transaction fee is 160 satoshis / byte, so your transaction should have 64,320 satoshis (0.00064320 BTC) to be included in the next block.  You included 0.0002431 BTC, so you are not in the fast lane.

These both show as included in block    449976