Bitcoin Forum
January 29, 2023, 05:04:11 PM *
News: Latest Bitcoin Core release: 24.0.1 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 [3] 4 »
41  Alternate cryptocurrencies / Altcoin Discussion / Re: [ANN] MemoryCoin | Requires a Restart on: August 10, 2013, 06:48:25 PM
1) Hard fork is by far the best option.  A "restart" should only be the last resort if the hard fork is impossible, or itself fails  (for example, has an error that kills the new chain, or too many people stay on the old software).

The canonical way to hard fork is you put the old protocol code in IF blocks, like this:
Code:
if (nHeight < NNN)
  {old protocol code}
else
  {new protocol code}

so the historic part of the chain accepts. Many of the altcoins have such scattered all over the place.


Also, remember to leave a long enough window that people can get the new software installed (several days at least).  I know it seems urgent that faulty votes/credits may be getting in, but discrepancies of a few blocks/coins are minor relative to tossing the entire 30000+ coin history.  Everyone on-board understood and accepted there might be some experimental snags.


2) In a restart scenario, it would be wise to maintain the original idea of preserving the balances (best effort), unless it's just too hard (eg. too many accounts to track by hand).  Most/all your early adopters put in significant energy and time experimenting and shaking out the bugs with that expectation, and a poof scenario will demoralize their enthusiasm and support.


3) In the life of a coin, you get maybe one restart, and after that you're in "can't get fooled again" territory.  And a zero restart, especially on a new port address, is effectively a new coin, with the added baggage of having already "failed" once, and discouraged early adopters.   Especially for a cpu coin, that leaves you the botnetters - not exactly the most community-minded group.  So IMO, we shouldn't even be voting on it, given that the much better options 1 and 2 above are still open.


===========

Other Notes:

* Reducing block maturation from 120 to 45 seems fine, though probably unnecessary.

* In regards switching ports on a restart, keep in mind they are a limited resource, and there is already growing contention among the altcoins.  The community cannot really sustain each coin variant grabbing 1, let alone more.   Is it necessary in the hard fork case?  Other altcoins are hard-forking all the time, and I have never heard of a port change.

* 6 minute block time  (mentioned above) is a *feature* for security and robustness, not a bug.

42  Alternate cryptocurrencies / Altcoin Discussion / Re: MemoryCoin | Request For Grant Proposals | Explorer, Pools, Clients on: August 07, 2013, 03:35:44 AM
MemoryCoin had an extremely fair launch, despite technical challenges - announced, roughly on time, all clients functional and anyone could join from minute 0 (with a little work). Technical challenges are not unreasonable with such major innovative features, namely: a brand new distributed voting system, plus automatic stakeholder controlled grants, plus cpu/memory-constrained scrypt-jane hashing. 

Yes the voting is hard to use and maybe noone fully understands it yet.  What a surprise the *brand new innovative experimental features* don't have a "1-Button For Dummies" GUI yet.

As for claiming "insta-mine"??   No. There's currently only 15000 coins minted out of 1 million+ scheduled, which is barely 3x the scheduled rate for the first 3 days, and they are widely distributed across many cpu-only miners.  Hardly an insta-mine.  A minimal level of vestment was necessary to get the voting system boot-strapped and tested.

The grant credits FreeTrade is talking about come from *FUTURE MINTED* coins, using the voting system to direct the built-in grant system -- and once there are enough proposals, the coinholders themselves will be voting on the grants.   (FreeTrade, I think you must emphasize this point, else people might assume the grants are like all those clonecoin premine stashes. They don't realize yet there's a totally new technology here.  Also it would be good to get a list of grant proposals in front of the users for voting soonest - and fixed bids are probably better than too many open-ended ones(?)).



(I'm not affiliated with this coin, just giving a fair commentary.)
43  Alternate cryptocurrencies / Altcoin Discussion / Re: [ANN] MemoryCoin | CPU Only | Slow Startup Fixed on: August 06, 2013, 09:33:38 PM
Is the voting balance the whole wallet balance, or just the amount currently credited/received by 1 particular address/account?
It's one particular address. But they should be the same thing.

Possible Bug?: I am seeing a series of new addresses generated in the default “” account, apparently related to the 4 txns produced by sending to MTVE addresses.
Yes, they'll be created by they won't be used. Change will go to your main wallet address.

Could be related to: I have been importprivkey the grant address into the same wallet, generally before sending to it. Maybe it's better/necessary to use a separate non-mining/non-transaction wallet to receive grants?
Yes, it is probably this. Use a separate wallet for each address to keep it simple.


What is the "main wallet address"? I'm not sure Bitcoin has such a concept, is it a MemoryCoin thing?

Right now, seems like every wallet step I'm doing is generating a new address.  Currently from the cmdline, getaddressesbyaccount ""  shows about 9 addresses in the default account (plus I have others in separate accounts made for the MVTE addresses.)   Is the bottom one of the 9 the main one?  But I saw 2 different ones from this list show up on your voting results tally with my voting balance/weight split between the different addresses.  How do I consolidate all the coins to one voting address?  In progress, I am trying: send them all to one address that had a vote registered - and will see what the next round shows.  If that doesn't work, what next?  Send all coins to the bottommost address?  Or I'm thinking: start a new wallet, send all the coins there, and leave the grant addresses in the current=old wallet, and then re-vote from the new wallet?


Is there an rpc call to show those vote summary lists, or a separate program?  Or you are piecing it together from debug.log info?
44  Alternate cryptocurrencies / Altcoin Discussion / Re: [ANN] MemoryCoin | CPU Only | Slow Startup Fixed on: August 06, 2013, 07:53:48 PM
FreeTrade,

How does one list those voting results you are posting? Is it showing all the votes, or just the top few?

Does voting at each round use the current balance at the address, or the balance at time vote was placed?

Is the voting balance the whole wallet balance, or just the amount currently credited/received by 1 particular address/account?

Possible Bug?: I am seeing a series of new addresses generated in the default “” account, apparently related to the 4 txns produced by sending to MTVE addresses. From brief read through your design notes, I thought an objective was to preserve the sending address when generating change, so is this an error (?). The series of new addresses is confusing my voting, as it seems I'm not getting the whole wallet balance for the vote weight, just the amount accumulated at 1 address before it changed to the next. Could be related to: I have been importprivkey the grant address into the same wallet, generally before sending to it. Maybe it's better/necessary to use a separate non-mining/non-transaction wallet to receive grants?

Also I've had a vote “disappear” (not show up on your lists) -- I'm now guessing this is because the sending address had a 0 apparent balance, per the above.

Thanks for your great work on this interesting, innovative coin. If you are not already in touch, fyi the FRC Freicoin developers have also been working towards a distributed voting feature like this, and will surely be very interested in the developments and experimental results with MemoryCoin.
45  Alternate cryptocurrencies / Altcoin Discussion / Re: IFC InfiniteCoin: now 48% mined. Last day at 500k reward, rate then HALF on: July 04, 2013, 05:41:26 PM
update:  now 48% mined, Last day at 500k block reward.
46  Alternate cryptocurrencies / Altcoin Discussion / Re: IFC InfiniteCoin: now 45% mined, 3 days left at 500k block reward, then HALF on: July 02, 2013, 02:36:07 PM
updated stats as of July 2:  now 45% mined, 3 days left at 500k block reward.
47  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] BTG BitGem REQUIRED UPDATE 0.4.1.5 BEFORE 15 JUL | Try new GemWallet. on: July 02, 2013, 02:58:12 AM
BITGEM VIRTUAL GEMS ASPECT ENCODING (draft proposal 2013-June, Yukon Coinelius)

(Following specification and notes are copyright 2013, YukonCoinelius@gmail.com and supplied for free use only in open-source freely-distributable BitGem wallets and software. Any other use requires separate licensing arrangement.)


Good initiative on the GemWallet idea, mineral. It's very nice to see your continuing development, which I think many BitGem fans have been anticipating, along with future pretty GUIs, etc.

I'd like to open the design up to further discussion, and supply some proposals here that you and the BitGem community can think about and adopt. Your current approach of apportioning the wallet balance across the 4 gems and 4C specs is a good start, but mainly serves the user's personal “hoarding”.

I propose a further UseCase is to focus on the Transactions, to enable users to *send, receive, and trade specific virtual gems*, which represent exact encoded amounts. So for example, users can send “10C Flawless Round Diamond”, or “1C Perfect Heart-Shaped Ruby” -- and those always correspond to exact encoded amounts.

Then:

* each of those gems can have unique pretty pictures in the gui.
* users can scroll through their transaction history to see pictures/names of all the gems they have received in their wallet (even after they spent them).
* users can create and send gems by selecting aspects from pulldown menus, and see the pictures of gems with different properties.
* exchanges could even support trading in such “gems” directly with words or pictures, instead of numeric amounts.

With this approach, the wallet balance itself does not have to be separately maintained in terms of gems (which is complicated - how to make change, handle fees, etc), but conceptually becomes more like a pool of “raw gem material” that you can use to fashion any kind of gem you want (or can afford). (In future, we could also have a way for the wallet balance to be expressed in terms of a user's favorite gems they have received.)

An advantage of this system is that it does not require changes in the underlying bitcoin protocol. It's not a full blown “colored coin” approach, but simply an encoding of transaction values to be reflected in the UI.


QUICK SUMMARY

The basic idea is that a certain amount will exactly represent a specific combination of gem aspects.

For example,  1 Carat of

Flawless Round Diamond = 0.573 btg   (just for example, not the real value)
Perfect Round Diamond = 0.473 btg
Perfect Square Diamond = 0.463 btg
Perfect Square Emerald = 0.461 btg

thus, 10 Carat Flawless Round Diamond = 5.73 btg


To send/trade a specific gem, you select the aspects in the GUI and it will compute the amount, or you type an amount and it will tell what gem that is. When you send the transaction amount, it gets delivered exactly to your recipient via the normal bitgem/bitcoin protocol (no changes needed),  and thus shows exactly that gem received in their wallet transaction list. So continuing the example, if you send 0.573 btg, the receiver's wallet will show they got a “1 Carat Flawless Round Diamond” (with picture!)



DESIGN ISSUES

To create this capability, we need:

1) to define an *exact unique encoding of Gem Aspects to amounts*, and
2) it must have a defined “total ordering” on the aspects such that higher values specify “better” gems.

Below I supply a working draft of a Gem Aspect Encoding, but before we get to that, the community should think about some general principles and what we want, because it affects how the encoding works. Some top-level design questions and issues:

* Should we support only the 4 gem kinds - diamond, ruby, sapphire, emerald - or allow for expansion to include a few more? I think more would be good if we can accommodate it. Like a total of 8, 16... or even a 100+ (for example, there are about 150 gem kinds listed here: http://www.gemselect.com/other-info/gemstone-list.php) We have to balance the fun and interest of having lots of different gems, versus the development work, complexity, and usability, but I think around 100+ is manageable if there is user interest.

* Simplicity and ease-of-use: The full “4C” system has a nice “theoretical rigor”, but I tend to think users may get overwhelmed with so many technical details in real-world use. Plus it will make the descriptions long and unwieldy. I propose a simplified code with fewer aspects, just (Carat, Quality, Shape, Kind).

* Should all the gem kinds be about the same value, or should diamonds be worth *much* more than rubies, rubies way more than emeralds, etc. I tend to think all the gem kinds should be about the same value, so everyone can afford to trade in the kinds of gems they like best. There will have to be some order, but we can make it so the other aspects count more. So everyone can trade diamonds or emeralds or HeartShaped Rubies, just maybe not 10 Carat Flawless ones.


* Rank of gem aspects

The draft proposal is: Carat - Quality - Shape - Kind, in that order.
So Carat is the most important part of the value - all 10C gems are worth more than all 9C gems. Carat can be as large as you want, so the system scales up to any amount.
Next is Quality, so for equal carat, all Flawless gems worth more than all Fine ones.
Next Shape - (All Round worth more than all Square. This is somewhat arbitrary, so we probably should have only a few shapes, like 4 or 8 so users can remember the order)
And finally, Kind.

I put Kind last so it affects the value least, so everyone can afford to send/trade their favorite gems. Also we might support even 100+ kinds, and it would be too hard to remember the value ordering, so it's better if it counts only a little to the value.


* Scope and Implementation

To collect/manage/display pictures for all the gem combinations, we have to keep the scope at a manageable level.
At 100+ gem kinds * 8 shapes * 4 quality levels, is 3200 combinations, which I think is just about still manageable. I'm hopeful at least the quality could just be an algorithmic change to the picture, like dimming or speckling it. Also, pictures of all shapes across all gems might not be available - maybe there's an algorithm for that too.
Of course, if we just start with 4 kinds (diamond, ruby, sapphire, emerald) it's much easier. Or maybe we don't need Quality, or Shape...?




BITGEM VIRTUAL GEMS ASPECT ENCODING - DETAIL, with Total Ordering (draft proposal 2013-June, YukonCoinelius@gmail.com)

Following is the detailed draft proposal.

I dropped many of the technical grades from 4C, and designed for usability and fun (no “poor” grade, nobody wants a poor gem).
Also dropped Color, because it's really just a hue, and adds complexity with little benefit (probably nobody wants a purple emerald).
The numbers of levels in each aspect should be a power of 2, like 4, 8, etc, for efficient bit-encoding.


Gem Aspects, from high to low:


CARAT - (all remaining high bits of the value). So we can define any amount.


QUALITY

order: (Flawless > Perfect > Excellent > Fine) or (Flawless > Excellent > Fine > Good)
Combines cut and clarity from the 4C system, and drops the technical terms like “vs2”, and grades like “poor” (nobody wants a poor gem).
4 levels, encodes in 2 bits.


EXPANSION

We should probably allocate a few bits at this level for future expansion, special “one of a kind” gems, etc. For now these bits would be all 0.
probably 4 bits is enough. However, to scale the basic gem values into a good range, we might like an additional 7 spare bits here, for a total of 11. (see summary example below).


SHAPE

order: Round > Oval > Pear > Heart-shaped > Marquise > Trillion > Square > Baguette
This ordering is a progression from Round to Rectangular (Baguette), where each shape has some similarity to the ones around it.

Basically the rounder and the fewer corner points, the better. (That does not necessarily correspond to real world valuation, it's just for easy mnemonic.)

Limit to 8 shapes, encodes in 3 bits. (maybe use only 4 shapes??)

For reference: Pear is like a teardrop, Marquise is like oval pointed on both ends, Trillion is rounded triangle, Baguette is narrow rectangle.
It might be hard to find pictures of each gemstone in all these shapes. Some algorithmic transform on a base picture would be helpful.
References:
http://www.gemstone.org/index.php?option=com_content&view=article&id=145&Itemid=45
http://www.africagems.com/trillion-gemstones.html


KIND

4 kinds encodes in 2 bits. Consider extension to 128 kinds in 7 bits.
order: (Diamond > Ruby > Sapphire > Emerald) (or alphabetical?)
Consider extending to many more gems including SemiPrecious, up to 8, 16, ... even 128+, like list at http://www.gemselect.com/other-info/gemstone-list.php

If we support many gemstones beyond the 4 precious gems, possibly the value order should be alphabetical. Mainly so people can tell on sight which are most valuable. So we would just have Amethyst > Garnet because A > G. (It's probably too hard to correspond with “real value” ordering, and users would have to keep looking it up anyway.)

Maybe should use alphabetical order even for: (Diamond > Emerald > Ruby > Sapphire).

Carat, quality, shape counts more than the kind in the overall value of the gem.


SUMMARY

This encoding system uses Quality + Expansion + Shape + Kind = 2 + 4 + 3 + 7 = 16 bits to encode the basic gem from 128 kinds. And the remaining high bits for the Carat.

These 16 bits can hold a value up to 64k, which means the base value for a 1 Carat gem ranges 0-64k. Given 1 “cent” is 10000 in the BitGem system, that means the basic 1C gem value can range from 0 to 6.4 cents (0.064 btg).

That value might be a little too small. To move the decimal over 2, we could add 7 more spare bits to the expansion, making 23 bits which gives a range of roughly 0 to 8 btg as the basic 1C gem values.So, with 23 bits and Quality as the highest aspect, we would have basic 1C values distributed approximately like this:

Flawless gems: 4 to 8 btg
Perfect: 2 to 4
Excellent: 1 to 2
Fine: 0 to 1



I hope this specification helps move us forward to being able to send, receive, and trade BitGem virtual gems as unique “real” objects.
All user feedback and comments welcome. Also, donations appreciated, BitGem: gWhCCz9P4TDU2Uj2ZNgwpCvWEf7DhXTg9N

mineral, I have only limited time to assist with this effort, but will try to advise/support you and other developers to implement such features in the Bitgem software. I will follow any community feedback here, and we can also discuss more in PM.
48  Alternate cryptocurrencies / Altcoin Discussion / Re: [ANN] Infinitecoin - IFC 524,288 coins per block! V1.1 Released! Please Upgrade on: June 30, 2013, 04:31:01 AM
There's no hurry to get on an exchange. If you trade now, it's in the context of 500k block rewards. If you wait another week at least, you're trading in the context of 256k blocks. And if you wait another month or two, 128k or 64k blocks.

Advocates of this coin should think in the long-term. You have one of the fairest mined and distributed coins which is basically 1000:1 to Litecoin in total money supply (90B IFC to 84M LTC). After the initial mining is done in about 6 months, there will not even be the pressure of miners dumping their minings every day.

So why do you even need to convert your IFC? Keep them. Build an economy in them.

If you attend to the security of the network, keep the transaction processing safe and steady, and build up services, goods, and merchants dealing in the coin, it will create demand and the exchanges and buyers will hurry over. Then valuation will be driven up, even approaching the nominal 1000:1 ratio vs Litecoin. Ok, maybe add another couple 0s in the ratio because it's not the leader, but going far below that is too pessimistic.

Remember, in 6 months to a year, anybody who needs some IFC for anything, will simply not be able to get any by mining, no matter how much hardware they throw at it. They will have to buy them on the market, or earn them with some other service. So don't sell yourselves too cheaply. 1 Million IFC looks a lot more valuable when the block reward is only 4k.

By the way, one of the first things I'd recommend is that IFC get established on a higher transaction fee. The total transaction fees for a block need to be high enough to incentivize continued mining when the reward is only the fees, and obviously 0.01 won't do.  I'm not sure how many transactions can fit in an IFC block, but it's probably a few hundred to a few thousand. So relative to Litecoin I'd estimate a good range for the IFC fee might be 2-100+.  The fee does not necessarily need to be enforced by the protocol, but at least the client should suggest a reasonable range.

(Fisheater, currently the client actually warns you are setting a fee “too high” if you go above roughly 0.1; that needs a source code fix, to encourage the user into the right range).
49  Alternate cryptocurrencies / Altcoin Discussion / Re: IFC InfiniteCoin: now 38% mined, 6 days left at 500k block reward, then HALF on: June 29, 2013, 03:31:42 PM
updated stats as of June 29:  now 38% mined, 6 days left at 500k block reward.
50  Alternate cryptocurrencies / Altcoin Discussion / Re: [WTS] 105,000,000 IFC Infinitecoin on: June 28, 2013, 07:35:02 PM
And IFC has been one of, if not actually *the* fairest release I've seen -- which gives a coin legitimacy.

So because the dev didn't try and pull any fast-one's at release, the coin is automatically legitimate?  Sorry, I need more than "the dev is not a scammer" to peak my interest in altcoin#0693.

Not automatically make it legitimate, but it doesn't hurt.  InfiniteCoin has just been sitting there quietly clicking out the starting big blocks for an *entire month*, at relatively low difficulty.  Just about anybody who wants should be able to pick up at least a few million, even cpu miners.  That seems the very definition of fair to me.

And, while technically this coin is simply a 1000:1 mint ratio Litecoin with a faster block time, the most interesting aspect is the accelerated distribution schedule.  It will be almost *completely mined* in 6 months, which is in fact a unique property among all the altcoins so far.

51  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] BTG BitGem REQUIRED UPDATE 0.4.1.5 BEFORE 15 JUL | Try new GemWallet. on: June 28, 2013, 03:18:16 PM
The 0.4.1.5 fix for stake reward on small amounts looks good, mineral!

Hopefully we have caught all the stake-mining credit issues now, and BitGem is becoming one of the best stake coins.

I will test again when the protocol update becomes active on July15.

By the way, I see you also picked up the change I had mentioned they did for BitBar in wallet.cpp, which it turns out is not needed - it's only cosmetic, but shouldn't hurt. I'll send you a PM about it.   (and note for any Bitbar users: BitBar is still broken for small stake amounts. I'll try to followup with the developers of BTB and other stake-mining coins to get them fixed as time permits)
52  Alternate cryptocurrencies / Altcoin Discussion / Re: [WTS] 105,000,000 IFC Infinitecoin on: June 27, 2013, 11:46:17 PM
A general fyi:

Walt's 100M here is over 0.1% of the *total eventual* money supply (90 Billion) after the full minting run. And IFC has been one of, if not actually *the* fairest release I've seen -- which gives a coin legitimacy. Seems people have forgotten that the block reward is going to be rapidly scaling down, and the primary purpose of a coin is a fair, well-distributed medium of exchange.

There is not much technically wrong with this coin, except maybe the 30-second block time (which is just a parameter tweak to increase in future if necessary). And it has a number of good features like fair release, can be integer only (no decimals needed in the software, might be good for embedded devices/phones), and rapid mining schedule means it will be the first fully mined coin. Plus has at least 1 developer supporting it.

So this is a very interesting coin to watch, mine, or invest.

For the naysayers, good luck mining 100M 6 months from now when the block reward is 4k.  All it will take is someone to offer a useful service/good in this coin, and everyone will be scrambling for the last 0.1%...
53  Alternate cryptocurrencies / Altcoin Discussion / IFC InfiniteCoin: now 48% mined. Last day at 500k reward, rate then HALF on: June 26, 2013, 06:46:27 PM
IFC still easy mining at the starting rate, over 1% total supply *per day* for an entire month, but rate will soon decrease sharply.  

This coin is interesting for the accelerated distribution schedule, as well as the 90 Billion target money supply. It's on track to be the first fully distributed coin, and has been very fair and easy for anyone who wants to mine some, even CPU mining on pools. Block reward will drop to 256K in 1 day, and halves monthly.

(Public service announcement, not affiliated with this coin.)


No pre-mine, no insta-mine.
Approximately 6+ month accelerated mining schedule, then will be transaction fee supported.
43 Billion mined so far of total 90 Billion schedule.
Still very easy to get a block, big payouts solo or pool.

SPECS:  (announce post at https://bitcointalk.org/index.php?topic=225891.0  )
30 sec block time = 2880 / day.
Block reward halves monthly. (every 86400 blocks)
Difficulty adjusts hourly.
90 Billion total mint schedule, equals roughly 1000:1 money supply ratio on Litecoin

RECOMMENDED TRANSACTION FEE: 2-100+ to ensure fast execution and secure network
54  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] BTG BitGem SAPPHIRE EDITION | 4Cs Gemstone implementation | bitgem.info on: June 23, 2013, 06:23:28 PM
Thanks, mullick.

The way stake mining works is, it's continuously scanning thru all your transactions, looking for “stake”, which are transaction credits over 30 days old. For example if you received 3 btg 40 days ago, that is 120 coindays of stake. When it finds some stake, there is a chance (depending on difficulty) that it will mine a block with it. That block is just like a normal proof-of-work mining block, processing transactions on the network and helping to secure it. Except it doesn't get a “generate” block bonus.

Instead, as your bonus for contributing your stake to let this block get mined, you are supposed to get a small interest on the amount of stake/coinAge you contributed (because you held that stake at least 30 days, and now it's locked up and you can't spend it until 520 confirms).

To credit you the interest, it replaces the old transaction (the 3 coins, 40 days old) from your wallet, with a brand new transaction with more money. For example, for 120 coindays at 3%, the interest bonus is about 0.0099. so your new transaction has 3.0099.

Nice!

However, because of the bug, the new transaction is currently exactly the same value as the old one! Instead of 3 to 3.0099, it's doing 3 to 3. Also keep in mind, it's a brand new transaction, so now its stake/coin-age got reset. It will have to wait another 30 days to become eligible for stake mining again. So Zero Interest. And using up 120 coin-days of stake in the process. (plus generating pointless transactions).

The workaround with reservebalance=N parameter tells the stake engine to ignore N amount of coins, so it won't use up their coinAge. As soon as you set reservebalance back to 0 (or whatever small amount you need handy), then all the accrued coinAge you had stored up becomes available. You won't have to wait any more time. (of course, it will take a while for the engine to mine through it - you won't get the interest all at once). (You can also just keep your wallet locked to stop stake mining, but then you can't solo mine, and as soon as you unlock it to send money, it would start again). It's ok not to fiddle with reservebalance, you won't lose very much assuming the fix gets in quickly.

To understand the big picture effect here:

There are total 17000+ btg existing right now. The stake interest they should earn at 3% is over 500 btg per year.
That would almost all be lost, if I had not debugged and fixed this issue. (note: the fix isn't in the code yet, but mineral has it in progress).

Basically, I've saved the BitGem community over 500 btg / year earnings. (thus my address for tips, above)

55  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] BTG BitGem SAPPHIRE EDITION | 4Cs Gemstone implementation | bitgem.info on: June 22, 2013, 09:39:52 PM
ALERT - Stake Mining Broken for small values - DETAILS AND FIX

I have generated a BitGem stake with maximum debug options (see log below), and investigated the situation why stake-mining has been yielding 0 bonus. It's a different issue than what they fixed for Bitbar (although the wallet rounding fix for bitbar might *also* be necessary in BitGem, but first we have to *create* the right stake reward, before worrying about crediting the wallet).  Also note: This issue actually applies to all the stake-mined coins (btg, btb, yac, nvc, ppc, ...) and I am planning to repeat post in a separate topic.

In a nutshell (after *lots* of debug work, all bitgemmer thank-you gifts welcome!):

in main.cpp, GetProofOfStakeReward, the line

Code:
int64 nSubsidy = nCoinAge * 33 / (365 * 33 + 8) * nRewardCoinYear;

is wrong for small values of nCoinAge (which result when the underlying transaction amounts are small).

When nCoinAge < 366, nSubsidy evaluates to 0 because of integer division truncation.

Because BitGem and BitBar deal mostly with small amounts, nCoinAge will almost always be less than 366, and so the formula yields 0 stake credit almost always (unless you have a very large bitgem transaction amount).


To illustrate, note these lines from the long debug log at end of posting:

Quote
coin age bnCoinDay=108
GetProofOfStakeReward() : lower=10000 upper=30000 mid=20000
GetProofOfStakeReward() : lower=20000 upper=30000 mid=25000
GetProofOfStakeReward(): create=0.00 nCoinAge=108 nBits=503964891

You see “create=0.00” as the computed nSubsidy, when it should be near 0.00887

This is a 3-unit coin that was about 36 days old (3 * 36 = 108 coindays).
Since June-20, Stake Mining Interest rate in Bitgem ranges 1-3% - I believe 3% (0.03) at the current difficulty.
So mathematically, the stake nSubsidy should be  
Code:
108 * 33 / (365 * 33 + 8) * 0.03 = 0.00887

But because all the numbers are internally represented as integers, the integer division truncation occurs.

Specifically:
Code:
(108 * 33 / (365 * 33 + 8)) = 0
with the integer divide.
...


FALSE

Code:
108 * 33 / (365 * 33 + 8) * DOUBLE  = DOUBLE


Because casting conversion, the result will be a DOUBLE, and != 0 because nSubsidy=0.015 * CENT

And, one more time, this month stake reward is not 3%, else  0.015 % , so 0.00015  ,

Code:
108 * 33 / (365 * 33 + 8) *  0.00015  = 0.000044354102713017506015099975109931

I suppose you understand that printed number in log is not "the real representation"  of float representation in memory (or CPU registry) ...

Well, this debate is good in any case ... no.



Hi mineral, I hope you will see it clearly in just a moment. It's a rather subtle bug, which no other stakecoin developer has noticed yet either.

As I said above, in the formula

Code:
int64 nSubsidy = nCoinAge * 33 / (365 * 33 + 8) * nRewardCoinYear;

*all* the variables and numbers are integers. There are no doubles. The numbers *represent* decimal values, but are actually integer values, scaled by a scaling factor.

Right on that line, you can see nSubsidy is declared int64, and a little further up in that function is the declaration
int64 nRewardCoinYear;
and also nCoinAge is int64 defined in the parameters of the function like this:
int64 GetProofOfStakeReward(int64 nCoinAge, unsigned int nBits, unsigned int nTime)

So all the values in the nSubsidy formula are integers, thus integer division occurs, which truncates to 0 for small values of nCoinAge.
Therefore small transaction inputs yield 0 stake reward currently.

ASIDE: Just fyi, what it means that decimals are stored as scaled integers:
When the stake reward is “3%” conceptually, which credits 0.03 of a bitgem on 1 bitgem per year, the internal integer variable holding “3%” is nRewardCoinYear = 3 * CENT = 30000 (CENT is defined as 10000 in util.h)  In the old interest schedule, it defined nRewardCoinYear = 0.015 * CENT. What is happening in that formula is, because of the double constant 0.015, CENT gets implicitly upconverted to a double, then the computation is 0.015 * 10000.0 = 150.0, which then gets implicitly downconverted back to an integer 150 to store in nRewardCoinYear, since that is an int64 variable. (you can't store a double in an integer var.)


In regards you saying the interest rate is still 0.015 %, I think you must not have checked the code lately.
On June 20, 2013 it switched to the new schedule, 1-3%, and the detailed debug investigation I posted is with the new schedule.
Again in that GetProofOfStakeReward() function, you can see the line
Code:
if(fTestNet || nTime > PROTOCOL_SWITCH_TIME)
which says if the time is after the protocol switch time, then use the new interest schedule.
And the switch time is defined in main.h as:
Code:
static const unsigned int PROTOCOL_SWITCH_TIME = 1371686400; // 20 Jun 2013 00:00:00

So we are definitely on the new schedule now, which has a variable interest rate 1-3%, computed as between:

Code:
bnLowerBound = 1 * CENT = 10000 (which represents 1%)
bnUpperBound = bnRewardCoinYearLimit = MAX_MINT_PROOF_OF_STAKE = 3 * CENT = 30000 (which represents 3%)

For any interested readers, the function we are talking about is GetProofOfStakeReward(), at line 979 in this file:
https://github.com/bitgem/bitgem/blob/master/src/main.cpp


I hope it's clear now, mineral, yes?   And thanks for your good support on BitGem.

If you still do not feel confident applying this fix, I will push it upstream to the PPC/NVC developers first, and you can pick up the changes after. But it will obviously take longer, and really BitGem (and BitBar) are the coins affected the most (because the transaction amounts are generally small).



SUMMARY FOR USERS

* Transactions less than about 12 btg get 0 stake interest currently.  It doesn't matter what the total wallet balance is - even if it were 1000, if all the transaction inputs are 3, 5, 0.422, etc  each of those gets 0 interest currently, so interest overall is 0.

* The wallet is continuously stake mining in the background.  It uses up your "CoinAge" to generate the interest.

* Because of these 2 factors, I recommend you set reservebalance=10000 in bitgem.conf.  That will save your CoinAge from getting used up.  After this is fixed you can set reservebalance=0 (or some small value), and then you should get more back-credit interest from all your accrued coinAge.

* This same issue affects all the stake coins (PPC, NVC, YAC, BTB, ...)  but it doesn't matter as much for the coins where most transaction amounts are higher than 12.)

* Thank you gifts appreciated Smiley  BitGem: gWhCCz9P4TDU2Uj2ZNgwpCvWEf7DhXTg9N
56  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] BTG BitGem SAPPHIRE EDITION | 4Cs Gemstone implementation | bitgem.info on: June 21, 2013, 11:38:19 PM
ALERT - Stake Mining Broken for small values - DETAILS AND FIX

I have generated a BitGem stake with maximum debug options (see log below), and investigated the situation why stake-mining has been yielding 0 bonus. It's a different issue than what they fixed for Bitbar (although the wallet rounding fix for bitbar might *also* be necessary in BitGem, but first we have to *create* the right stake reward, before worrying about crediting the wallet).  Also note: This issue actually applies to all the stake-mined coins (btg, btb, yac, nvc, ppc, ...) and I am planning to repeat post in a separate topic.

In a nutshell (after *lots* of debug work, all bitgemmer thank-you gifts welcome!):

in main.cpp, GetProofOfStakeReward, the line

Code:
int64 nSubsidy = nCoinAge * 33 / (365 * 33 + 8) * nRewardCoinYear;

is wrong for small values of nCoinAge (which result when the underlying transaction amounts are small).

When nCoinAge < 366, nSubsidy evaluates to 0 because of integer division truncation.

Because BitGem and BitBar deal mostly with small amounts, nCoinAge will almost always be less than 366, and so the formula yields 0 stake credit almost always (unless you have a very large bitgem transaction amount).


To illustrate, note these lines from the long debug log at end of posting:

Quote
coin age bnCoinDay=108
GetProofOfStakeReward() : lower=10000 upper=30000 mid=20000
GetProofOfStakeReward() : lower=20000 upper=30000 mid=25000
GetProofOfStakeReward(): create=0.00 nCoinAge=108 nBits=503964891

You see “create=0.00” as the computed nSubsidy, when it should be near 0.00887

This is a 3-unit coin that was about 36 days old (3 * 36 = 108 coindays).
Since June-20, Stake Mining Interest rate in Bitgem ranges 1-3% - I believe 3% (0.03) at the current difficulty.
So mathematically, the stake nSubsidy should be  
Code:
108 * 33 / (365 * 33 + 8) * 0.03 = 0.00887

But because all the numbers are internally represented as integers, the integer division truncation occurs.

Specifically:
Code:
(108 * 33 / (365 * 33 + 8)) = 0
with the integer divide.

Probably the reason this hasn't been noticed on the stake-coins before, is that with other stakecoins the nCoinAge is much bigger because the coin amounts are larger. PPCoin was originally dealing with amounts in the 1000s. So if you have a transaction holding a 1000-coin for a month, you have 1000 * 30 = 30000 coindays, much bigger than 366.

CODE FIX

Fortunately, I think there is an easy code fix here, which is to reorder the calculation like this:

Code:
int64 nSubsidy = nRewardCoinYear * nCoinAge * 33 / (365 * 33 + 8) ;

Now the integer division will not truncate to 0, and because all the values are int64, it should be safe from overflow too.
(Safe even in ppcoin, which could have values for CoinAge like 1M coins for 1000 days = 1 Billion coin days, still fits fine in int64)
This will also give more accurate results in all the stake-coins for large values, which currently are rounding to the nearest multiple of a coin-year.

Because this issue affects all the stake-mined coins, I'm planning to re-post this as it's own topic. But it would be good if we could get it patched in BitGem first/fastest, since it matters more here.

Finally, I'll mention here again this is a pretty major issue affecting all the stake-coins to varying degrees, and my diagnosis and fix will probably save/make everyone some money, either directly or indirectly. So all thank-you gifts welcome:

BitGem: gWhCCz9P4TDU2Uj2ZNgwpCvWEf7DhXTg9N
or,
BTC: 13xN2MvG9RcvWY92HeMpMFgBbGq9RLW64z
LTC: LKgvPQBp7wWxP57T8YWHY1dVnstBE81FyW
FRC: 19nQm96DNew1Wrm1LG9eNvpkTT2wauryih
(others welcome too, request my addr)


FULL-DETAIL DEBUG LOG OF BITGEM STAKE-MINED BLOCK:

Quote
CheckStakeKernelHash() : using modifier 0xc78b730c95ac918f at height=5303 timestamp=2013-05-25 12:12:22 UTC for block from height=3528 timestamp=2013-05-16 14:27:50 UTC
CheckStakeKernelHash() : pass protocol=0.3 modifier=0xc78b730c95ac918f nTimeBlockFrom=1368714470 nTxPrevOffset=81 nTimeTxPrev=1368714470 nPrevout=0 nTimeTx=1371833019 hashProof=00000a7e92270e1d1912e9b109825a5af621e8897b9ab7c42d3722b3601bee48
CreateCoinStake : kernel found
CreateCoinStake : parsed kernel type=1
CreateCoinStake : added kernel type=1
coin age nValueIn=3000000 nTimeDiff=3118549 bnCentSecond=935564700
coin age bnCoinDay=108
GetProofOfStakeReward() : lower=10000 upper=30000 mid=20000
GetProofOfStakeReward() : lower=20000 upper=30000 mid=25000
GetProofOfStakeReward(): create=0.00 nCoinAge=108 nBits=503964891
CreateCoinStake : fee for coinstake 0.00
CreateNewBlock(): total size 1000
keypool return 5
CPUMiner : proof-of-stake block found a2ad30df67f6b37f2f9301bff115a4095e003f57004fb6061c24e6feecef01ce
BitcoinMiner:
new block found  
  hash: a2ad30df67f6b37f2f9301bff115a4095e003f57004fb6061c24e6feecef01ce  
target: 000009e4db000000000000000000000000000000000000000000000000000000
CBlock(hash=a2ad30df67f6b37f2f9301bff115a4095e003f57004fb6061c24e6feecef01ce, ver=4, hashPrevBlock=389023b31af092d537eaf27360c73fd8318e6cd75e20ddae3ef3be5079decc07, hashMerkleRoot=9f99a622a5fd66fe1eaf26d6e31b37cce3e2b6ccfbd71ee83fcb110b21cb857a, nTime=1371833019, nBits=1e09e4db, nNonce=0, vtx=2, vchBlockSig=30460221009b1fa391f759a94f3ee96ae831b4eb9b2e58309e5181818beb66b03d396f91ae022100807e9dee8a2758e5d0c27f1eaa89ddf35b544732f3ca358e8c320f8882eb40c8)
  Coinbase(hash=009458e775, nTime=1371833019, ver=1, vin.size=1, vout.size=1, nLockTime=0)
    CTxIn(COutPoint(0000000000, 4294967295), coinbase 028b2602c006062f503253482f)
    CTxOut(empty)
  Coinstake(hash=d0fbc90cd0, nTime=1371833019, ver=1, vin.size=1, vout.size=3, nLockTime=0)
    CTxIn(COutPoint(8ac47fa04a, 0), scriptSig=30460221009c26337f666328)
    CTxOut(empty)
    CTxOut(nValue=1.50, scriptPubKey=036dedb30ffdcdb3988c4232af8536824d44fd8d8191bbe485d02bca74d1c09246 OP_CHECKSIG)
CTxOut(nValue=1.50, scriptPubKey=036dedb30ffdcdb3988c4232af8536824d44fd8d8191bbe485d02bca74d1c09246 OP_CHECKSIG)
  vMerkleTree: 009458e775 d0fbc90cd0 9f99a622a5
generated 0.00
CheckStakeKernelHash() : using modifier 0xc78b730c95ac918f at height=5303 timestamp=2013-05-25 12:12:22 UTC for block from height=3528 timestamp=2013-05-16 14:27:50 UTC
CheckStakeKernelHash() : check protocol=0.3 modifier=0xc78b730c95ac918f nTimeBlockFrom=1368714470 nTxPrevOffset=81 nTimeTxPrev=1368714470 nPrevout=0 nTimeTx=1371833019 hashProof=00000a7e92270e1d1912e9b109825a5af621e8897b9ab7c42d3722b3601bee48
trying connection 92.206.87.53:7692 lastseen=79.5hrs
GetStakeEntropyBit: nHeight=9867 hashBlock=a2ad30df67f6b37f2f9301bff115a4095e003f57004fb6061c24e6feecef01ce nEntropyBit=0
ComputeNextStakeModifier: prev modifier=0xd895202b9a9a4cda time=2013-06-21 12:04:50 UTC
coin age nValueIn=3000000 nTimeDiff=3118549 bnCentSecond=935564700
coin age bnCoinDay=108
GetProofOfStakeReward() : lower=10000 upper=30000 mid=20000
GetProofOfStakeReward() : lower=20000 upper=30000 mid=25000
GetProofOfStakeReward(): create=0.00 nCoinAge=108 nBits=503964891
ConnectBlock() : destroy=0.00 nFees=0
connect() failed after select(): No route to host
AddToWallet d0fbc90cd0  new
WalletUpdateSpent found spent coin 3.00nvc 8ac47fa04afe24669bfb17ccc35b0baea55e41203be0b89ab4c8dc8bfbeaba1e
SetBestChain: new best=a2ad30df67f6b37f2f93  height=9867  trust=1178452533  date=06/21/13 16:43:39
ProcessBlock: ACCEPTED

57  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] BTG BitGem SAPPHIRE EDITION | 4Cs Gemstone implementation | bitgem.info on: June 21, 2013, 10:36:46 PM
Stake reward, for this month is 0.015*CENT per year, what is 0.00125*CENT per month. What it is means is if you has got an stake of  1,000 BTGs, your stake reward-month would be 1.25 BTGs.  This low stake setting was choosed because the very lower bulk of BTGs as compared to PPC or NVC, avoiding innecesary inflaction of coin.

I take note about your appreciation, but, attending to the stake rewards computed above, it is right. It seems, rather, small amounts of reward stake in your balance are not appreciated or noted.

Stake modifiers are a security mechanism rather a reward system, so, for security, does not deactivate it under any reason.


As I understand, on 2013-Jun-20 we switched to the new interest schedule, which is 1-3% depending on difficulty, so I believe is 3% now.

The problem I have found applies to all the stake mining coins, just that it only matters much on the coins with small amounts.

What I meant by disable/deactivate stake mining, is that *users* should do that, until we get this fixed.  Certainly not that we should take it out of BitGem - it's a great feature, which has the *dual purpose* of securing the network and giving the users a bonus for their contribution to that.

As an aside, I tend to think 1-3% interest is too low, because since we started with a very small/scarse coin amount, even a higher interest rate would not cause too much inflation.  (and it encourages people to save/hoard the coin, which supports a higher market price). The whole idea of the stake coins is for a stake reward, and YAC/Bitbar are at 5%, and NVC at a higher variable rate.   But we can say it's ok for now.

But right now, users are not getting *any* credits for stake mining, so they are using up their stake power for nothing.  The reservebalance technique I mentioned is a way they can stop it, just for a while, till we get this fixed.

I am pretty sure of the finding.  I generated a stake block under full debug detail.
I will have a detailed posting out shortly, hopefully by end of the day. 

58  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] BTG BitGem SAPPHIRE EDITION | 4Cs Gemstone implementation | bitgem.info on: June 21, 2013, 09:05:46 PM
ALERT - Stake Mining broken for small values

I am pretty sure now there is 1 or more faults in the stake mining for BitGem, and probably affecting other stake-mining coins too. I have close to debugged it, and will make another posting shortly with details on the issue and a fix.

For the moment, I STRONGLY RECOMMEND BitGem and BitBar users to disable stake mining. You can do this by adding a line “reservebalance=10000” (any number larger than your balance) in your bitgem.conf, and restarting the wallet/daemon.

This bug does not affect your existing gems/coins, you won't lose money, but your “stake mining power” (accrued Coin Age) is currently getting invisibly chewed up for nothing.

Note also: from preliminary investigation, I suspect this issue affects all the stake-mining coins, especially those dealing with small values like BitGem and BitBar, but even potentially YAC, NVC, PPC. It goes all the way back to the PPCoin source, unnoticed because it only affects stake credit on small amounts (like under 10 coins). If you have many small-value transactions in any of these coins, you may want to disable stake mining on them too, for now. (using reservebalance, as above). Larger values should be ok. I will try to work with the developers of these coin(s) to get this resolved, but it will take some time to understand the interplay of all the parameters on the different coins.

This is a pretty major issue, saving/making everyone a lot of money over the future. Gifts appreciated:

BitGem: gWhCCz9P4TDU2Uj2ZNgwpCvWEf7DhXTg9N
or,
BTC: 13xN2MvG9RcvWY92HeMpMFgBbGq9RLW64z
LTC: LKgvPQBp7wWxP57T8YWHY1dVnstBE81FyW
FRC: 19nQm96DNew1Wrm1LG9eNvpkTT2wauryih
(others welcome too, request my addr)
59  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] BTG BitGem SAPPHIRE EDITION | 4Cs Gemstone implementation | bitgem.info on: June 20, 2013, 06:59:41 PM
Quote
The stake miner is finding blocks, but my balance does not seem to be going up, I'm not getting any credit.  listtransactions shows that the 3 coin stakes are just being put back as 3 coins, no additional reward.
In the debug.log it says

43 POS blocks found total reward Nothing . Shutdown,...


it is showed 0.00 TWO DECIMALS.
 Stake is 100 times smaller than NVC or BTB, PoS reward is 0.015 CENTS / YEAR, so stake is very low because there is only 17.000 BTGs. Otherwise, inflaction would kill the coin.

Yes, but if what BitBardev said and fixed is accurate, what is actually happening is it's getting chopped, truncated, always rounded down to 0.  Even if the reward is 0.009,  if you get 100 or 1000 of them then you get something.  But if every little piece gets chopped to 0, then it can never add up to more than 0.

I think a fix is needed on this.  We should investigate what they did for bitbar. 

60  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] BTG BitGem SAPPHIRE EDITION | 4Cs Gemstone implementation | bitgem.info on: June 20, 2013, 05:45:17 PM

PoS reward is set up accodiing BTG bulk, so stake reward is too small, but still is subsidzied (just is not printed with all decimals in tx info).


The stake miner is finding blocks, but my balance does not seem to be going up, I'm not getting any credit.  listtransactions shows that the 3 coin stakes are just being put back as 3 coins, no additional reward.
In the debug.log it says
Quote
CPUMiner : proof-of-stake block found ...
generated 0.00

Are you saying it really is giving a small decimal credit, but just not showing that?  So just a printing error?  Or the value is soooo small it's in the 10th decimal or something?

But my understanding from the Bitbardev posting I linked is that it's actually rounding down to exactly 0.

This is bad because (N-stake-blocks-mined * 0) = 0 credit
whereas (N-stakes * tinydecimal) at least equals something.

We should not have to wait til 100k's BitGems are mined in the total supply to start getting a stake reward.  While the moneysupply is small, a small stake reward is still at least proportionately reasonable, much better than 0.


If you say there actually is a tiny credit to the overall balance occurring, I will check the total balance more carefully, but so far looks like 0.

Maybe you can have a look at what Bitbardev mentioned/fixed for Bitbar, which is a related codebase to BitGem.  Looks like same issue.
At https://bitcointalk.org/index.php?topic=238608.0  and https://bitcointalk.org/index.php?topic=196125.100
Quote
Low diff is why even small transactions can make PoS blocks after very small amount of time, and the reward is minimal.
rounding is up to 2 decimals, rounddown.  Super small rewards ale below rounding are not paid.
ex:
reward of 3.432353 is rounded to 3.43
reward of 3.439865 is rounded to 3.43
reward of 0.009234 is rounded to 0.00
Quote
PoS difficulty is very low. Low diff is why even small transactions can make PoS blocks after very small amount of time, and the reward is minimal. Rounding was up to 2 decimals, rounding down. Super small rewards were below rounding and not paid.
new 0.4.1 update:
- no more rounding starting from block 12500 [23.06.2013]


Pages: « 1 2 [3] 4 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!