I think the minimum transaction fee algorithm deserves to be discussed in greater detail. It also seems to me that HOdling could become worthless if the fee to HOdl ever becomes greater than the interest earned due to the aforementioned algorithm. I understand why you want to tie i., ii., and iii. to the same HIP, but I think their consequences are farther reaching than you may intend. Not to mention, HOdlcoin is only now starting to recover from the 1 year mandatory HOdl snafu and now you want to implement this HIP.

By my rough calculation, a block of 50 HOdlcoin is only worth about 6 or 7 cents. If you HOdl that block, you must pay between 14-17% at today's HOdl/BTC rates. I think that is overly steep at this stage and more than a bit destructive to the current ecosystem. It will effectively drive out any of today's small time miners. At some point, I do think it could be worth looking at a target fee such as you have proposed, but I do not think that day is today.

I believe that depends on your definition of improving. It seems to me that you are attempting to progress HOdlcoin which is not the same as improving it.

To continue with that thought, if I mine with a pool (let's use optiminer's as the example), and my payouts come in 50 HODL each payments, those are worth (at the moment) about 10 cents usd.  Optiminer's pool sends the payment to me, and a 1 cent fee is incurred (which is destroyed).  So that's 1/10th the value of the payment.  I will assume the pool is not likely to be absorbing those costs out of the goodness of their hearts.  So let's say they get passed on to the miners.  Now my payment of 50 HODL has cost me 5 HODL on top of the pool fee (1%, or .5 HODL)  I was already paying which effectively brings the pool fee to 11%.  Who among us wouldn't die laughing if a pool advertised an 11% fee? 

Now I HODL those 50 in the wallet, and another 10% is taken in transaction fees?  So by the time I get paid for mining and get my nuts safely hodled away, I actually get a value of 39.5 HODL out of a block of 50.  21% in fees for every 50 HODL is straight out nuts.  Not to mention the compounded loss when you start talking about interest lost on the coins that are taken up in fees.

So ok, yes, you can mitigate this some by pools upping the minimum payout amount so that the percentage of the total payment that is taken by the 1 cent fee is less, but then the pool is now holding on to my HODL that could be earning interest in my wallet.  Meanwhile, in my wallet, I'm having to mimic the pool's payout scheme when I HODL by waiting until I have a substantial balance to HODL in order to minimize the impact the fee will have as a percentage of my HODL transaction.  And the longer I wait, the more interest I lose out on.  You also put massive pressure on HODL'ers to choose the longer term deposits, because doing short term deposits will cost more in transaction fees (re-hodling every say 30 days to keep your HODL somewhat liquid would cost you the transaction fee 12 times a year instead of 1 with a yr HODL).  And voila, we're back to everyone having to HODL for a year, only now it's not a requirement, it's the only economically sensible thing to do.

If you really want to implement something like this now you need to write it to scale to the current value of a HODL, maybe updating the fee amount once a month (or week, or day, whatever is reasonable).  And right now 1 cent per transaction is highway robbery.

Actually the discussion has just helped trigger a good improvement to the HIP I think.


Yes, I think we need a complete branding overhaul. Maybe even a re-name. I think one of the main reasons we stopped gaining momentum was that Bittrex refused to add the coin, citing the brand. I think we need something more corporatey and boring.


Thanks, appreciate the effort, but they look a little radioactive to me. I think we can keep the squirrel motif, but need something that looks more like what a bank might come up with.

That does sounds like it addresses the issue. You could even tie the maximum minimum fee to 1% of the block reward. It feels weird to contemplate maximum minimums.

great to see activity on the developement front!!
the deflation implementation sounds like the right way to go.
changing the name is somehow strange.
hodl is a now totally accepted algo. myriad, groestl, x11, equihash, those names are not better by any means.
i cannot understand what bittrex has to complain about. they have coins like thc, pot, gub, 1st, myst and so on.
what might be considered is a new logo. there had been some new designs posted here. maybe it should be more on the nut side than on ths squirrel side :-)

what definetely should be more defined is why people should have it. safety like inside a nutshell. keeping you away from trading losses and transaction fees are the key features in my opinion.
fast transaction speed and increased capacity should make it even more comfortable to use.

so call it a roadmap and we are good to go :-)

cheers,

ahinga

Big buy order is now

I hope this is the right place to post this:

So I spend the last couple of days to program my first ever miner, which happens to be a HoDL Coin GPU miner... with not so great results. Here my findings so far:
- I am running a Core i3-3200 CPU without AES-NI. This gives me ~7 hash/s on the non-aes hodlminer per CPU thread(w0lf and optiminer keep crashing for me and I doubt they would improve performance as they mainly improve via AES-NI integration from what I understand)
- I started out implementing the hodlcoin algo on CPU and my implementation gave me ~3-4 hash/s per CPU thread
- I ported everything incl. a custom AES implementation to OpenCL (actually I didn't put the SHA stuff on GPU, but it is way less relevant than AES... for every sha execution there are at least 15 more AES executions)
- So my miner gives me now ~60 hash/s on an an rather old HD7850. It's 10-20x faster than the equivalent (unoptimized) CPU implementation. If I optimize the implementation, get something like a RX580 I'd guestimate a further 10x as the room for improvment, resulting in ~600 hash/s.
- and just to make it clear: the implementation _does_ work. I successfully submitted completed work to hodlcoin pool, which got accepted.

Conclusion so far: The GPU implementation as-is is good for people without AES-NI... on the other hand: you can get AES-NI nowadays for less than 50 USD. It may be possible to optimize the miner further, which would maybe even place it above an i7, but the improvement  would still be less than 50% in a rather good scenario. So a GPU miner may be feasable, but don't expect quantum leaps.

Another finding: The "1 GB space requirement" is complete nonsense. Give me 5kb memory and I give you an ASIC...

make hodl....

ahh wait nvm then.

In regards to my guesstimation: Of course it is not accurate... it's in the word. My way of thinking: A new graphics card simply delivers 2-3x more performance than my graphics card. There are AES implementations which are ~2x more performant than mine. I believe this is my first OpenCL code and therefore probably not as good as it gets... a further 2x may be possible here just by how you deploy the workload onto the graphics card. 2-3x * ~2x * 2x = 10x.

In regards to the lookuptable: You have ~250.000x 4KB (let's call them:) cache entrys. With the lookup table you have to calculate every cache entry once (256k calculations), which involves generating 64 SHA512 hashes per cache entry. If you calculate them on-the-fly, you have to calculate every cache entry (very worst case:) 16 times. Now that seems like a bad number at first, because it would take 16 times as long to calculate these cache entrys, but you have to put it in context! Or more specifically: what would be the overall performance decrease?

One way of doing it is mathematically, in which case you would compare
versus
Now the question is how expensive is that SHA512 compared to the AES CBC?

So instead I do it the other way... I implemented both algorithms (with and without Scratchpad) and these are the results I am measuring on CPU:
versus

So the penalty hit for not using a 1GB lookup table is 70% in this scenario! And this leaves things out like the fact, that the SHA-512 step has much more optimizations/parallelization possible than a AES-CBC, which would decrease the relative performance hit you would take, after optimization.
You end up with this trade off: Use 1GB of memory versus take a 70% (=0.7x) performance penalty (in the very, very worst case).

Just for a sake of completeness: I did these numbers on my non AES-NI CPU, in a single thread, using the native Java Crypto library, which is faster than my own AES implementation. The worse your AES implementation is, the lower the relative performance hit. The better your SHA implementation is, the lower the relative performance hit.

Conclusion:
Advertising the HOdl algorithm as ASIC proof is total bullshit... the performance penalty when calculating cache entrys on-the-fly opposed to storing them in the 1GB lookup table makes every ASIC builder and their grandmother laugh...

What I don't understand/what I would appreciate if some one would answer:
Where does the algorithm origin from? I don't mean stuff like "it is similiar to Cryptonight" or something like that, but who made this algo? Also there seems to be zero documentation about the algo except for the code itself, which is a bad thing.

All things are not lost, I guess... from what I understand one could make an update to the algorithm via an update? I would strongly suggest it, since as of now, the algo doesn't hold up what it promises imho.
Again: I am _not_ a crypto expert or mathematician. I am simply your average Joe software engineer. And when I see a problem like this... everyone taking a closer look will...

EDIT:
@FreeTrade: I just re-read your post: "if you can calculate faster than you can retrieve from memory, that'll be optimal, but I doubt it" - that is totally besides the point! It is not about what is faster! It is about what are the time/space requirements for the algorithm! Even if not using the lookup table is 0.7x slower, it requires 250000x less memory! This is a great trade off and makes ASICs possible, which still operate on an algorithm, which is 0.7x slower, but do so 1000x faster (=700x total - of course this is not an accurate number again, but you hopefully get the point)!