i am curious why the official website not update the client after the official chain launch, as the official client is connected to invalid chain now.

Oh.  I don't know about that.  I didn't see any binaries on the official site.  If the code in the GitHub repo is set to mine to the wrong genesis block then so is the binary I posted earlier, take note.


Edit: On this topic and to people coming from here, I think you are getting confused by this -- the NoirShares beta (last updated two days ago) and this (last updated 12 hours ago) which looks a bit less like a beta.

The binary I provided is built off the latter repository.

I'm not affiliated with the project and don't know if my conjecture is right, but that's what I think is happening here.

Quote from: barwizi on February 15, 2014, 12:50:21 am

Quote

All modified redistributions will allocate 7% of their total lifetime value supply units to Noirshares at genesis
of said redistribution, also further allocate 3% of their total lifetime value supply units to Protoshares.

that is a quote from the license, it's been there all along.

What license?

The one in the source code, I'd think.

On the topic of mining, I find that whether I hit a block in the first day really colours my appreciation of a coin/commodity/token.

Sorry for not getting to this yesterday, had to deal with some snow.

In any case, I think I'm done.  See pull request here.

A few caveats:


0) Haven't tested it yet (beyond that it compiles and that the generated C++ code properly dumps keys -- haven't tested the glue C++.)  I'll get on that as time permits in the next day or two.


1) I'm especially unsure about
fc::datastream<const char*> stream(keys[i].c_str(), keys[i].size());
fc::sha256 bits;
stream >> bits;
keysRet.push_back(fc::ecc::private_key::regenerate(bits));
I took it from DerKorb's multibit wallet import implementation.  In my case keys{i} is going to be a 51-character, starts-with-a-5 style uncompressed key -- but I haven't looked into whether that's what he was dealing with as well.


2) The cython-generated C++ file isn't very clean.  I realized that a better way to do things than to make a minimal private key extractor from the electrum code would be to minimally modify the electrum code, thereby making it easier to keep the import function working should electrum change the way they handle wallets.  In any case I added to vendor (wrong place, I know, there wasn't anywheres that fit too well) a makefile script and patch that lets one copy over the electrum lib directory and easily regenerate the C++ code.


3) I made the cmake file rely upon python 2.7.5 exactly.  This isn't right, we just need python 2.x, but I cannot for the life of me figure out how to set a maximum (minimum required versions are easy) that cmake will find and it always goes for 3.3 on my system.

FC_ASSERT( fc::exists( wallet_dat ), "unable to find ${wallet}", ("wallet",wallet_dat) ) is better than returning nothing...
or better yet use FC_THROW_EXCEPTION( file_not_found... )

Done.  Here are my changes as they currently stand, https://github.com/tiau/BitShares/compare .  I haven't initiated a pull request since I'm still waiting on boost to be able to test the changes.  There are almost certainly bugs in the not-cython-generated C++ portion and I doubt I did the CMakeList.txt changes right either...

One question: Is electrum_python.cpp okay as it stands (50,000 lines of mostly dead code) since the C++ compiler will remove all the cruft anyways or should it be cleaned up?

Proof of burn is riskier than PTS/AGS as well.   Keep in mind:

"Disclaimer: The code being released here is of alpha-quality and under heavy development. You should expect to encounter significant bugs when using it. It is even possible that a bug might cause you might lose some money. The Counterparty team will do everything in its power to prevent this from happening, but this technology is very new, and the implementation is not yet well-tested. In particular, we may at some point have to change the Counterparty protocol in a not backwards-compatible way, if such a change is necessary to fix a bad bug or an exploit. As always, don't invest more than you can afford to lose."

PTS and AGS have no such issue.  If the test bitshares fail due to bugs, they fail; but test bitshares 2 will simply take on the mantle and carry on.

The "BitShares X" page reads, "Earn 5% or more on anything." even though that no longer seems to be the case re: this.

I don't know if that counts as a typo, per se.