Topic: DILEMMA: Should I release a new clone-able codebase? (Read 1245 times)

Already is, see the previous post.. although it needs to be generalised and documented a little before it's ready to fork properly.

Open source is the way to go , code should be released.

The pre-release of Bitmark/Pfennig on TEMPORARY chains is available here cross compiled for windows and linux.

You can find details on variables/ports on the wiki.

If you'd like to test installing / uninstalling feel free. To test functionality and get some test coins, or test miners against the build please let me know via pm and I'll give you an addnode and some test coins.

To follow Bitmark/Pfennig development see the announcement

I will, there is a question of licenses. I want to use the unlicense whereas the original bitcoin codebase uses a different license. I'll look in to this later.

Release any code you can for common good! open-source rulez

The stratum-mining issue has resolved itself. Apparently only blocks below the height of 16 are affected, everything over is fine.

I hope that as the project grows more people will contribute and maintenance will be devolved. I have consulted the community and worked out a self supporting development budget so team members would be remunerated for their work done by the project itself.

I am aware of the pseudonym issue and have weighed it up. This is a programming project in beta mode, not an IPO or an organization seeking start up investment, looking to get on to exchanges, or anything like that. Merit of the project should be entirely based on work done and it's own value proposition. I am committed to the project completely, but I do not want it to define my identity forever.

To quote from the bitmark wiki:

Part of the Bitmark project also includes merging tagged releases of the Bitcoin project, I will be creating a semi automated patching process which allows the development team to sanely update the codebase. It must be semi automated as the codebase isn't a direct clone, it's a fork with alternative functionality and changes.

The RI release discussed in this thread will have patches pushed to it from both Bitmark and Bitcoin. I will automate this process as much as is feasible.

I'd like to thank you Graham for the work you have done for the alternative coin community, for your well thought out feedback regarding my own project, and for hosting a test node.

Mark Pfennig  

Are you thinking of setting up a github org to host the source so that maintenance can be devolved to a group rather than a single-owner, single-dev model? That's the model that I have (hopefully) chosen for the DOACC project.

In other work, we've been following a similar notion but looking at a range of approaches, e.g. investigating Darkcoin variants:

https://github.com/gjhiggins/zendarkcoin-algos/commit/b30c940aaeb053af943da437e26ce5bc1131ace6

We integrated much of that work for the creation of minkiz foundry. It's tongue-in-cheek, up to a point - we intend to make the templates available under an open source licence.

Whilst it would be trivial to go the extra distance and publish the chunk of straightforward Python code that renders the templates as full-on forks of the main Bitcoin Core development stream, we're stopping short of that point. We're happy to work with named devs to help them set up a reliable, robust and contemporaneous codebase but we won't be doing any commercial work with coin developers who operate behind a pseudonym - for us, the loss of transparency is profoundly unsupportable.


We share your thinking on i) explicitly recognising and accepting the current reality & ii) the desirability of making high-quality templates available so that (the inevitable) investors get at least some basic support from a reliable and checkable codebase as a foundation.

We have ambitions for a future where investors show a marked preference for coins based on established, branded, open source templates of assured quality --

“Does it use a Minkiz template? No? Then it's a SHITCOIN!!!!”

(Minkiz templates will be advertised along with Feckle Freezers. You do own a Feckle Freezer, don’t you? ...).

Cheers

Graham

Edit: fix typos

Ticket opened with every detail I could gather: https://github.com/Crypto-Expert/stratum-mining/issues/349

If you're working on it and need more input, just ping me here.

Thanks, I'll open a ticket on github with some logs for you.

yep i can certainly do that. i actually need to rewrite a lot of the stratum code

That's a good enough reply for me.

Whilst you're here, the codebase requires a minor change to stratum-mining, is that under your control?
nHeight for v2 blocks isn't being created correctly and blocks are rejected, all other mining software like minerd, cgminer all works fine, only stratum-mining doesn't.

please do it. as a pool operator these shitcoins based on old crap are becoming a nightmare

As part of the Bitmark project, I've essentially recreated a new scrypt code base, it's based on bitcoin 0.9.2.1, with scrypt support added, and done properly. This means every upgrade and improvement to bitcoin is included. Also all conditional BIPs are unconditionally supported from block 1 on all three networks (testnet, mainnet, regression network).

The project is currently at a stage where I could fork it and release the code for others to clone and use. Before I make Bitmark specific alterations.

My rationale is that people will clone coins anyway, so I may as well do what I can to ensure those clones are based on new tested and safe code, rather than old copied and modified code which hasn't been updated and has had god knows how many bugs introduced.

I'm seeking the alt coin communities guidance on this before I take any action.

Thank you