Search content
Sort by
Showing 16 of 16 results by JobCreator
Re: [ANN]LGD Legendary Coin - Cryptsy,Bittrex,NEW Merchants, Many Games, Scrypt!
wake up guys, just open a exchange, we have to make roadmap.
I don't think anyone wants to touch this.
New developer needs to copy/paste from a new source and re-launch this as Legendarycoin 2.0. Or just make a new coin.
Or better yet... move on, make up your losses, buy 100k Zetacoins now, at 1100, and sell them later at 2000.
Apparently there is a new twist
Most of these NINJA launches had something extra to them:
https://gist.githubusercontent.com/Earlz/41c5c18113210d3c36f9/raw/4d14022e3c75a6a10c653bd98831fd3bbded79a1/gistfile1.txt
Most of these NINJA launches had something extra to them:
https://gist.githubusercontent.com/Earlz/41c5c18113210d3c36f9/raw/4d14022e3c75a6a10c653bd98831fd3bbded79a1/gistfile1.txt
windows wallet wont send. 
Hmm, buggy wallets. Typical NINJA launch scenario playing out. See for more information:
https://bitcointalk.org/index.php?topic=1089206.0
So says the guy who posted THREE topics about Zetacoin in the Alt discussion.
Beware of anything Zetacoin, ConspiracyChef, Konen, BitcoinSachs, Internet Kiosk and Bryce Weiner related too while we're at it.
Dude, we get it. You hate Zetacoin and pretty much every altcoin. Zetacoin Express has at least created dedicated topics, your just spamming your anti-zetacoin rhetoric all over the place.
For those who don't know what a 'NINJA launch' is:
It is when a new coin with pretty icons, graphics, and a slick looking wallet is all of a sudden announced without any prior notice. Everyone rushes to setup pools and insta-mine it. These coins usually tend to be PoS coins with a very short initial PoW minting period. The wallets also tend to be buggy.
After a few hours of mining, PoS kicks in, PoW ends, the 'developer' give a sense of commitment, a strong following emerges. Within a few days the coin gets added to exchanges, promises start being made, believers start believing it's the next big thing, wallets gets updated, roadmaps, hard forks, etc..
Once on an exchange the price starts rising, greed begins to emerge, miners start selling off. The price takes small dip due to the initial unloading by miners who need to pay for the rented hash/asicis. But soon it starts to rise higher as the 'sheep' start getting fooled into buying. Holders start staking and unloading on to these poor souls.
Finally the so called 'developer' dumps his bag and moves on to the next scheme. Within a few days, the 'developer' disappears and the coin gets de-listed from the exchanges. The hopes and dreams of the sheep are crushed.
It's quite an entertaining spectacle. The threads posted are a great example of what such a scheme looks like from start to end.
Early adopters with powerful ASIC's or lots of BTC to rent hash power have the most to gain, second only to the 'developer' (this really needs a better name).
100% of the time there is one 'developer' (better named in this case a ponzi) who spends a few weeks cloning a few coins, then releases them one after another in a series of "NINJA" launches. Rinse, repeat. This person, having access to the source either creates a prime, or insta-mines several blocks moments prior to and after release.
It is when a new coin with pretty icons, graphics, and a slick looking wallet is all of a sudden announced without any prior notice. Everyone rushes to setup pools and insta-mine it. These coins usually tend to be PoS coins with a very short initial PoW minting period. The wallets also tend to be buggy.
After a few hours of mining, PoS kicks in, PoW ends, the 'developer' give a sense of commitment, a strong following emerges. Within a few days the coin gets added to exchanges, promises start being made, believers start believing it's the next big thing, wallets gets updated, roadmaps, hard forks, etc..
Once on an exchange the price starts rising, greed begins to emerge, miners start selling off. The price takes small dip due to the initial unloading by miners who need to pay for the rented hash/asicis. But soon it starts to rise higher as the 'sheep' start getting fooled into buying. Holders start staking and unloading on to these poor souls.
Finally the so called 'developer' dumps his bag and moves on to the next scheme. Within a few days, the 'developer' disappears and the coin gets de-listed from the exchanges. The hopes and dreams of the sheep are crushed.
It's quite an entertaining spectacle. The threads posted are a great example of what such a scheme looks like from start to end.
Early adopters with powerful ASIC's or lots of BTC to rent hash power have the most to gain, second only to the 'developer' (this really needs a better name).
100% of the time there is one 'developer' (better named in this case a ponzi) who spends a few weeks cloning a few coins, then releases them one after another in a series of "NINJA" launches. Rinse, repeat. This person, having access to the source either creates a prime, or insta-mines several blocks moments prior to and after release.
Re: Will Monero have to rebrand because of the cease and desist notification?
"Moneero" is registered in a small South American country and has no ties to "Monero" which stands for a decentralized currency. They are words in different languages, presumably, so this c n d is worthless. I believe it's all lies/fud regardless.
Doesn't matter if the words are spelled differently. The two names are similar and fall under the same Goods and Services category.
It's like if I were to open a hamburger restaurant, and name it "Whendees"
The minting phase for several of these older altcoin that are currently seeing a price rise has pretty much ended or is ending soon. For some it may be a temporary boost, for others, it could be a permanent boost.
Just because no one posts on the thread, or the 'developer' is absent, doesn't mean a coin is dead. So long as the blockchain is moving, it's alive and well.
It took Bitcoin 4 years to get to where it is today. Many of these altcoins are no more than 1 year old.
Exactly. The real winners are those who held and accumulated for long term investment.
Those with the 'mine & dump' methodology, who made a small profit in the beginning will ultimately be the biggest losers.
Just because no one posts on the thread, or the 'developer' is absent, doesn't mean a coin is dead. So long as the blockchain is moving, it's alive and well.
It took Bitcoin 4 years to get to where it is today. Many of these altcoins are no more than 1 year old.
Any new coin that wants to be a longterm project and real money token will also have to go through accumulation phase and pow mining with halvings when during early stages people will say "it's dead" while smart money buys.
Exactly. The real winners are those who held and accumulated for long term investment.
Those with the 'mine & dump' methodology, who made a small profit in the beginning will ultimately be the biggest losers.
Received some replies but nothing final yet. This is still open. I've gone ahead and started some of the work...
poller.py
updater.py
block_chain_interface.py
A 'finalized_block' will have these methods:
poller.py
Code:
# Manually compares the 'prevhash' to detect a new block and/or update the Merkle tree.
class Poller(object):
def _init_(self, _rpc, _block_chain, _interval = 60):
self.RPC = _rpc
self.BLOCK_CHAIN = _block_chain
self.INTERVAL = _interval
def setInterval(self, _interval):
self.INTERVAL = _interval
class Poller(object):
def _init_(self, _rpc, _block_chain, _interval = 60):
self.RPC = _rpc
self.BLOCK_CHAIN = _block_chain
self.INTERVAL = _interval
def setInterval(self, _interval):
self.INTERVAL = _interval
updater.py
Code:
# Retrieves data via the 'getblocktemplate' RPC call
class Updater(object):
def _init_(self, _rpc):
self.RPC = _rpc
def Update(self, force = False):
raise NotImplementedError("Not implimented")
class Updater(object):
def _init_(self, _rpc):
self.RPC = _rpc
def Update(self, force = False):
raise NotImplementedError("Not implimented")
block_chain_interface.py
Code:
class InterfaceBlockChain(object):
def _init_(self):
raise NotImplementedError("This interface must be implimented")
def Submit(self, finalized_block):
raise NotImplementedError("This interface must be implimented")
def Update(self):
raise NotImplementedError("This interface must be implimented")
def GetData(self):
raise NotImplementedError("This interface must be implimented")
def Set_OnSubmit(self, _call_back):
raise NotImplementedError("This interface must be implimented")
def Set_OnUpdate(self, _call_back):
raise NotImplementedError("This interface must be implimented")
def _init_(self):
raise NotImplementedError("This interface must be implimented")
def Submit(self, finalized_block):
raise NotImplementedError("This interface must be implimented")
def Update(self):
raise NotImplementedError("This interface must be implimented")
def GetData(self):
raise NotImplementedError("This interface must be implimented")
def Set_OnSubmit(self, _call_back):
raise NotImplementedError("This interface must be implimented")
def Set_OnUpdate(self, _call_back):
raise NotImplementedError("This interface must be implimented")
A 'finalized_block' will have these methods:
Code:
class FinalizedBlock(object):
def getHash(self):
def getHex(self):
def getRaw(self):
def getHash(self):
def getHex(self):
def getRaw(self):
More details about the design as requested. Anyone is free to submit feedback and offer suggestions.
BlockChain
Interface for implementation of PrimaryBlockChain and AuxiluryBlockChain objects. This is already complete (source will be provided), these methods should be implemented when extending this object.
PrimaryBlockChain
Implements a BlockChain Interface. It is used by the Engineer object as a means of data retrieval and block submission for the network where PoW is being performed.
Public Methods
Submit
The engineer will 'submit' a solution (aka: share/block) to the PrimaryBlockChain object using this method. The solution has already been validated and finalized into a submittable block by the Engineer.
This should be a deferred method where the program does not block execution while the PrimaryBlockChain processes the submission. When the block is accepted/rejected the method specified by 'Set_OnSubmit' should be called with the resulting information.
If the block is accepted, the PrimaryBlockChain object should perform an update request.
Update
The engineer may call this method upon program initialization for initial construction of a block template. It's also possible that this method may be called by the engineer via an external process (such as a new block notification mechanism)
This should be a deferred where the program does not block execution while the PrimaryBlockChain waits for data. Once data is received the method specified by 'Set_OnUpdate' should be called with the resulting information.
GetData
Allows the on demand retrieval of the currently loaded data (cached) from when the last update was run. This method may be called by the Engineer when checking for block candidates and may be called by the Poller when comparing cached data with live data.
Set_OnSubmit
This method allows the Engineer to set a callback method to be executed upon a successful or failed block submission.
Set_OnUpdate
This method allows the Engineer to set a callback method to be executed any time new data is received from the upstream network.
Call Backs
These are the callbacks as set by the 'Set_OnXXXX' public methods.
Return an indication of a successful or failed block submission with block hash and height as additional information. If submission failed, then no additional data is provided.
Returns a data package containing all the information necessary to construct a block template. Basically it should be whatever the 'getblocktemplate' RPC call returns.
Object Initialization
The constructor should require that an RPC object be provided during initialization.
Updater
Internal object responsible for retrieving data via the 'getblocktemplate' RPC call. Used by BlockChain implementing objects and Poller.
Public Methods
Update
This is what begins the actual 'update' process. An optional parameter is passed indicating if this should be a 'forced' update (false by default).
Object Initialization
The constructor should require that an RPC object be provided during initialization.
Poller
Internal object responsible for manually comparing the 'prevhash' to detect a new block and/or update the Merkle tree.
Public Methods
SetInterval
Self Explanatory, allows the ability to specify a polling interval.
Object Initialization
The constructor should require that an RPC object be provided during initialization.
RPC
The Updater, Poller, and PrimaryBlockChain objects utilize this as a means of communicating with the upstream network. This is already implemented, the following methods are exposed:
BlockChain
Interface for implementation of PrimaryBlockChain and AuxiluryBlockChain objects. This is already complete (source will be provided), these methods should be implemented when extending this object.
Code:
def Submit(self, solution):
def Update(self):
def GetData(self):
def Set_OnSubmit(self, _call_back):
def Set_OnUpdate(self, _call_back):
def Update(self):
def GetData(self):
def Set_OnSubmit(self, _call_back):
def Set_OnUpdate(self, _call_back):
PrimaryBlockChain
Implements a BlockChain Interface. It is used by the Engineer object as a means of data retrieval and block submission for the network where PoW is being performed.
Public Methods
Submit
The engineer will 'submit' a solution (aka: share/block) to the PrimaryBlockChain object using this method. The solution has already been validated and finalized into a submittable block by the Engineer.
This should be a deferred method where the program does not block execution while the PrimaryBlockChain processes the submission. When the block is accepted/rejected the method specified by 'Set_OnSubmit' should be called with the resulting information.
If the block is accepted, the PrimaryBlockChain object should perform an update request.
Update
The engineer may call this method upon program initialization for initial construction of a block template. It's also possible that this method may be called by the engineer via an external process (such as a new block notification mechanism)
This should be a deferred where the program does not block execution while the PrimaryBlockChain waits for data. Once data is received the method specified by 'Set_OnUpdate' should be called with the resulting information.
GetData
Allows the on demand retrieval of the currently loaded data (cached) from when the last update was run. This method may be called by the Engineer when checking for block candidates and may be called by the Poller when comparing cached data with live data.
Set_OnSubmit
This method allows the Engineer to set a callback method to be executed upon a successful or failed block submission.
Set_OnUpdate
This method allows the Engineer to set a callback method to be executed any time new data is received from the upstream network.
Call Backs
These are the callbacks as set by the 'Set_OnXXXX' public methods.
Return an indication of a successful or failed block submission with block hash and height as additional information. If submission failed, then no additional data is provided.
Returns a data package containing all the information necessary to construct a block template. Basically it should be whatever the 'getblocktemplate' RPC call returns.
Object Initialization
The constructor should require that an RPC object be provided during initialization.
Updater
Internal object responsible for retrieving data via the 'getblocktemplate' RPC call. Used by BlockChain implementing objects and Poller.
Public Methods
Update
This is what begins the actual 'update' process. An optional parameter is passed indicating if this should be a 'forced' update (false by default).
Object Initialization
The constructor should require that an RPC object be provided during initialization.
Poller
Internal object responsible for manually comparing the 'prevhash' to detect a new block and/or update the Merkle tree.
Public Methods
SetInterval
Self Explanatory, allows the ability to specify a polling interval.
Object Initialization
The constructor should require that an RPC object be provided during initialization.
RPC
The Updater, Poller, and PrimaryBlockChain objects utilize this as a means of communicating with the upstream network. This is already implemented, the following methods are exposed:
Code:
def call(self, method, params):
def submitblock(self, block_hex, hash_hex, raw_hex, method, num_retries):
def getinfo(self):
def getblocktemplate(self, num_retries):
def prevhash(self):
def validateaddress(self, address):
def getdifficulty(self):
def blockexists(self, hash_hex):
def set_getblocktemplate_pollformat(self, format):
def set_has_submitblock(self, enabled):
def submitblock(self, block_hex, hash_hex, raw_hex, method, num_retries):
def getinfo(self):
def getblocktemplate(self, num_retries):
def prevhash(self):
def validateaddress(self, address):
def getdifficulty(self):
def blockexists(self, hash_hex):
def set_getblocktemplate_pollformat(self, format):
def set_has_submitblock(self, enabled):
Design Discussion
The design can be publicly discussed here. Lets start with the following image:
http://s16.postimg.org/6eza6g0a9/New_Merge_Mine_Design.jpg
You will be working on writing code to implement the BOTTOM RIGHT corner.
To be clear, you will be programming:
* The RPC object is already complete.
Anyone is free to post thoughts.
The design can be publicly discussed here. Lets start with the following image:
http://s16.postimg.org/6eza6g0a9/New_Merge_Mine_Design.jpg
You will be working on writing code to implement the BOTTOM RIGHT corner.
To be clear, you will be programming:
- PrimaryBlockChain
- Poller
- Updater
* The RPC object is already complete.
Anyone is free to post thoughts.
[UPDATED] [HIRING] Python Programmer for stratum-mining improvements
EDITED:
Shame on me for originally offering a 0.2 acceptance payment. Oh well, live and learn.
Anyway, I need someone (preferably a senior forum member, but not required) who is familiar with Python and Twisted to assist me in finalizing some customizations for a forked version of slush0's stratum-mining server.
Please make sure you read through my posts in this topic as they provide full details of the work that is to be done.
Need
I require a Python programmer for a 4 hour gig. No more no less.
Compensation
Payment is 0.5 BTC. Divided into 4 parts.
Payment Schedule
Requirements:
- Advanced level Python programmer (you use design patterns such as dependency injection and factories)
- Familiarity with Python Twisted (deferred calls, callbacks, HTTP client)
- Very knowledgeable about Bitcoin blockchain technology (for example, you know how to build a valid coinbase transaction, you know what a merkle tree is, you understand merge mining)
- Familiar with slush0/stratum-mining
Info:
The 'design' is already complete. Your job is to write code in Python. An experienced programmer can do this in less than 2 hours, but I am paying for 4 hours regardless.
I maintain a fork of a heavily improved and modified version of 'stratum-mining'. Currently being used in production on a popular well known mining pool. The code is of course open source but not yet public.
You will be completing some enhancements to this codebase. Rest assured that the code you will be working with is not currently part of the existing slush0/stratum-mining release.
Shame on me for originally offering a 0.2 acceptance payment. Oh well, live and learn.
Anyway, I need someone (preferably a senior forum member, but not required) who is familiar with Python and Twisted to assist me in finalizing some customizations for a forked version of slush0's stratum-mining server.
Please make sure you read through my posts in this topic as they provide full details of the work that is to be done.
Need
I require a Python programmer for a 4 hour gig. No more no less.
Compensation
Payment is 0.5 BTC. Divided into 4 parts.
Payment Schedule
- 0.125 BTC paid upon submission of first milestone - Completion of poller.py
- 0.125 BTC paid upon submission of second milestone - Completion of updater.py
- 0.125 BTC paid upon submission of third milestone - Completion of PrimaryBlockChain.py
- 0.125 BTC paid upon job completion - Code is tested and determined to be working to my needs.
Requirements:
- Advanced level Python programmer (you use design patterns such as dependency injection and factories)
- Familiarity with Python Twisted (deferred calls, callbacks, HTTP client)
- Very knowledgeable about Bitcoin blockchain technology (for example, you know how to build a valid coinbase transaction, you know what a merkle tree is, you understand merge mining)
- Familiar with slush0/stratum-mining
Info:
The 'design' is already complete. Your job is to write code in Python. An experienced programmer can do this in less than 2 hours, but I am paying for 4 hours regardless.
I maintain a fork of a heavily improved and modified version of 'stratum-mining'. Currently being used in production on a popular well known mining pool. The code is of course open source but not yet public.
You will be completing some enhancements to this codebase. Rest assured that the code you will be working with is not currently part of the existing slush0/stratum-mining release.