Pages:
Author

Topic: [ANNOUNCE] Ixcoin - a new Bitcoin fork - page 18. (Read 128457 times)

newbie
Activity: 42
Merit: 0
August 15, 2011, 11:26:41 AM
It will eventually hit zero.  You are right shifting the number 5000000000 one extra time every 210,000 blocks, eventually you will right shift out to zero.

Yes of course, but there's no inherent hard coded limit that must be edited. i.e. if you start with 150 coins per block, you are not going to get stuck at 21M simply because there's some magic number hard coded in. The algorithm will just run along until the maths produce a zero, so a sufficiently higher initial bounty will always end up with more coins in the system unless the algorithm is changed.
sr. member
Activity: 253
Merit: 250
August 15, 2011, 11:19:00 AM
I've added the currency to the list I'm maintaining but I won't touch this currency because I don't like it at all.
On the other hand, I own namecoins and I'm waiting for the rise in difficulty that merged mining will cause.

I think it would be great to see ixcoin fail for not adding any advantage (in fact, adding a disadvantage) over bitcoin. This way some concerns about forks "stealing" value from bitcoin may disappear.

Wait, you don't like Ixcoin, but you own Namecoins? *boggle*  If you think Ixcoin is bad, just look at what's coming up on the horizon in the way of a bunch of *coin clones.  Devcoin and I0coin are up next with many more to follow.  It's just one big cash grab after another.
member
Activity: 61
Merit: 10
August 15, 2011, 11:15:27 AM
It also exposes a poor coding practice by the original developers.  They hardcoded both 50 & 21000000 in the code, and I guess that's why I assumed that the 21mill that MAX_MONEY was set to was being used to limit the money supply.  What should've been done is to also make 50 a constant, and then at startup calculate the total number of coins that can be created based on that constant.  That way ixcoin could've just changed the constant from 50 to 96 and it all would've magically worked for him, no extra brainpower required lol...

MAX_MONEY is perhaps poorly named. What I see from a quick glance at the source (yes I finally decided to just download it), it is only referenced for a basic sanity check on the transaction output amount. Perhaps more a better name would be MAX_TRANSACTION_AMOUNT

In any case, whether it's Bitcoin or Ixcoin, a 21M coin limit per transaction is ridiculously high Cheesy

Again, there is NO hard limit on the number of coins that can be generated in Bitcoin.


It will eventually hit zero.  You are right shifting the number 5000000000 one extra time every 210,000 blocks, eventually you will right shift out to zero.
hero member
Activity: 742
Merit: 500
August 15, 2011, 11:06:20 AM
It also exposes a poor coding practice by the original developers.  They hardcoded both 50 & 21000000 in the code, and I guess that's why I assumed that the 21mill that MAX_MONEY was set to was being used to limit the money supply.  What should've been done is to also make 50 a constant, and then at startup calculate the total number of coins that can be created based on that constant.  That way ixcoin could've just changed the constant from 50 to 96 and it all would've magically worked for him, no extra brainpower required lol...

MAX_MONEY is perhaps poorly named. What I see from a quick glance at the source (yes I finally decided to just download it), it is only referenced for a basic sanity check on the transaction output amount. Perhaps more a better name would be MAX_TRANSACTION_AMOUNT

In any case, whether it's Bitcoin or Ixcoin, a 21M coin limit per transaction is ridiculously high Cheesy

Again, there is NO hard limit on the number of coins that can be generated in Bitcoin.


Yeah, my understanding is that the 21M total coins is not derived from a set variable, but is mathematically derived from the coin reward and reward halving frequency. The "final coin" is in the last block before the mining subsidy rounds itself down to zero.
newbie
Activity: 42
Merit: 0
August 15, 2011, 11:02:59 AM
It also exposes a poor coding practice by the original developers.  They hardcoded both 50 & 21000000 in the code, and I guess that's why I assumed that the 21mill that MAX_MONEY was set to was being used to limit the money supply.  What should've been done is to also make 50 a constant, and then at startup calculate the total number of coins that can be created based on that constant.  That way ixcoin could've just changed the constant from 50 to 96 and it all would've magically worked for him, no extra brainpower required lol...

MAX_MONEY is perhaps poorly named. What I see from a quick glance at the source (yes I finally decided to just download it), it is only referenced for a basic sanity check on the transaction output amount. Perhaps more a better name would be MAX_TRANSACTION_AMOUNT

In any case, whether it's Bitcoin or Ixcoin, a 21M coin limit per transaction is ridiculously high Cheesy

Again, there is NO hard limit on the number of coins that can be generated in Bitcoin.
hero member
Activity: 812
Merit: 1000
member
Activity: 61
Merit: 10
August 15, 2011, 10:31:07 AM

Edit:  Also seems to be laziness on the part of the original developers of ixcoin that they didn't keep that consistent.

When you're in a rush to start a worthless copy and scam people out of their money, it's hardly surprising you don't take the time to really understand what TF is going on.  The main thing is to get it out there as quickly as possible and get an army of monkeys working hard to make you rich.  Figure the rest out as you go along.

Too bad for those "early adopters" duped by this.  No matter what happens the "contract" is going to be changed under their feet from what they thought (again, their own laziness) they were promised.
It also exposes a poor coding practice by the original developers.  They hardcoded both 50 & 21000000 in the code, and I guess that's why I assumed that the 21mill that MAX_MONEY was set to was being used to limit the money supply.  What should've been done is to also make 50 a constant, and then at startup calculate the total number of coins that can be created based on that constant.  That way ixcoin could've just changed the constant from 50 to 96 and it all would've magically worked for him, no extra brainpower required lol...
legendary
Activity: 1708
Merit: 1020
August 15, 2011, 10:04:14 AM
some more stats are available at http://bitcoinx.com/ixcoin

edit: corrected; thanks payb.tc Roll Eyes

sr. member
Activity: 375
Merit: 250
<3 Bitcoins
August 15, 2011, 09:57:27 AM

Edit:  Also seems to be laziness on the part of the original developers of ixcoin that they didn't keep that consistent.

When you're in a rush to start a worthless copy and scam people out of their money, it's hardly surprising you don't take the time to really understand what TF is going on.  The main thing is to get it out there as quickly as possible and get an army of monkeys working hard to make you rich.  Figure the rest out as you go along.

Too bad for those "early adopters" duped by this.  No matter what happens the "contract" is going to be changed under their feet from what they thought (again, their own laziness) they were promised.


Not real sure how being an earlier adopter of Ixcoin is being duped.

Mined and sold IXC for over 450BTC in the past week since it launched.

You're only duped if you actually believe in the long term of it.

 I am in it for pure profit.
I don't believe in Bitcoin, Namecoin, Ixcoin or the next one that will launch soon.

None of it has a snowball's chance in Phoenix LOL

You lucky son of a bitch XD
donator
Activity: 668
Merit: 500
August 15, 2011, 09:18:15 AM

Edit:  Also seems to be laziness on the part of the original developers of ixcoin that they didn't keep that consistent.

When you're in a rush to start a worthless copy and scam people out of their money, it's hardly surprising you don't take the time to really understand what TF is going on.  The main thing is to get it out there as quickly as possible and get an army of monkeys working hard to make you rich.  Figure the rest out as you go along.

Too bad for those "early adopters" duped by this.  No matter what happens the "contract" is going to be changed under their feet from what they thought (again, their own laziness) they were promised.
legendary
Activity: 1022
Merit: 1001
August 15, 2011, 07:49:10 AM
Holy crap, the price has crippled! I'm buying in! The more people that buy in the higher the price will rise Wink

The price is scaled against the current price of Bitcoin (which is up atm)
full member
Activity: 123
Merit: 100
August 15, 2011, 07:42:21 AM
Holy crap, the price has crippled! I'm buying in! The more people that buy in the higher the price will rise Wink
legendary
Activity: 1372
Merit: 1002
August 15, 2011, 07:04:16 AM
I've added the currency to the list I'm maintaining but I won't touch this currency because I don't like it at all.
On the other hand, I own namecoins and I'm waiting for the rise in difficulty that merged mining will cause.

I think it would be great to see ixcoin fail for not adding any advantage (in fact, adding a disadvantage) over bitcoin. This way some concerns about forks "stealing" value from bitcoin may disappear.
member
Activity: 61
Merit: 10
August 15, 2011, 03:17:14 AM

Actually it is a right shift, so it is more like this:

1st stage: 50
2nd stage: 25
3rd stage: 12
4th stage: 6
5th stage: 3
6th stage: 1
7th stage: 0

Total should be 210000*50 + 210000*25 + 210000*12 + 210000*6 + 210000*3 + 210000*1 = 20370000

Again, unless I'm missing something or screwed up my math/logic somewhere

Your numbers are probably more accurate than mine since I'm basing mine based on reading wiki rather than delving into actual code Cheesy
Doing a right shift sounds more sensible than dividing and getting fractions early as well.

Although I don't think it stops at 1, does Bitcoin count represent 1 BTC as an bigint 1 or actually 1000000 and simply putting the decimal for display purposes?

Actually I screwed up a bit here.  There is another line of code I forgot to take into account:

int64 nSubsidy = 50 * COIN

and COIN is set to 100000000

So it goes like this:

Stage 1 : 50
Stage 2 : 25
Stage 3:  12.5
Stage 3 : 6.25
Stage 4 : 3.125
Stage 5:  1.5625
Stage 6:  0.78125
Stage 7:  0.390625

and so on

I was just using 50 and shifting it, so you were actually closer to right than me, lol.  It will eventually reach zero but very slowly.  I guess I'm not exactly exploring new ground here, but we can at least say it is maybe more clear what is happening in the code, it just right shifts the subsidy every 210,000 blocks, and so yeah IXcoin would generate many more coins since it would be starting the right shift from 96 instead of 50.  That one line of code basically controls everything as far as new coins are concerned.  Does that matter?  Not sure in my opinion both overall counts are relatively low given that there are 6 billion+ people on the planet.  I know you can divide it out to 8 places, but who wants to do that?

Edit:  Also seems to be laziness on the part of the original developers of ixcoin that they didn't keep that consistent.  Bitcoin put MAX_MONEY in to check the size of a transaction, any transaction that tried to move more than 21000000 coins would fail since there aren't any more coins than that.  There will be almost twice as many coins in the new block chain, and the most they could still move is 21000000, admittedly a nice and rare problem for someone to have, but something they should've caught.  There is nothing in the code that would cause any other problems, you just wouldn't be able to spend more than 21mill all at once...
sr. member
Activity: 266
Merit: 251
August 15, 2011, 03:04:08 AM
Actually it is a right shift, so it is more like this:

1st stage: 50
2nd stage: 25
3rd stage: 12
4th stage: 6
5th stage: 3
6th stage: 1
7th stage: 0

Total should be 210000*50 + 210000*25 + 210000*12 + 210000*6 + 210000*3 + 210000*1 = 20370000

Again, unless I'm missing something or screwed up my math/logic somewhere

The mining reward is measured in Satoshis.  It'll eventually get rounded down to zero, but not that quickly.
newbie
Activity: 42
Merit: 0
August 15, 2011, 02:53:05 AM

Actually it is a right shift, so it is more like this:

1st stage: 50
2nd stage: 25
3rd stage: 12
4th stage: 6
5th stage: 3
6th stage: 1
7th stage: 0

Total should be 210000*50 + 210000*25 + 210000*12 + 210000*6 + 210000*3 + 210000*1 = 20370000

Again, unless I'm missing something or screwed up my math/logic somewhere

Your numbers are probably more accurate than mine since I'm basing mine based on reading wiki rather than delving into actual code Cheesy
Doing a right shift sounds more sensible than dividing and getting fractions early as well.

Although I don't think it stops at 1, does Bitcoin count represent 1 BTC as an bigint 1 or actually 1000000 and simply putting the decimal for display purposes?
member
Activity: 61
Merit: 10
August 15, 2011, 02:43:34 AM

You're right, that constant is used in a function called MoneyRange which seems to be mainly used to check transaction size.  Where is the total supply actually limited in the original bitcoin code?

Edit:  Actually I see it is just based upon the subsidy being cut in half in the code every 210,000 blocks.  Interesting I just always assumed that constant was responsible.

nSubsidy >>= (nHeight / 210000);


You're right, there isn't a hard limit on the amount of bitcoins. 21 million is just rough level at which new Bitcoins generate per block is effectively negligible.

To make it clearer, this is what actually happens
1st "Stage": 50 BTC per block
2nd Stage : 25 BTC per block
3rd Stage : 12.5 BTC per block
4th Stage : 6.25 BTC per block
5th Stage : 3.125 BTC per block
6th Stage : 1.5625 BTC per block

So it just gets smaller and smaller so total Bitcoins would never reach the next million.

Actually it is a right shift, so it is more like this:

1st stage: 50
2nd stage: 25
3rd stage: 12
4th stage: 6
5th stage: 3
6th stage: 1
7th stage: 0

Total should be 210000*50 + 210000*25 + 210000*12 + 210000*6 + 210000*3 + 210000*1 = 20370000

Again, unless I'm missing something or screwed up my math/logic somewhere
newbie
Activity: 42
Merit: 0
August 15, 2011, 02:33:36 AM

You're right, that constant is used in a function called MoneyRange which seems to be mainly used to check transaction size.  Where is the total supply actually limited in the original bitcoin code?

Edit:  Actually I see it is just based upon the subsidy being cut in half in the code every 210,000 blocks.  Interesting I just always assumed that constant was responsible.

nSubsidy >>= (nHeight / 210000);


You're right, there isn't a hard limit on the amount of bitcoins. 21 million is just rough level at which new Bitcoins generate per block is effectively negligible.

To make it clearer, this is what actually happens
1st "Stage": 50 BTC per block
2nd Stage : 25 BTC per block
3rd Stage : 12.5 BTC per block
4th Stage : 6.25 BTC per block
5th Stage : 3.125 BTC per block
6th Stage : 1.5625 BTC per block

So it just gets smaller and smaller so total Bitcoins would never reach the next million.
member
Activity: 61
Merit: 10
August 15, 2011, 01:36:04 AM
Well I'm no expert on the code, but MAX_MONEY is still set to 21000000 in main.h, so unless I'm missing something it's still capped at the same amount.

That constant does almost nothing. All it limits is the amount of money that can change hands in a single transaction, not the total amount of money in circulation.

That thread is incorrect in stating that blocks will begin being rejected. Things will continue past 21 million IXC as usual, unless one person happens to hold half of the money.

The point I was trying to make here is that Ixcoin's fundamental reason for existing (at least, the publicly stated one) isn't actually real, but it's still documented as such in the forum posting and the Ixcoin FAQ. What's wrong with re-raising the issue here? It seemed rather important to me.
You're right, that constant is used in a function called MoneyRange which seems to be mainly used to check transaction size.  Where is the total supply actually limited in the original bitcoin code?

Edit:  Actually I see it is just based upon the subsidy being cut in half in the code every 210,000 blocks.  Interesting I just always assumed that constant was responsible.

nSubsidy >>= (nHeight / 210000);
hero member
Activity: 516
Merit: 643
August 15, 2011, 12:59:00 AM
Well I'm no expert on the code, but MAX_MONEY is still set to 21000000 in main.h, so unless I'm missing something it's still capped at the same amount.

That constant does almost nothing. All it limits is the amount of money that can change hands in a single transaction, not the total amount of money in circulation.

That thread is incorrect in stating that blocks will begin being rejected. Things will continue past 21 million IXC as usual, unless one person happens to hold half of the money.

The point I was trying to make here is that Ixcoin's fundamental reason for existing (at least, the publicly stated one) isn't actually real, but it's still documented as such in the forum posting and the Ixcoin FAQ. What's wrong with re-raising the issue here? It seemed rather important to me.
Pages:
Jump to: