How to get started with Bitcoin mining.

Something is rotten in the state of DOGE mining

Shibes, something stinks in doge land. A problem in the design of dogecoin means that dishonest (or perhaps we should call them "creative") miners can take a disproportionate share of rewards, leaving everyone else to earn less than they deserve. Many of you have probably noticed that calculators estimate payouts larger than what you earn in practice (for example, dustcoin estimates ~1500DOGE/day @ 200KH/s while Non Stop Mine pays about a quarter of that rate), and most have written it off as bad luck: the blocks your pool found happened to be small, or your pool happened to be unlucky, and such is life. At least another friendly Shibe is having a better day, and it'll come around in tips anyway! Unfortunately, the truth is much darker.
The "random" DOGE rewards per block are not random. In fact, the value of each block is predetermined by a simple equation applied to the hash of the previous block. A creative miner can take advantage of this fact to mine dogecoin when the potential reward is high, and switch to litecoin when the potential reward is low. During some rounds, the reward is so small it isn't worth the electricity spent finding it; during more rounds, the reward is less than can be earned mining LTC; in a few rounds, the reward is spectacular. Honest miners mine with the expectation of earning an average of 500,000 DOGE per block, but when people are selectively mining the high-profit DOGE rounds, the average reward falls for honest miners.
So the question is: is this problem theoretical, or are honest miners really losing value to cheaters? I spent some time digging, and it appears that cheating is rampant! There are a few ways cheating can be detected.
If there is outside competition for high-value blocks, then pools should on average be finding blocks worth less than 500,000 DOGE (because some of the valuable blocks, but none of the low-value blocks, will be found by cheaters). The largest pool, Dogehouse, reports some useful averages: over all time, the pool has found 11,241 valid blocks worth 5365077071.0746 DOGE, for an average of 477,277 DOGE (including fees, which should actually raise the average above 500,000!). That's 4.5% below the expected average block value. Is it simply bad luck? No. With so many blocks found, there's about a 7% chance that the average will be above 505,000 or below 495,000; there's a <<1% chance their average will be above 510,000 or below 490,000, and effectively NO chance of seeing an average below 485,000. 477,000 is simply preposterous. Dogepool is either mind-bogglingly unlucky, or something is fishy.
Maybe Dogehouse is doing something fishy...but we can look at other pools. Dogechain's pool's all-time average block value is similar: 478847 DOGE. They're a smaller pool so the odds of this being bad luck aren't astronomical, but it's not very likely. Fast-pool's average is 477892. They're big enough that the odds are again astronomical.
And this only accounts for people cheating outside of the pools. Cheaters can operate inside our pools (more on this later)!
Maybe there's something wrong with the pools. They mostly run similar software. All their owners could be lying to us. We can check for signs of cheating independent of the pools: if more people are mining high-value blocks than low-value blocks, the hash-rate will be higher when the next block is high-value, so high-value blocks will be found faster than low-value blocks. Here's what you find if you look at 5000 recent blocks (blocks 80,001 to 85,000) and measure the average time to find a block, broken out by the block value:
I had to drop about 50 blocks which were missing good timestamps, but they're evenly distributed and shouldn't skew the averages.
The pattern is clear: the network is finding high-value blocks significantly faster than low-value blocks. Low-value rounds take as much as 10% longer than intended, and high-value rounds take around 5% less time than intended. Significant hashrate belongs to miners that cheat.
I mentioned cheaters can operate inside our pools. The payment algorithms used by most pools were carefully designed for bitcoin's (effectively) fixed block reward. They reliably protect against cheaters trying to hop in and out of pools based on short-term profitability, by making payouts solely dependent on the unknowable future (the straightforward pool payment schemes allow cheaters to look at a pool's recent history and use that to take an unfair share of its earnings; read this awesome paper for details). Since the future reward for a bitcoin pool is completely unknowable, PPLNS does not protect against a hopper who knows the future. In the case of Dogecoin, the future reward IS knowable, and PPLNS offers no protection.
Dogehouse is so big we can reasonably assume they'll find any particular block. Dogehouse is using a PPLNS target similar to an ordinary round's length. Someone who mines only during high-value rounds will, with high confidence, earn significantly more DOGE per share submitted than someone who mines Dogecoin 24/7. They also experience much lower variance in earnings.
The random block reward size needs to be removed. It's fun, but it rewards cheaters. Developing a more secure random block value selection technique is possible, but based on observations of GitHub, I do not trust the Dogecoin creator to get it right. Even subtle errors re-open the opportunity for cheating.
While I believe cheating is already unacceptably common, many will disagree until it worsens. To force the issue, I've included everything you need to join the cheaters.
Patch dogecoin/src/main.cpp:
diff --git a/src/main.cpp b/src/main.cpp index 2af23af..8c32dad 100644 --- a/src/main.cpp +++ b/src/main.cpp @@ -1794,6 +1794,8 @@ bool CBlock::ConnectBlock(CValidationState &state, CBlockIndex* pindex, CCoinsVi prevHash = pindex->pprev->GetBlockHash(); } +fprintf(stdout, "Next block value: %lld\n", GetBlockValue(pindex->nHeight, 0, GetHash())); +fflush(stdout); if (vtx[0].GetValueOut() > GetBlockValue(pindex->nHeight, nFees, prevHash)) return state.DoS(100, error("ConnectBlock() : coinbase pays too much (actual=%"PRI64d" vs limit=%"PRI64d")", vtx[0].GetValueOut(), GetBlockValue(pindex->nHeight, nFees, prevHash))); 
Perl script to control cgminer:
#!/usbin/perl use strict; use warnings; my $ltcMiner = "192.168.1.1 4029"; my $dogeMiner = "192.168.1.1 4028"; open (INSTREAM, "dogecoind|") or die; my $lastPool = 0; # LTC while (my $line = ) { if ($line =~ /Next block value: ([\d].*)/) { my $val = $1; if ($val >= 70000000000000) { # High-value DOGE round if ($lastPool == 0) { # Switch from LTC to DOGE $lastPool = 1; &onoff($dogeMiner, "en"); &onoff($ltcMiner, "dis"); } else { # Already mining DOGE } } elsif ($lastPool == 1) { # Low-value DOGE round and currently mining DOGE $lastPool = 0; print " Switching to LTC\n"; &onoff($ltcMiner, "en"); &onoff($dogeMiner, "dis"); } else { # Low-value DOGE round; already mining LTC anyway } } } close (INSTREAM); exit; sub onoff { my $miner = shift; my $enDis = shift; open (OUT1, "|nc $miner") or die $!; print OUT1 "gpu${enDis}able|0"; close (OUT1); } 
Then, simply run two instances of cgminer with separate API ports, one configured for LTC and the other configured for DOGE.
submitted by DisappointedShibe to dogemining [link] [comments]

So you’ve got your miner working, busy hashing away … but what is it really doing?

Posted for eternity @ https://vertcoin.easymine.online/articles/mining
Your miner is repeatedly hashing (see below for detail about a hash) a block of data, looking for a resulting output that is lower than a predetermined target. Each time this calculation is performed, one of the fields in the input data is changed, and this results in a different output. The output is not able to be determined until the work is completed – otherwise why would we bother doing the work in the first place?
Each hash takes a block header (see more below, but basically this is a 80-byte block of data). It runs this through the hashing function, and what comes out is a 32-byte output. For each, we usually represent that output in hexadecimal format, so it looks something like:
5da4bcb997a90bec188542365365d8b913af3f1eb7deaf55038cfcd04f0b11a0 
(that’s 64 hexadecimal characters – each character represents 4-bits. 64 x 4 bits = 256bit = 32 bytes)
The maximum value for our hash is:
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 
And the lowest is:
0000000000000000000000000000000000000000000000000000000000000000 
The goal in Proof-of-Work systems is to look for a hash that is lower than a specific target, i.e. starts with a specific number of leading zeros. This target is what determines the difficulty.
As the output of the hash is indeterminate, we look to statistics and probability to estimate how much work (i.e. attempts at hashing) we need to complete to find a hash that is lower than a specific target. So, we can therefore assume that to find a hash that starts with a leading zero will take, on average, 16 hashes. To find one that will start with two leading zeros (00), we’re looking at 256 hashes. Four leading zeros (0000) will take 65,536 hashes. Eight leading zeros (00000000) takes 4,294,967,296 hashes. So on and so on, until we realize that it will take 2 ^ 256 (a number too big for me to show here) attempts at hitting our minimum hash value.
Remember – this number of hashes is just an estimate. Think of it like rolling a dice. A 16-sided dice. And then rolling it 64 times in a row. And hoping to strike a specific number of leading zeros. Sometimes it will take far less than the estimate, sometimes it will take far more. Over a long enough time period though (with our dice it may take many billions of years), the averages hold true.
Difficulty is a measure used in cryptocurrencies to simply show how much work is needed to find a specific block. A block of difficulty 1 must have a hash smaller than:
00000000FFFF0000000000000000000000000000000000000000000000000000 
A block of difficulty 1/256 (0.00390625) must have a hash lower than:
000000FFFF000000000000000000000000000000000000000000000000000000 
And a block of difficulty 256 must have a hash lower than:
0000000000FFFF00000000000000000000000000000000000000000000000000 
So the higher the difficulty, the lower the hash must be; therefore more work must be completed to find the block.
Take a recent Vertcoin block – block # 852545, difficulty 41878.60056944499. This required a hash lower than:
000000000001909c000000000000000000000000000000000000000000000000 
The achieve finding this, a single miner would need to have completed, on average 179,867,219,848,013 hashes (calculated by taking the number of hashes needed for a difficulty 1 block - 4,294,967,296 or 2 ^ 32 or 16 ^ 8 – and multiplied by the difficulty). Of course, our single miner may have found this sooner – or later – than predicted.
Cryptocurrencies alter the required difficulty on a regular basis (some like Vertcoin do it after every block, others like Bitcoin or Litecoin do it every 2016 blocks), to ensure the correct number of blocks are found per day. As the hash rate of miners increases, so does the difficulty to ensure this average time between blocks remains the same. Likewise, as hash rate decreases, the difficulty decreases.
With difficulties as high as the above example, solo-mining (mining by yourself, not in a pool) becomes a very difficult task. Assume our miner can produce 100 MH/s. Plugging in this into the numbers above, we can see it’s going to take him (on average) 1,798,673 seconds of hashing to find a hash lower than the target – that’s just short of 21 days. But, if his luck is down, it could easily take twice that long. Or, if he’s lucky, half that time.
So, assuming he hit’s the average, for his 21 days mining he has earned 25 VTC.
Lets take another look at the same miner, but this time he’s going to join a pool, where he is working with a stack of other miners looking for that elusive hash. Assume the pool he has joined does 50 GH/s – in that case he has 0.1 / 50 or 0.2% of the pool’s hash rate. So for any blocks the pool finds he should earn 0.2% of 25 VTC = 0.05 VTC. At 50 GH/s, the pool should expect to spend 3,597 seconds between finding blocks (2 ^ 32 * difficulty / hashrate). So about every hour, our miner can expect to earn 0.05 VTC. This works out to be about 1.2 VTC per day, and when we extrapolate over the estimated 21 days of solo mining above, we’re back to 25 VTC.
The beauty of pooled-mining over solo-mining is that the time between blocks, whilst they can vary, should be closer to the predicted / estimated times over a shorter time period. The same applies when comparing pools – pools with a smaller hash rate will experience a greater variance in time between blocks than a pool with a greater hash rate. But in the end, looking back over a longer period of time, earnings will be the same.
Hashes
A Hash is a cryptographic function that can take an arbitrary sized block of data and maps it to a fixed sized output. It is a one-way function – only knowing the input data can one calculate the output; the reverse action is impossible. Also, small changes to the input data usually result in significant changes to the output value.
For example, take the following string:
“the quick brown fox jumps over the lazy dog” 
If we perform a SHA256 hash of this, it results in:
05c6e08f1d9fdafa03147fcb8f82f124c76d2f70e3d989dc8aadb5e7d7450bec 
If we change a single character in the input string (in this case we will replace the ‘o’ in ‘over’ to a zero), the resulting hash becomes:
de492f861d6bb8438f65b2beb2e98ae96a8519f19c24042b171d02ff4dfecc82 
Blocks
A block is made up of a header, and at least one transaction. The first transaction in the block is called the Coinbase transaction – it is the transactions that creates new coins, and it specifies the addresses that those coins go to. The Coinbase transaction is always the first transaction in a block, and there can only be one. All other transactions included in a block are transactions that send coins from one wallet address to another.
The block header is an 80-byte block of data that is made up of the following information in this order:
  • Version – a 32-bit/4-byte integer
  • Previous Block’s SHA256d Hash – 32 bytes
  • Merkle Hash of the Transactions – 32 bytes
  • Timestamp - a 32-bit/4-byte integer the represents the time of the block in seconds past 1st January 1970 00:00 UTC
  • nBits - a 32-bit/4-byte integer that represents the maximum value of the hash of the block
  • Nonce - a 32-bit/4-byte integer
The Version of a block remains relatively static through a coin’s lifetime – most blocks will have the same version. Typically only used to introduce new features or enforce new rules – for instance Segwit adoption is enforced by encoding information into the Version field.
The Previous Blocks’ Hash is simple a doubled SHA256 hash of the last valid blocks header.
The Merkle Hash is a hash generated by chaining all of the transactions together in a hash tree – thus ensuring that once a transaction is included in a block, it cannot be changed. It becomes a permanent record in the blockchain.
Timestamp loosely represents the time the block was generated – it does not have to be exact, anywhere within an hour each way of the real time will be accepted.
nBits – this is the maximum hash that this block must have in order to be considered valid. Bitcoin encodes the maximum hash into a 4-byte value as this is more efficient and provides sufficient accuracy.
Nonce – a simple 4-byte integer value that is incremented by a miner in order to find a resulting hash that is lower than that specified by nBits.
submitted by nzsquirrell to VertcoinMining [link] [comments]

The Concept of Bitcoin

The Concept of Bitcoin
https://preview.redd.it/5r9soz2ltq421.jpg?width=268&format=pjpg&auto=webp&s=6a89685f735b53ec1573eefe08c8646970de8124
What is Bitcoin?
Bitcoin is an experimental system of transfer and verification of property based on a network of peer to peer without any central authority.
The initial application and the main innovation of the Bitcoin network is a system of digital currency decentralized unit of account is bitcoin.
Bitcoin works with software and a protocol that allows participants to issue bitcoins and manage transactions in a collective and automatic way. As a free Protocol (open source), it also allows interoperability of software and services that use it. As a currency bitcoin is both a medium of payment and a store of value.
Bitcoin is designed to self-regulate. The limited inflation of the Bitcoin system is distributed homogeneously by computing the network power, and will be limited to 21 million divisible units up to the eighth decimal place. The functioning of the Exchange is secured by a general organization that everyone can examine, because everything is public: the basic protocols, cryptographic algorithms, programs making them operational, the data of accounts and discussions of the developers.
The possession of bitcoins is materialized by a sequence of numbers and letters that make up a virtual key allowing the expenditure of bitcoins associated with him on the registry. A person may hold several key compiled in a 'Bitcoin Wallet ', 'Keychain' web, software or hardware which allows access to the network in order to make transactions. Key to check the balance in bitcoins and public keys to receive payments. It contains also (often encrypted way) the private key associated with the public key. These private keys must remain secret, because their owner can spend bitcoins associated with them on the register. All support (keyrings) agrees to maintain the sequence of symbols constituting your keychain: paper, USB, memory stick, etc. With appropriate software, you can manage your assets on your computer or your phone.
Bitcoin on an account, to either a holder of bitcoins in has given you, for example in Exchange for property, either go through an Exchange platform that converts conventional currencies in bitcoins, is earned by participating in the operations of collective control of the currency.
The sources of Bitcoin codes have been released under an open source license MIT which allows to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the software, subject to insert a copyright notice into all copies.
Bitcoin creator, Satoshi Nakamoto
What is the Mining of bitcoin?
Technical details :
During mining, your computer performs cryptographic hashes (two successive SHA256) on what is called a header block. For each new hash, mining software uses a different random number that called Nuncio. According to the content of the block and the nonce value typically used to express the current target. This number is called the difficulty of mining. The difficulty of mining is calculated by comparing how much it is difficult to generate a block compared to the first created block. This means that a difficulty of 70000 is 70000 times more effort that it took to Satoshi Nakamoto to generate the first block. Where mining was much slower and poorly optimized.
The difficulty changes each 2016 blocks. The network tries to assign the difficulty in such a way that global computing power takes exactly 14 days to generate 2016 blocks. That's why the difficulty increases along with the power of the network.
Material :
In the beginning, mining with a processor (CPU) was the only way to undermine bitcoins. (GPU) graphics cards have possibly replaced the CPU due to their nature, which allowed an increase between 50 x to 100 x in computing power by using less electricity by megahash compared to a CPU.
Although any modern GPU can be used to make the mining, the brand AMD GPU architecture has proved to be far superior to nVidia to undermine bitcoins and the ATI Radeon HD 5870 card was the most economical for a time.
For a more complete list of graphics cards and their performance, see Wiki Bitcoin: comparison of mining equipment
In the same way that transition CPU to GPU, the world of mining has evolved into the use of the Field Programmable Gate Arrays (FPGA) as a mining platform. Although FPGAs did not offer an increase of 50 x to 100 x speed of calculation as the transition from CPU to GPU, they offered a better energy efficiency.
A typical HD/s 600 graphics card consumes about 400w of power, while a typical FPGA device can offer a rate of hash of 826 MH/s to 80w of power consumption, a gain of 5 x more calculations for the same energy power. Since energy efficiency is a key factor in the profitability of mining, it was an important step for the GPU to FPGA migration for many people.
The world of the mining of bitcoin is now migrating to the Application Specific Integrated Circuit (ASIC). An ASIC is a chip designed specifically to accomplish a single task. Unlike FPGAs, an ASIC is unable to be reprogrammed for other tasks. An ASIC designed to undermine bitcoins cannot and will not do anything else than to undermine bitcoins.
The stiffness of an ASIC allows us to offer an increase of 100 x computing power while reducing power consumption compared to all other technologies. For example, a classic device to offer 60 GH/s (1 hashes equals 1000 Megahash. 1GH/s = 1000 Mh/s) while consuming 60w of electricity. Compared to the GPU, it is an increase in computing power of 100 x and a reduction of power consumption by a factor of 7.
Unlike the generations of technologies that have preceded the ASIC, ASIC is the "end of the line" when we talk about important technology change. The CPUs have been replaced by the GPUs, themselves replaced by FPGAs that were replaced by ASICs.
There is nothing that can replace the ASICs now or in the immediate future. There will be technological refinements in ASIC products, and improvements in energy efficiency, but nothing that may match increased from 50 x to 100 x the computing power or a 7 x reduction in power consumption compared with the previous technology.
Which means that the energy efficiency of an ASIC device is the only important factor of all product ASIC, since the estimated lifetime of an ASIC device is superior to the entire history of the mining of bitcoin. It is conceivable that a purchased ASIC device today is still in operation in two years if the unit still offers a profitable enough economic to keep power consumption. The profitability of mining is also determined by the value of bitcoin but in all cases, more a device has a good energy efficiency, it is profitable.
Software :
There are two ways to make mining: by yourself or as part of a team (a pool). If you are mining for yourself, you must install the Bitcoin software and configure it to JSON-RPC (see: run Bitcoin). The other option is to join a pool. There are multiple available pools. With a pool, the profit generated by any block generated by a member of the team is split between all members of the team. The advantage of joining a team is to increase the frequency and stability of earnings (this is called reduce the variance) but gains will be lower. In the end, you will earn the same amount with the two approaches. Undermine solo allows you to receive earnings huge but very infrequent, while miner with a pool can offer you small stable and steady gains.
Once you have your software configured or that you have joined a pool, the next step is to configure the mining software. The software the most populare for ASIC/FPGA/GPU currently is CGminer or a derivative designed specifically for FPGAS and ASICs, BFGMiner.
If you want a quick overview of mining without install any software, try Bitcoin Plus, a Bitcoin minor running in your browser with your CPU. It is not profitable to make serious mining, but it is a good demonstration of the principle of the mining team.
submitted by Josephbitcoin to u/Josephbitcoin [link] [comments]

Vertcoin's Recent Decisions. The damage hasn't been done yet, please join me in stopping the madness!

Foreword
Alright, I’ve been sitting on the sidelines about most of the dealings with Vertcoin because I felt like a lot of the sensible voices were loud enough on their own. Many people have stepped up to the plate and developed amazing products that benefit Vertcoin at no addition expense to the original development team. I’ve seen and helped test/brainstorm some incredible projects. Vert.geek.nz was a great example: a project that promoted p2pool mining while still allowing miners to reap the benefit of merged mining. Before nzsquirrell brought us this product we were all forced to either solo mine or to switch to a mining pool that support merged coins (namely SimpleVert at the time). V2p was another amazing product. There's the One Click Miner that's being developed right now... There are a lot more, but my point is that people were able to see a need for a new service, and build that service without any voting or public funding or whatever. And they did an amazing job because they thought things through. With input from multiple sources, and a slow, steady brainstorming session, they were able to develop something that really couldn’t have been made better.
Democracy in Action
Alternatively, Vertcoin itself is being left to an absolutely ridiculous voting process right now that WILL destroy the coin, and here’s why: The democratic process doesn’t work. If you build a system by which the majority can make these kinds of decisions, you create an environment based purely on mob mentality. If I can convince a large enough group of people that a certain idea is better than another, I win. This is extremely bad if you’re trying to gather interest from investors as well because it creates too much variance in coin value and feature sets (the idea of changing the also they would probably like, since that’s something Vertcoin has been about since the beginning, changing the inner workings of the coin simply to combat a single “problem” is VERY BAD if you want to attract investors because they see these moves as signs of weakness).
Development
Now, I’ll come back to the VertVote process later, because I think the most important thing to talk about right now is the decision-making process on the part of our developers.
The VTC dev team has done numerous things that don’t make sense to a number of users lately, and they need to be addressed. First, the website update. We’ve beat this horse to a pulp, and I understand that, but I think people still need to keep this in mind. When the new site was released, there wasn’t any input from the community. There wasn’t any play-testing or public brainstorming done to help promote discussion that might have found issues with this site. For example, the “Mining” page still doesn’t have a single mining pool listed, which leaves a user to go out and find a solid pool on their own. This isn’t easy, especially for someone who doesn’t even know how cryptocurrencies work (the primary audience for a site like this should be users with no crypto experience). The same goes for the “Details” page. There’s plenty of technical information, but that doesn’t mean anything to a regular person. They don’t know what an algorithm is, or what block times/rewards are… It even mentioned merged-mining, without any information on what that is. It’s just confusing for a newbie.
Management
Second, and similarly, the marketing fund got thrown into a pit of uselessness. Vertcoin.org was advertised to miners on a site where people go to see the profitability and mining calculations for a number of coins. Let’s just say that the ad actually catches a miners eye and they click on it. It would lead them to a site that has no information on which mining pools they can/should connect to, aside from p2pool. So the most common frequenter of that site can’t access the most important information he would want from the Vertcoin website. I want to know how that seemed like a good idea.
Alternatively, a group of dedicated Vertans (including one miner that has somewhere in the ballpark of 40 rigs, so he’s pretty damn dedicated), built an entire site from scratch that addressed a number of things for regular folks who we should be attracting to Vertcoin, and presented it to the community and the development team. I realize that there’s a sort of pride in work mentality that might have made the devs prefer their own site, but in this case the new presentation was, in my opinion, better. Furthermore, the devs could have taken this new site and moved it over straight away with almost no other changes, besides a couple small fixes and integration to include mobile browsers. Instead, all they got was a 'thanks for the suggestions, I’ll use some of your stuff if it seems fitting’. If you want to check out the alternative site that a few dedicated Vertans built, check it out here.
VertVote
Now, I promised to come back to VertVote. VertVote says on their front page: "You may vote once on any active poll. Make your voice heard Vertan!”, yet there’s literally nothing stopping a member from voting multiple times. So now we’re making decisions about the life of the coin based on how many possible mis-informed people vote for something, with the honest folks losing out more than anyone else (since the honest ones are the ones less likely to cheat)… Probably the most important factor for VertVote would be the fact that it's in the hands of such a knee-jerk crew right now. I didn't even realize that the vote for block maturation was actually a decision-making vote. I assumed it was simply a poll that the dev team wanted to conduct to get a gauge of how strongly the miners feel on the subject. Instead, they took one of the most poorly worded/conducted votes and turned it into the final decision on the continuation of the coin. That was the wrong decision.
Not only that, but it appears that the dev team has decided to interpret the voting results however they see fit, without letting anyone know the conditions of the vote in advance. The example of this being that fact that they completely disregarded the winning vote and instead gave the vote to the second-highest result. To me, this would be like throwing the clear presidential winner out because he only had 49% of the vote (so 51% didn’t want him) and instead picking the candidate who had 30% of the vote simply because he was among the majority… It makes no sense, and if you were going to start a vote with such a senseless base to it, you should have stated as much and given voters more time to decide before they cast their vote(s).
As for the VertVote manipulation, for those who don’t believe me. It’s incredibly easy, and ridiculous. To test things out, I used 100 VTC, spread it out across 10 VTC addresses and cast a vote from each. Nothing in the site, not even a browser cookie, stopped me from casting multiple votes. But then I thought a bit more. Why limit myself by how much VTC I have? All I need is 10 VTC in an address at the moment I cast my vote. So really, I just need 10 VTC plus [number of votes I want to cast] times [transaction fee to send 10 VTC]. I could just keep creating wallets, sending the 10 VTC to the new wallet, and vote again… On the other hand, one of the measures to fight against this behavior is a block on IP addresses submitting multiple votes. This doesn't seem all that logical, considering multiple people could reside at one location / share an internet connection and not be able to voice their opinion as well as a single person / internet user.
Economically, These are Bad Decisions
As for the block subsidy change proposal: This is getting out of hand. Cryptocurrencies’ values need to stay in line with regular products and fiat currency. A very successful cryptocurrency should have about a 1:1 ratio with things normal people are used to. What this means is that we want Vertcoin to settle in value somewhere between $0.50 and $3 each, so that normal people can easily convert the value and go from there. Artificially halting/slowing the production of Vertcoin may result in a slight pump in value, but ultimately it will detract investors because it causes more variance (who knows what the devs/community will want to do next) and it makes Vertcoin less easy to calculate compared to what they’re used to (i.e. the dollar, euro, etc).
Think of it, literally, as a coin. If Vertcoin were an actual coin and each coin were worth over $100, people won’t exactly want to carry it around. For this reason, Bitcoin community members have been discussing creating a denomination of sorts, so they could refer to smaller increments of BTC as something like bits and have each bit worth $0.10-1.00. Your proposal would do the exact opposite and make Vertcoin even more difficult for the layman to comprehend.
Minor side-point
One last thing, and this is mostly unrelated (I noticed it during my experimentation): Vertcoin-Qt has an option to view a transaction on VertExplorer, even though VertExplorer isn’t even around anymore. Alternatively, there’s explorer.vertcoin.org, which works fine. Can the devs please change the wallet so that it can reference transactions without having to copy, browse to explorer.vertcoin.org and then paste/search for that transaction?
For Those Who Think We Need VertVote:
I ask you this, what did you come here for? Did you like Vertcoin, or did you like the idea of a coin that could be constantly changed on the whim of a couple hundred votes? We all bought into Vertcoin because we liked what it stood for (ASIC-resistance), and the economics of it were sound. Even now, the economics of it are only frowned upon because we see so many PoS coins taking over the market. Nobody's out there suggesting we switch to a PoS model, even though PoS is patently anti-ASIC, ASIC-proof for that matter. The whole point of cryptocurrencies is that they are void of any centralized control. If we leave this coin up to the decisions of those who hold it, we're still centralizing the currency's control to those people in particular. Instead, we should be basing the currency on a constitutional model (by that I mean that there should be absolutes that won't be changed, such as the block reward schedule, total VTC supply, time to block solve, etc). The technical details should only change out of absolute necessity to maintain the requirements laid out in the coin's "constitution". In this case, changing the algorithm makes sense, because it maintains the constitutional requirement of being ASIC-resistant. Changing the block reward is just an idea that people like because they see it as a way to increase the value and ROI of their current holdings, without regard to the fact that it'll scare off practically any conscious investor.
submitted by phishfi to vertcoin [link] [comments]

Block size adjustment idea - expedience fees + difficulty scaling proportional to block size (+ fee pool) | Natanael | Mar 30 2017

Natanael on Mar 30 2017:
I had these following ideas as I was thinking about how to allow larger
blocks without incentivizing the creation of excessively large blocks. I
don't know how much of this is novel, I'd appreciate if anybody could link
to any relevant prior art. I'm making no claims on this, anything novel in
here is directly released into public domain.
In short, I'm trying to rely on simple but direct incentives to improve the
behavior of Bitcoin.
Feedback requested. Some simulations requested, see below if you're willing
to help. Any questions are welcome.
Expedience fees. Softfork compatible.
You want to really make sure your transaction gets processed quickly?
Transactions could have a second fee type, a specially labeled
anyone-can-spend output with an op_return value defining a "best-before"
block number and some function describing the decline of the fee value for
every future block, such that before block N the miners can claim the full
expedience fee + the standard fee (if any), between block N+1 and N+X the
miner can claim a reduced expedience fee + standard fee, afterwards only
the standard fee.
When a transaction is processed late such that not the full expedience fee
can be claimed, the remainder of the expedience fee output is returned to
the specified address among the inputs/outputs (could be something like
in#3 for the address used by the 3rd UTXO input). This would have to be
done for all remaining expedience fees within the last transaction in the
block, inserted there by the miner.
These additional UTXO:s does increase overhead somewhat, but hopefully not
by too much. If we're going to modify the transaction syntax eventually,
then we could take the chance to design for this to reduce overhead.
My current best idea for how to handle returned expedience fees in
multiuser transactions (coinjoin, etc) is to donate it to an agreed upon
address. For recurring donation addresses (the fee pool included!), this
reduces the number of return UTXO:s in the fee processing transaction.
The default client policy may be to split the entire fee across an
expedience fee and a fee pool donation, where the donation part becomes
larger the later the transaction gets processed. This is expected to slow
down the average inclusion speed of already delayed transactions, but they
remain profitable to include.
The dynamics here is simple, a miner is incentivized to process a
transaction with an expedience fee before a standard fee of the same
value-per-bit in order to not reduce the total value of the available fees
of all standing transactions they can process. The longer they wait, the
less total fees available.
Sidenote: a steady stream of expedience fees reduces the profitability of
block withholding attacks (!), at some threshold it should make it entirely
unprofitable vs standard mining. This is due to the increased risk of
losing valuable expedience fees added after you finished your first block
(as the available value will be reduced in your block #2, vs what other
miners can claim while still mining on that previous block).
(Can somebody verify this with simulations?)
Fee pool. Softfork compatible.
We want to smooth out fee payments too for the future when the subsidy
drops, to prevent deliberate forking to steal fees. We can introduce a
designated P2SH anyone-can-spend fee pool address. The miner can never
claim the full fees from his block or claim the full amount in the pool,
only some percentage of both. The remainder goes back into the pool (this
might be done at the end of the same expedience fee processing transaction
described above). Anybody can deliberately pay to the pool.
The fee pool is intended to act as a "buffer" such that it remains
profitable to not try to steal fees but to just mine normally, even during
relatively extreme fee value variance (consider the end of a big
international shopping weekend).
The fee value claimed by the miners between blocks is allowed to vary, but
we want to avoid order-of-magnitude size variation (10x). We do however
want the effect of expedience fees to have an impact. Perhaps some
logarithmic function can smooth it out? Forcing larger fees to be
distributed over longer time periods?
Block size dependent difficulty scaling. Hardfork required.
Larger blocks means greater difficulty - but it doesn't scale linearly,
rather a little less than linearly. That means miners can take a penalty in
difficulty to claim a greater number of high fee transactions in the same
amount of time (effectively increasing "block size bitrate"), increasing
their profits. When such profitable fees aren't available, they have to
reduce block size.
In other words, the users literally pay miners to increase block size (or
don't pay, which reduces it).
(Sidenote: I am in favor of combining this with the idea of a 32 MB max
blocksize (or larger), with softforked scheduled lower size caps (perhaps
starting at 4 MB max) that grows according to a schedule. This reduces the
risk of rapidly increasing load before we have functional second layer
scaling in place.)
In order for a miner to profit from adding additional transactions, their
fees must exceed the calculated cost of the resulting difficulty penalty to
make it worth it to create a larger block. Such loads are expected during
international shopping weekends.
With only a few available high value transactions the incentive becomes the
reverse, to create a smaller block with lower difficulty to faster claim
those fees.
To keep the average 10 minute block rate and to let this mechanism shift
the "block size bitrate" as according to the fee justified block size
changes, we set an Expected blocksize value that changes over time, and we
change the difficulty target into the Standard difficulty target, where
each block must reach a Scaled difficulty target .
In terms of math we do something like this:
Scaled difficulty = Standard difficulty * f(blocksize), where f would
likely be some logarithmic function, and blocksize is defined in terms of
units of Expected blocksize (a block 1.5x larger than Expected blocksize
gets a value of 1.5).
When we retarget the Standard difficulty and Expected blocksize we do this:
Standard difficulty = Network hashrate per 10 minutes (approximately same
as before, but now we take the Scaled difficulty of the last period's
previous blocks into consideration)
Standard blocksize = Recent average effective block bitrate = (sum of
recent (weighted!) block sizes / length of timeperiod) / number of blocks
in a retargeting period.
Thus, generating larger blocks drives up the long term standard block
bitrate, smaller blocks reduces it, in both cases we strive to average 1
block per 10 minutes.
Combining this with expedience fees makes it even more effective;
There's always a cutoff for where a miner stops including unprocessed
transactions and let the rest remain for the next block. For standard fees,
this would result in a fairly static block size and transactions backlog.
With expedience fees your transaction can bypass standard fees with same
value-per-bit, as explained above, because otherwise the miners reduces the
value of their future expected fees. The more people that do this, the
greater incentive to not delay transactions and instead increase the
blocksize. (Can somebody help with the math here? I want simulations of
this.)
(Sidenote: I'm in favor of RBF, replace-by-fee. This makes the above work
much more smoothly. Anybody relying on the security of unconfirmed
transactions for any significant value have to rely on some kind of
incentive protected multisignature transaction, including LN type second
layer schemes. The other option is just not secure.)
If load is low then you can add a high expedience fee to incentivize the
creation of a smaller block with your transaction, since difficulty will be
reduced for the smaller block. This means the miner has a higher chance of
beating the competition. Adding additional lower fee transactions may
reduce his average value-per-bit to become less profitable.
Miners simply aim to maximize their fees-per-bit, while also paying as
little as possible in mining costs.
To make this work as intended for those willing to explicitly pay to reduce
block size, one could tag such an expedience fee with a maximum allowed
blocksize (where the fee will be claimed in such a smaller block if it is
the more profitable option), such that it won't be countered by others
making more high expedience fees to increase blocksize. Note: I'm not
particularly in favor of this idea, just mentioning the possibility.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170330/823b7763/attachment.html
original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013885.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

ZiftrCOIN Launch Update

Announcing the ziftrCOIN Release

ZiftrCOIN will be launching this Saturday(February 28th) see more info here. We’ve put a lot of hard work into it and a large portion of our efforts have been leading to this very moment. We couldn’t have gotten here without all the support we received during the ziftrCOIN Presale and we just want to again express our gratitude to all presale participants, as well as everyone who has expressed interest in ziftrCOIN.
 

Specifications:

 
We are pre-mining 4.5% of the total ziftrCOINs, 66.7% of which we will give away to consumers. In doing this, we hope that more consumers start to become familiar with cryptocurrency.
 

You will be able to begin CPU mining via the ziftrCOIN-Qt wallet immediately upon release to get a bit of a head start. As for GPU mining, we’re waiting to release our GPU code until 1-2 weeks after the coin release date. Why? A couple reasons:

 
Be sure to follow ziftrCOIN on Twitter (@ziftrcoin) for all mining update announcements.
     

What Makes ziftrCOIN different?

 

$1 Minimum Redemption Value

 
ziftrCOIN comes with a built-in use case. When spent in Ziftr’s merchant network, each ziftrCOIN will have a minimum redemption value of $1. Think of ziftrCOINs as your very own Ziftr coupons.
   

Incentivized Proof of Knowledge Mining

 
In our version of Proof of Knowledge, the miner may optionally prove knowledge of transaction data while mining to get a slightly higher reward. More specifically, a block solved with Proof of Knowledge of transaction data is allowed to claim a 5% higher reward than those that are not. The idea here is that we want to incentivize miners to run their own software to decide which transactions will be processed, rather than just working on data given by the pool operator. With this setup, pools can still exist to limit the variance of miners, but are no longer the source for transaction data while mining. In addition, an SPV node may verify the Proof of Knowledge of transaction data with only one more transaction from the block, rather than downloading the full block data.
 

Mature Coins Spent as a Tiebreaker

 
In ziftrCOIN, the core client calculates the number of sufficiently old coins spent in each new block received on the peer-to-peer network. When two blocks are solved on the tip of the chain at nearly the same time, the block with more sufficiently old coins spent in it is chosen as the correct block. Chains are still prioritized by most-work first; the counting of old coins spent is only used when two chains have the same work. This tiebreaking strategy makes it unprofitable for a miner to mine PoK blocks while not including transactions because the blocks would have far fewer old coins spent in the block, and they would lose ties. Since the tiebreaking strategy is mathematically expected to take effect in approximately 18% of blocks, a 5% increase in rewards would not be sufficient to make this attack worthwhile.
 

Dynamic Block Size Limit

 
The ziftrCOIN block size limit is not set to a fixed constant, as is currently done in Bitcoin. Instead, the chain automatically allows for growth as transaction volume increases. This can be faked by miners, but a clear majority of miners must be artificially increasing block size limits in order for the block size limit to increase unnecessarily. The block size growth is limited to 10% every 3 months, which is roughly equivalent to doubling every 2 years.
 

Coin Distribution Model

Most coins follow a halving block reward distribution that incentivizes early adopters to participate before the block reward drops. Instead, we decided to try to match the distribution with common adoption curves for new technologies. For example, the chart contained in this article (below for convenience) shows the standard adoption curve of new technologies. Ten billion total ziftrCOINs will be created over 30 years, with the coins distributed in each block changing each day following a standard bell curve.
 

Support for OP_CHECKLOCKTIMEVERIFY

The Bitcoin scripting language currently has no way to make a transaction output that cannot be spent until a later point in time. The ziftrCOIN network supports the use of both OP_CHECKLOCKTIME and OP_CHECKLOCKTIMEVERIFY to allow the creation of outputs that can only be spent after a certain point in the blockchain. This is useful in many scenarios, such as using escrow with a third party who cannot participate in the arbitration process unless there is actually a problem between the two transacting parties. This scripting opcode was also used to lock up the coins that Ziftr received (not including giveaway coins) in the genesis block. The goal here is to prove to the community that we are not going to take the coins we have set aside and dump them on the market, because we literally could not even if we wanted to. The core client, however, does not currently relay transactions that use these types of outputs, but these rules will likely be relaxed soon.
 

Convenient Transaction Processing Speed

The expected generation rate of ziftrCOIN blocks is 1 block per minute. This block generation time was chosen as a trade-off between convenience and consensus.
   
We hope you’re as excited as we are about the release of ziftrCOIN! If you have any questions or comments, please reach out to us on Twitter or Reddit or email us directly at [email protected].
     
submitted by RyanCD to ziftrCOIN [link] [comments]

An objective score for Bitcoin mining decentralization (and other cryptos)

The Herfindahl index can be applied to objectively measure how decentralized a cryptocurrency's mining infrastructure is - and to directly compare cryptos in that regard. Perhaps more interesting, though more work, would be to graph how these change over time. Has bitcoin become more or less decentralized over the years? It's actually possible to answer, but I'll leave doing so up to others.
The more mining pools there are, and the more their hash rates are evenly distributed, the more decentralized a cryptocurrency's mining economy is. This is the basis of the Herfindahl index, and we can use the reciprocal to obtain a decentralization score.
Here is the procedure, followed by results and calculations for Bitcoin, Bitcoin Cash, and Ethereum.
  1. Pick a number of blocks (N) to give you a sufficiently good estimate.
  2. For all of those blocks, identify what pool/miner mined it.
  3. For each unique pool/miner, count how many blocks they mined (n) out of the total (N), and then calculate (n/N)2 (squared market share).
  4. Sum all of these squares up to give you the Herfindahl index (H).
  5. Optionally, calculate the reciprocal (1/H). This makes the index proportional to decentralization and is IMO easier to understand in "bigger is better" terms.
Since steps 1-3 are the already used by many web stats to calculate miner hash rate proportions, you can work directly from hash rate proportions. Square each miner's proportional hash rate and add these all up to get H, then take the reciprocal.
Higher values of the reciprocal Herfindahl index indicate greater decentralization. You can directly compare these between cryptos, but be aware that the index will fluctuate over time and will exhibit some variance.
In my opinion this value is an important metric of the security of a cryptocurrency's network along with the total hash rate.
Here are the current values for a few different cryptos. Higher is better.
Bitcoin: 7.9
Bitcoin Cash: 6.0
Ethereum: 7.0
So, what is an acceptable value? That is the subjective part. I would personally suggest the current state of bitcoin is not decentralized enough, so a value of 7.9 does not satisfy me. Your own opinion may differ.
How do we tell if the above values are different enough to warrant discussion? One method is through the use of significance tests. Or, it may be sufficient to simply plot such values on a graph an examine variability over time. I leave these as exercises for others...
Raw calculations for Bitcoin:
Miner Block Count share*share BitFury 12 0.00852071 ViaBTC 12 0.00852071 BTC.top 2 0.000236686 Bixin 8 0.003786982 BW Pool 3 0.000532544 BitClub 7 0.002899408 Slush Pool 26 0.04 BTCC 13 0.01 AntPool 28 0.046390533 GBMiners 5 0.00147929 ConnectBTC 1 5.91716E-05 BTC.com 8 0.003786982 Bitcoin.com 2 0.000236686 F2Pool 3 0.000532544 TOTAL 130 Excluded Blocks 14 H 0.126982249 Decentralization 7.875116496 
Note: 14 blocks excluded with "unknown" miners.
Raw calculations for Bitcoin Cash:
Miner Block Count share*share BTC.com 31 0.046344522 AntPool 19 0.017409336 Bitcoin.com 2 0.000192901 BTC.top 25 0.030140818 ViaBTC 29 0.040557485 F2Pool 17 0.013937114 Unknown 20 0.019290123 BitClub 1 4.82253E-05 TOTAL 144 Excluded Blocks 0 H 0.167920525 Decentralization 5.955198162 
Raw calculations for Ethereum:
Miner Block Count share*share f2pool 32 0.049382716 nanopool 23 0.025511188 miningpoolhub 19 0.017409336 ethermine 28 0.037808642 0x5a0b54d5... 11 0.005835262 dwarfpool 5 0.001205633 bitclubpool 6 0.001736111 bw 9 0.00390625 ethpool 2 0.000192901 0x625a083b... 1 4.82253E-05 0xb75d1e62... 2 0.000192901 0x180ba8f7... 1 4.82253E-05 0xeba863d1... 1 4.82253E-05 0x6b4afbc4... 1 4.82253E-05 waterhole 1 4.82253E-05 0xcc4b9f07... 1 4.82253E-05 0xb435ce7c... 1 4.82253E-05 TOTAL 144 Excluded Blocks 0 H 0.143518519 Decentralization 6.967741935 
submitted by CaptainOuzo to Bitcoin [link] [comments]

/r/bitcoin, Help me write my letter to Congress and the IRS

All, any constructive feedback on this letter appreciated. Thanks!
To whom it may concern,
I am writing regarding the latest ruling of the Internal Revenue Service regarding Virtual Currency taxation (IR-2014-36). Due to several critical mistakes in this ruling, I am writing to recommend that the IRS suspend its guidance pending a period of public comment and Congressional oversight. Mistakes in the IRS guidance include giving the American public 20 days notice to calculate and pay $900 million dollars in new taxes, failing to provide any guidance on how to calculate the new tax, creating new tax law ex-post-facto, and ignoring the speculative nature of emerging markets.
In 2013, 1.5 million Bitcoins were mined. In December of 2013, Bitcoins were traded for $1300/coin. At this exchange rate, Bitcoin mining in 2013 constitutes $1.9 Billion in wealth. The IRS has ruled that this wealth is to be taxed as gross self-employment income; for most individuals this will be a 32% marginal rate combined with a self-employment tax rate of %15 for a total tax treatment of %47, or $900 Million in new taxes. While potentially a bold move to solve the deficit, this guidance was released March 25th, twenty days before the $900 million bill is due. The IRS guidance advised that all Virtual Currency taxes were due on April 15th and that all penalties, including criminal, will apply for late payment. This timeline gives Bitcoin entreprenuers, lawyers, accountants, and tax software authors a timeline of 20 days to calculate and move nearly a billion dollars into the Federal Treasury. This guidance is neither feasible, reasonable, or in the best interests of the United States.
To move nearly a billion dollars into the federal treasury in 20 days, tax must be calculated. The IRS has given the following instruction: "taxpayers will be required to determine the fair market value of virtual currency in U.S. dollars as of the date of payment or receipt". This simple guidance ignores the following facts of Bitcoin mining:
As a result, taxpayers must calculate and pay nearly a billion dollars in new income taxes, in twenty days, on threat of criminal penalties, with no guidance as to how much tax is due and up to a 90% variance in the possible amount of tax due. This is not sound tax policy, imposes an unreasonable burden, and deprives even the most honest & compliant citizens of the ability to calculate and pay taxes.
Finally, the new IRS guidance ignores the speculative nature of Virtual Currencies. All Bitcoin miners, this author included, had planned with their accountants to pay capital gains tax on any gained capital as a result of Virtual Currency sales. However, many miners chose never to sell virtual currency due to the lack of a robust or fair market. Of the two biggest Bitcoin exchanges in 2013, the first, Mt. Gox, has been shown to be a Ponzi scheme and has gone bankrupt, keeping all investor funds. The second, BTC-E, is located somewhere in Eastern Europe and its operators are unknown but rumored to be criminals. These are the markets that the IRS is endorsing in its guidance as "fair market". The IRS guidance requires Americans to sell $900 million worth of virtual currency on these markets in order to satisfy a new tax burden.
Many miners see these markets as risky and emerging and have held virtual currency without spending it, cognizant that on any day, the value of Bitcoin may be zero. For most miners, this means that taxes on Bitcoins mined in 2013 will be taxed at their 2013 trade value of $1300/coin, and tax will be paid by selling at today's price of $400/coin. This means that most miners will owe more in taxes than their Bitcoin is worth, and will be paying taxes out of their life savings on income they never earned. This is what I will be doing on April 15th. The IRS has purchased a massive "short sale" option against the American people, assessing tax at a price over twice as high as the price Americans are now forced to sell.
No bitcoin miner would have entered into this agreement knowingly. Like many miners, had I known that 46% tax would be assessed at speculative prices, I would never have entered into such a liability. The option of being forced to sell half of my Bitcoins every day on foreign exchanges operated by criminals and moving thousands of dollars into overseas accounts was not a risk I was willing to take. This risk is what the IRS has required with its guidance. The IRS has classified mined Bitcoin as income retroactively, against all guidance and wisdom, and caused those who entered into this hobby to incur massive tax debt against gains they have never realized. This retroactive ruling bears all the worst elements of ex-post-facto tax law, a practice our Founding Fathers worked so hard to prevent.
When the Internet revolution swept over America in the early 90s, Congress wisely allowed it to flourish and kept control of the Internet within the United States, control we still enjoy today. Like America's Mining Act of 1872, Denmark and other countries have opted to forgo a tax on Bitcoin mining due to its speculative nature, and instead tax only capital gained. Bitcoin is at the center of the virtual currency revolution, and the IRS has given miners, the core of this revolution, a choice of Denmark at 0% or the United States at 46%. We are chasing all the talent, investment, mindshare and control of an emerging revolution out of the country. We have created impossible, uninformed guidance and given America twenty days to pay a billion-dollar tax bill. We have placed a billion dollar "short sell" option against the American taxpayer and forced her to pay out of her life savings. We have engaged in the worst type of ex-post-facto lawmaking.
The IRS must immediately announce suspension of its guidance pending a period of public comment and Congressional oversight. During this period of oversight, the following minimum reforms should be undertaken:
Thank you, and God Bless America.
Sincerely,
-Truly, my name is Mike
submitted by trulymynameismike to Bitcoin [link] [comments]

ZiftrCOIN Mining Update: Proof of Knowledge algorithm

TL;DR: Ziftrcoin is dropping Sign to Mine(S2M) and using the new Proof of Knowledge algorithm due to the potential problems S2M could create being much worse than the ones it was meant to solve.
     

Goodbye Sign to Mine. Hello Proof of Knowledge.

One of the things we love so much about cryptocurrency is the opportunity to engage with a community of brilliant individuals who are just as passionate about this technology as we are. Our priority, first and foremost, is to put out the best tools, applications, and products possible to improve cryptocurrency and facilitate mass adoption.
Fortunately, thanks to Reddit, BitcoinTalk and other online cryptocurrency communities, we’ve received a lot of great feedback – specifically on our Sign to Mine mining algorithm. We’ve taken all of this valuable feedback into careful consideration and have decided to say goodbye to Sign to Mine and hello to a new and improved mining algorithm that we’re calling Proof of Knowledge.
Please read on for all the details behind this decision and for an introduction to Proof of Knowledge. As always, we would love to hear any and all constructive feedback!
   

Problems with Mining

When we first set out to create ziftrCOIN, one of the goals that we had was to make improvements on cryptocurrency wherever we could. Bitcoin has a handful of issues that some people see as possible problems – problems that we wanted to try to fix and prevent.   One of these issues is the risk of centralized control of the network hashing power. As mining gets more difficult, there is a natural tendency to have fewer yet larger mining pools. Unfortunately, the operators in charge of these pools then have control over large portions of the miners. The problems caused by this are outside the scope of this discussion but they include 51% attacks, selfish mining, and coordinated double spending.   These problems only exist if the miners act on them. While it is unlikely that a large group of anonymous strangers would all be willing to combine forces to attack the network, a pool operator may choose to do so single-handedly. This is exactly where centralization becomes a problem: when pool operators have exclusive control over a large portion of the hashing power of the network.
 

Sign to Mine As a Proposed Solution

This was where our S2M solution was meant to help. In a normal mining setup, the miners mine the coins directly to an address controlled by the pool. It’s then up to the pool to distribute the rewards appropriately. With S2M, all miners working together must have the ability to withdraw the mined coins directly. This means that any single miner on the pool could choose how to distribute the rewards, including taking 100% of them. The idea is that S2M could prevent pooling by large groups of anonymous strangers. Pooling would still be possible, but every member of the pool would have to trust the entire group. However, pools serve a very important function for miners, which is to smooth out reward variance. It’s impractical for a miner to leave their equipment running for long periods of time in the hopes that they’ll win a large reward. Small constant payouts are practically required for miners to operate.   We had plans to solve the rewards variance problem by providing a solution called social pooling. With social pools, miners could use reputation systems and social networking to find groups of like-minded miners to work with. In this way, people could pool their power and vary the rewards while also reducing the risk of loss caused by an anonymous user running off with the coins.
   

Possible Problems Caused By Sign to Mine

All of this sounds pretty good, so why get rid of S2M? The short answer is that our testing and theory-crafting showed that the problems created by the system could be much worse than the ones it was meant to solve. In addition, there are also ways pool operators could work around the limitation.
 
First, let’s look at some possible problems caused by S2M. If a miner is not getting regular rewards, it’s a safe assumption that they will simply stop mining. What this means is that only miners with enough hashing power to get regular payouts, sometimes referred to as whales, will mine. This leads to the exact problem we wanted to prevent in the first place: large portions of the mining power controlled by a single entity. In this case, it could be even worse because unlike the pool operators in a typical mining scenario, these miners would have direct control over the equipment itself.
 
Social pooling was our proposed solution for combatting the centralized mining by whales. In theory, groups of friends could gather enough hashing power to become equal to larger miners. However, what we’ve discovered is that the social mining would heavily reward malicious users and bad actors, leading to things like scamming users, creating fake accounts to build rep, and buying and selling of high-ranked accounts in order to steal block rewards. There are already enough problems in cryptocurrency with user security, theft, and scamming. To not only invite these problems but also to create a system that outright rewards bad actors seems to be the wrong answer.
 
The next issue is pool operators simply working around the system. Operating a pool can be a profitable enterprise. S2M would increase demand for a good pool to connect to. With S2M, the risk is that a miner could run away with the block rewards. A pool operator could easily work around this by providing each miner with a unique address to sign and mine with. By doing this, if a user ran off with the coins, the pool would know which user it was. The pool operator could then simply require a deposit equal to a single block reward, meaning that for any miner to mine on the pool they would have to give a block reward worth of coins temporarily to the pool. These coins could be held in a type of escrow account. When the user is done mining, they could check out, and get their deposit returned. If the user is found to have stolen a block reward, then the pool would simply seize the deposit. This could further be expanded on by allowing users to enter credit card info instead, or by requiring users to mine a block reward worth of coins before allowing a withdrawal.
 
Setting up account systems, escrow systems, and/or credit card processing systems isn’t a simple task. What this means is that only larger groups of dedicated people could create and operate pools. This would further push out the “little guy” and lead to centralized pools. Also, since the pools would be in demand, pool operators would also be able to charge large fees. The large fees would reduce the profitability of mining and lead to less users mining and a less secure blockchain.
 
Just like social pools, these large “buy in” pools are also breeding grounds for malicious activity. Hackers stealing deposits, scam pools accusing miners of theft to seize deposits, and credit card and account theft are just a few of the things that are likely to happen in a setup like this. When mining as part of a pool, the miner already has to put a lot of trust in the pool operator. Inviting all these other ways in which the miner could be ripped off is a bad idea for the mining community.
 
Due to all of these issues, it simply doesn’t make sense to keep S2M as part of ziftrCOIN. It’s a lot of work and risk for the miners who won’t even directly see the benefits. Keeping miners mining is an important part of keeping a blockchain strong. It seems much more likely that S2M would backfire and cause the problems it’s meant to prevent than it does that the problems would arise in the first place.
 
With all of this said, we had already put some resources into developing Sign to Mine before we decided not to go that route. The Sign to Mine code is contained within a branch in our GitHub repository, which will be made available when the coin is released. Obviously, this will be freely issued and available for anyone to use. There may be variations of S2M that put better incentives in place, and it would be great to see someone out there find a better way to use it.
 

ziftrCOIN’s New and Improved Mining Algorithm: Proof of Knowledge

Keeping mining decentralized is still an important goal for us, but attempting to force it via S2M doesn’t seem to be the solution. Instead, we are going to use something that we call Incentivized Proof of Knowledge.
In our version of Proof of Knowledge, the miner may optionally prove knowledge of transaction data while mining to get a slightly higher reward. More specifically, a block solved with Proof of Knowledge of transaction data is allowed to claim a 5% higher reward than those that are not. The idea here is that we want to incentivize miners to run their own software to decide which transactions will be processed, rather than just working on data given by the pool operator. With this setup, pools can still exist to limit the variance of miners, but are no longer the source for transaction data while mining.
 
The exact hashing algorithm used is a combination of the 5 finalist algorithms that NIST selected as candidates for SHA3 (BLAKE, Grøstl, JH, Keccak, and Skein). The first in the series, Keccak, is executed, and then the order of the next four is determined based on the result.
 
The opt-in process of using transaction data while mining should reward miners who contribute their resources to the network in the form of running a full node. However, a pool protocol could just transfer transaction data and circumvent the requirement that the miner run a full node. Transmitting all transaction data to miners would require large amounts of bandwidth, however, so we do not expect that this will be an issue. In addition, even if this were done, it still increases decentralization by making miners aware of transaction data (in the standard work protocol, miners are not given autonomy to determine which transactions are mined into a block).
 
The obvious attack on this system is that miners could simply not run a full node and never add any transactions to their blocks. Since their blocks would be empty, there would be nothing to prove knowledge of. This would allow them to avoid the bandwidth overhead while still mining with Proof of Knowledge of transaction data to gain the 5% in rewards. But this is where the tie-breaking strategy kicks in.
 
In ziftrCOIN, the core client calculates the number of sufficiently old coins spent in each new block received on the peer-to-peer network. When two blocks are solved on the tip of the chain at nearly the same time, the block with more sufficiently old coins spent in it is chosen as the correct block. Chains are still prioritized by most-work first; the counting of old coins spent is only used when two chains have the same work. This tie-breaking strategy makes it unprofitable for a miner to mine PoK blocks while not including transactions because the blocks would have far fewer old coins spent in the block, and they would lose ties. Since the tie-breaking strategy is mathematically expected to take effect in approximately 18% of blocks, a 5% increase in rewards would not be sufficient to make this attack worthwhile.
 
Why make mining with Proof of Knowledge optional? The reason is that we don’t want to add unnecessary barriers to entry. Many miners may not find a 5% increase in payouts to be a sufficient reward for the hassle of running a full node. These miners could still participate in the ecosystem through a standard pool, but are at a slight economic disadvantage.
 
As mentioned above, we welcome any and all constructive feedback regarding our new mining algorithm. We believe wholeheartedly in the future of cryptocurrency and we value the community’s insight as we continue to do everything we can to improve it.
submitted by ZCdev_Stephen to ziftrCOIN [link] [comments]

Announcing the ZiftrCOIN Release (x-post from /r/ziftrcoin)

Announcing the ziftrCOIN Release

ZiftrCOIN will be launching this Saturday(February 28th) at noon(12 p.m. EST)! We’ve put a lot of hard work into it and a large portion of our efforts have been leading to this very moment. We couldn’t have gotten here without all the support we received during the ziftrCOIN Presale and we just want to again express our gratitude to all presale participants, as well as everyone who has expressed interest in ziftrCOIN.
 

Specifications:

 
We are pre-mining 4.5% of the total ziftrCOINs, 66.7% of which we will give away to consumers. In doing this, we hope that more consumers start to become familiar with cryptocurrency.
 

You will be able to begin CPU mining via the ziftrCOIN-Qt wallet immediately upon release to get a bit of a head start. As for GPU mining, we’re waiting to release our GPU code until 1-2 weeks after the coin release date. Why? A couple reasons:

 
Be sure to follow ziftrCOIN on Twitter (@ziftrcoin) for all mining update announcements.
     

What Makes ziftrCOIN different?

 

$1 Minimum Redemption Value

 
ziftrCOIN comes with a built-in use case. When spent in Ziftr’s merchant network, each ziftrCOIN will have a minimum redemption value of $1. Think of ziftrCOINs as your very own Ziftr coupons.
   

Incentivized Proof of Knowledge Mining

 
In our version of Proof of Knowledge, the miner may optionally prove knowledge of transaction data while mining to get a slightly higher reward. More specifically, a block solved with Proof of Knowledge of transaction data is allowed to claim a 5% higher reward than those that are not. The idea here is that we want to incentivize miners to run their own software to decide which transactions will be processed, rather than just working on data given by the pool operator. With this setup, pools can still exist to limit the variance of miners, but are no longer the source for transaction data while mining. In addition, an SPV node may verify the Proof of Knowledge of transaction data with only one more transaction from the block, rather than downloading the full block data.
 

Mature Coins Spent as a Tiebreaker

 
In ziftrCOIN, the core client calculates the number of sufficiently old coins spent in each new block received on the peer-to-peer network. When two blocks are solved on the tip of the chain at nearly the same time, the block with more sufficiently old coins spent in it is chosen as the correct block. Chains are still prioritized by most-work first; the counting of old coins spent is only used when two chains have the same work. This tiebreaking strategy makes it unprofitable for a miner to mine PoK blocks while not including transactions because the blocks would have far fewer old coins spent in the block, and they would lose ties. Since the tiebreaking strategy is mathematically expected to take effect in approximately 18% of blocks, a 5% increase in rewards would not be sufficient to make this attack worthwhile.
 

Dynamic Block Size Limit

 
The ziftrCOIN block size limit is not set to a fixed constant, as is currently done in Bitcoin. Instead, the chain automatically allows for growth as transaction volume increases. This can be faked by miners, but a clear majority of miners must be artificially increasing block size limits in order for the block size limit to increase unnecessarily. The block size growth is limited to 10% every 3 months, which is roughly equivalent to doubling every 2 years.
 

Coin Distribution Model

Most coins follow a halving block reward distribution that incentivizes early adopters to participate before the block reward drops. Instead, we decided to try to match the distribution with common adoption curves for new technologies. For example, the chart contained in this article (below for convenience) shows the standard adoption curve of new technologies. Ten billion total ziftrCOINs will be created over 30 years, with the coins distributed in each block changing each day following a standard bell curve.
 

Support for OP_CHECKLOCKTIMEVERIFY

The Bitcoin scripting language currently has no way to make a transaction output that cannot be spent until a later point in time. The ziftrCOIN network supports the use of both OP_CHECKLOCKTIME and OP_CHECKLOCKTIMEVERIFY to allow the creation of outputs that can only be spent after a certain point in the blockchain. This is useful in many scenarios, such as using escrow with a third party who cannot participate in the arbitration process unless there is actually a problem between the two transacting parties. This scripting opcode was also used to lock up the coins that Ziftr received (not including giveaway coins) in the genesis block. The goal here is to prove to the community that we are not going to take the coins we have set aside and dump them on the market, because we literally could not even if we wanted to. The core client, however, does not currently relay transactions that use these types of outputs, but these rules will likely be relaxed soon.
 

Convenient Transaction Processing Speed

The expected generation rate of ziftrCOIN blocks is 1 block per minute. This block generation time was chosen as a trade-off between convenience and consensus.
   
We hope you’re as excited as we are about the release of ziftrCOIN! If you have any questions or comments, please reach out to us on Twitter or Reddit or email us directly at [email protected].
     
submitted by RyanCD to CryptoCurrency [link] [comments]

What Do YOU Need to MINE ONE BITCOIN In 2020?! UPDATED ... Bitcoin and cryptocurrency mining explained - YouTube Bitcoin Mining Calculator What Do Bitcoin Miners Calculate - YouTube Bitcoin Mining Explained - YouTube

Bitcoin Mining PoolsAs more and more miners competed for the limited supply of blocks, individuals found that they were working for months without finding a block and receiving any reward for their mining efforts. This made mining something of a gamble. To address the variance in their income miners started organizing themselves into pools so that they could share rewards more evenly. Bitcoin is programmed to mine a block about every 10 minutes. It maintains this rate of production by adjusting the “mining difficulty” in line with the overall hashrate of the network. In short, it becomes more difficult for miners to find the target. As hashrate increases, so does Bitcoin’s mining difficulty. The main point is that the answer that this formula produces is not entirely ... There are a lot of naive attempts at calculating a “price floor” at which miners would stop selling. Every miner’s entry time, amount of capital, cost basis, and risk tolerance is different, hence the industry-wide cost-basis is actually a very wide spectrum. Nonetheless, there will be selling at every level. To assess the entire network’s selling pressure, we need to understand the ... Bitcoin.com is your premier source for everything Bitcoin related. We can help you buy bitcoins , choose a bitcoin wallet . You can also read the latest news , or engage with the community on our Bitcoin Forum . Please keep in mind that this is a commercial website that lists wallets, exchanges and other bitcoin related companies. Bitcoin mining pools are a way for Bitcoin miners to pool their resources together and share their hashing power while splitting the reward equally according to the amount of shares they contributed to solving a block. A "share" is awarded to members of the Bitcoin mining pool who present a valid proof of work that their Bitcoin miner solved. Bitcoin mining in pools began when the difficulty ...

[index] [19909] [42207] [13689] [19053] [49612] [4780] [35523] [46656] [29225] [8536]

What Do YOU Need to MINE ONE BITCOIN In 2020?! UPDATED ...

Bitcoin and cryptocurrency mining explained with the Byzantine Generals Problem. We use it to explain the essence of cryptocurrency mining. https://www.udemy... We are miners from 2013 looking to create community and help train and learn together as blockchain tech changes so quickly. Leave your thoughts in the comme... On the right panel you will see a link to the "Bitcoin mining profitability calculator". Click on it. You will be presented with a set of variables upon which your profitability will depend. Step ... Blockchain explorers: blockchain.info, blockr.io, blockexplorer.com To do a SHA 256 on a string of text: http://www.xorbin.com/tools/sha256-hash-calculator T... What do you need to mine one Bitcoin BTC coin AFTER the block reward halving in 2020? Let's review Bitcoin mining profitability and what BTC mining rigs you ...

#