Amateur hour

[acoindr]

Okay, you may know something about programming, but you appear to know nothing about monetary systems.

Actually, I am published author on economics and I have had articles published by Mises.org.

Widespread adoption of bitcoins would certainly decrease price volatility, but nevertheless, price swings would still persist.

In an economically proper crypto currency each client would maintain a constant, the value multiplier, just the way it now maintains the proof of work target. The value multiplier would determine how many bitcoins each address has by multiplying the wallet's fraction. Thus, the number of bitcoins you had would go up and down, but their value would remain relatively constant.

Not true. To measure value you need to measure against something else. For obvious reasons bitcoins are commonly measured against dollars, but also other currencies and even precious metals like gold or silver. You cannot maintain a constant bitcoin value by simply modifying the number of bitcoins each account has. The number of bitcoins, as well as how fast they come into existence, is known. This is how a value for them is first established; a pizza was bought for about 10K bitcoins which established a dollar value for them. If the rate of bitcoins had been 10 times what it was then that pizza would likely to have been bought for 100K bitcoins, because that number relative to how many total that account holder had would have been commensurate. That's all the effect of increasing the number has; it means each individual bitcoin becomes worth less, not any constant value.

For example, the capitalization of bitcoins has recently gone from $50 million to over $300 million, with a consequent increase in the value of each bitcoin. This is because the supply of bitcoins has not increased as fast as the volume of transactions has increased.

No, it had nothing to do with transaction volume. It had to do with the fact the rate of bitcoins coming into existence was not enough to keep up with the demand of people wanting them.

The proximate cause is, you are right, demand for the coins, but it is hard for the clients to know what the "demand" is. They can know the volume, however, so the volume can serve as a proxy for the current demand level.

Did you say earlier you worked for the Fed? I would find that believable.

That was a joke .

Again, you convince me you know nothing about monetary systems.

If I'm not mistaken an author on Mises.org dismissed Bitcoin early on explaining it wasn't "backed by anything".

And, no, transaction volume is not an accurate proxy for demand. In fact, anyone around Bitcoin any length of time would know a large skepticism people have about it is that not much of use can be bought with bitcoins. The transaction volume can be a fraction of what it is now while having the exact same demand that's keeping the price at about $40 on MtGox.

[Blinken]

Ok, that answers the last question.  What about the two right before it that you conveniently avoided?

The fact of the matter is, there is no way to determine true transaction volume without knowing who is sending to who.  Therefore, this multiplier could be manipulated by anyone at any time for any reason, and would not be a reliably corollary for supply (and therefore price) to base itself upon.  You seem to want to simply ignore this glaring flaw in your argument for price stability.

I don't see why it is necessary to discriminate the change address. When a node confirms a transaction it has complete knowledge of the amounts of bitcoins involved in the transaction.

It is true that clients can create spurious volume by ping ponging transactions back and forth, but I accept that as a possible source of error. In truth, we can imagine transactions of different importance. For example, two parties might be doing a business deal, but another transaction might be some guy juggling the coins in his accounts to tidy them up. The multiplication metric does not attempt to judge how "worthy" a transaction is, it just gauges the overall volume.

So you think that if I send a transaction of 1 BTC to someone out of an address holding a 100 BTC input, that counting all 100 BTC as transaction volume is ok?  99 BTC of that isn't true economic activity, and shouldn't be an indicator of such.

Here's an example of how to game your system.

I plan to buy a car for 1,000 BTC.
I send that 1,000 BTC on a wild goose chase across many many different addresses, to generate false transaction volume and increase the multiplier.  I now have 1,100 BTC.  I send 1,000 BTC to the dealer, "saving" myself 100 BTC.  Because the transaction volume was false, I am left (at some point in the future when the multiplier re-adjusts) with 91 BTC, and the dealer is left with 909 BTC (roughly).

Regardless, I think your idea has merit as an experimental altcoin (it IS an interesting idea), just not exactly in the way you describe.

I think you still need a reasonable way to distribute currency at the beginning that doesn't just involve a multiplier (the way you describe it, it would be a 100% premine with a single person holding on to all of the currency until they decided to distribute it how they choose), but creates some method of distributing new currency to new users across many years.

I think that transaction volume should be indicated in "Altcoin days destroyed" instead of straight-up transaction volume over a given period of time.  This would prevent, to an extent, gaming of the system, though holders of large numbers of Altcoin days could theoretically game the system one time.  Maybe they put Altcoin days up for sale to be destroyed upon the date and time of the highest bidder's choosing or something.

I also think that some people might be more concerned with coins being added or taken from their account on an unpredictable basis than they would be of the price fluctuations inherent in Bitcoin.  Would people rather have a fluctuating number of coins in their wallet based on a best estimate of transaction volume, or would they rather have a fluctuating price based on free market buying and selling?

And finally, couldn't a decrease in transaction volume, which would cause people to lose coins from their wallets, theoretically feedback to itself in a deflationary spiral?  Something along the lines of, "Well, I only have 90 coins instead of 100 that I had yesterday, so I'm not going to buy that computer."  And then they only have 80 coins, then 70, etc, because no one is buying anything?  I mean, I'm not making the argument that Bitcoin doesn't also have the same potential problem, but this doesn't fix potential deflation-related problems.

You are right, there is a psychological effect of, gee I had 100 btc yesterday, and today I only have 90, but the dollar value should remain roughly the same if the multiplier is doing its job. So if your 100 btc were worth $1000, then your 90 btc should be worth approximately the same, $1000.

Note that in practice I would expect the multiplier to change slowly, so that daily changes in your btc count might only be 0.5% or less. Compare that to the situation today where the value of bitcoins is bouncing up and down 15% every day. Right now it is hard for vendors to use bitcoins because they have to have a live link to an exchange to keep their prices in sync, which is a big hassle and uncertainty. With a stability multiplier the vendor can set a single price in btc and the value will remain constant over a long period of time. No need to be constantly updating your prices. For a vendor with thousands of items in inventory that is a game changing advantage.

[SgtSpike]

Ok, that answers the last question.  What about the two right before it that you conveniently avoided?

The fact of the matter is, there is no way to determine true transaction volume without knowing who is sending to who.  Therefore, this multiplier could be manipulated by anyone at any time for any reason, and would not be a reliably corollary for supply (and therefore price) to base itself upon.  You seem to want to simply ignore this glaring flaw in your argument for price stability.

I don't see why it is necessary to discriminate the change address. When a node confirms a transaction it has complete knowledge of the amounts of bitcoins involved in the transaction.

It is true that clients can create spurious volume by ping ponging transactions back and forth, but I accept that as a possible source of error. In truth, we can imagine transactions of different importance. For example, two parties might be doing a business deal, but another transaction might be some guy juggling the coins in his accounts to tidy them up. The multiplication metric does not attempt to judge how "worthy" a transaction is, it just gauges the overall volume.

So you think that if I send a transaction of 1 BTC to someone out of an address holding a 100 BTC input, that counting all 100 BTC as transaction volume is ok?  99 BTC of that isn't true economic activity, and shouldn't be an indicator of such.

Here's an example of how to game your system.

I plan to buy a car for 1,000 BTC.
I send that 1,000 BTC on a wild goose chase across many many different addresses, to generate false transaction volume and increase the multiplier.  I now have 1,100 BTC.  I send 1,000 BTC to the dealer, "saving" myself 100 BTC.  Because the transaction volume was false, I am left (at some point in the future when the multiplier re-adjusts) with 91 BTC, and the dealer is left with 909 BTC (roughly).

Regardless, I think your idea has merit as an experimental altcoin (it IS an interesting idea), just not exactly in the way you describe.

I think you still need a reasonable way to distribute currency at the beginning that doesn't just involve a multiplier (the way you describe it, it would be a 100% premine with a single person holding on to all of the currency until they decided to distribute it how they choose), but creates some method of distributing new currency to new users across many years.

I think that transaction volume should be indicated in "Altcoin days destroyed" instead of straight-up transaction volume over a given period of time.  This would prevent, to an extent, gaming of the system, though holders of large numbers of Altcoin days could theoretically game the system one time.  Maybe they put Altcoin days up for sale to be destroyed upon the date and time of the highest bidder's choosing or something.

I also think that some people might be more concerned with coins being added or taken from their account on an unpredictable basis than they would be of the price fluctuations inherent in Bitcoin.  Would people rather have a fluctuating number of coins in their wallet based on a best estimate of transaction volume, or would they rather have a fluctuating price based on free market buying and selling?

And finally, couldn't a decrease in transaction volume, which would cause people to lose coins from their wallets, theoretically feedback to itself in a deflationary spiral?  Something along the lines of, "Well, I only have 90 coins instead of 100 that I had yesterday, so I'm not going to buy that computer."  And then they only have 80 coins, then 70, etc, because no one is buying anything?  I mean, I'm not making the argument that Bitcoin doesn't also have the same potential problem, but this doesn't fix potential deflation-related problems.

You are right, there is a psychological effect of, gee I had 100 btc yesterday, and today I only have 90, but the dollar value should remain roughly the same if the multiplier is doing its job. So if your 100 btc were worth $1000, then your 90 btc should be worth approximately the same, $1000.

Note that in practice I would expect the multiplier to change slowly, so that daily changes in your btc count might only be 0.5% or less. Compare that to the situation today where the value of bitcoins is bouncing up and down 15% every day. Right now it is hard for vendors to use bitcoins because they have to have a live link to an exchange to keep their prices in sync, which is a big hassle and uncertainty. With a stability multiplier the vendor can set a single price in btc and the value will remain constant over a long period of time. No need to be constantly updating your prices. For a vendor with thousands of items in inventory that is a game changing advantage.

How about the non-psychological effect of cheating my car dealer out of 91 BTC?  Even though you don't see it in the price, the value that a person is holding still fluctuates.

You said that in practice, even if someone tried to game it, the daily changes might be 0.5% or less.  I don't have enough of a predictive spirit to know whether that is true, which is why I think this would be an interesting experiment, to see what would really happen.  If the multiplier doesn't change quickly enough, it won't be a true enough indicator of economic activity, and the price could vary greatly.  If the multiplier changes too quickly, it would be too easy to game.  There would certainly need to be some sort of balance between the two.

If the vendor sets up a link to an exchange, it doesn't matter if they sell 100 items or 10,000, it's the same amount of work to set up said link.  Not really a game-changer IMO.

You still haven't really touched on how you would initially distribute a currency like this.  If not through mining, then how?

[sd]

The comparison of currency to stocks by sd isn't apt. The two are not compatible.

Are you seriously saying that something about the nature of currencies means nobody would ever change shift the decimal point? Or are you just trolling me?

'Since 1960, governments of developing and transition economies have redenominated their currencies on approximately seventy occasions.'
 -- http://www.google.nl/url?sa=t&rct=j&q=remove%20zeros%20currency&source=web&cd=5&cad=rja&ved=0CEoQFjAE&url=http%3A%2F%2Fwww.unc.edu%2F~lmosley%2FAPSA%25202005.pdf&ei=zXc_UZLpO8iNOKvLgKgE&usg=AFQjCNEv2UciW5vxGEzB1j3kpjb-6Bh9Nw

No, I didn't say the nature of currencies means nobody would ever change or shift the decimal point. I said the comparison of currency to stocks isn't apt.

In the context of moving the decimal point so the number of units of a thing a person has changes whilst the value they hold doesn't change you are saying that currencies and stocks behave differently. You are either mistaken or deliberately trolling.

[Blinken]

Ok, that answers the last question.  What about the two right before it that you conveniently avoided?

The fact of the matter is, there is no way to determine true transaction volume without knowing who is sending to who.  Therefore, this multiplier could be manipulated by anyone at any time for any reason, and would not be a reliably corollary for supply (and therefore price) to base itself upon.  You seem to want to simply ignore this glaring flaw in your argument for price stability.

I don't see why it is necessary to discriminate the change address. When a node confirms a transaction it has complete knowledge of the amounts of bitcoins involved in the transaction.

It is true that clients can create spurious volume by ping ponging transactions back and forth, but I accept that as a possible source of error. In truth, we can imagine transactions of different importance. For example, two parties might be doing a business deal, but another transaction might be some guy juggling the coins in his accounts to tidy them up. The multiplication metric does not attempt to judge how "worthy" a transaction is, it just gauges the overall volume.

So you think that if I send a transaction of 1 BTC to someone out of an address holding a 100 BTC input, that counting all 100 BTC as transaction volume is ok?  99 BTC of that isn't true economic activity, and shouldn't be an indicator of such.

Here's an example of how to game your system.

I plan to buy a car for 1,000 BTC.
I send that 1,000 BTC on a wild goose chase across many many different addresses, to generate false transaction volume and increase the multiplier.  I now have 1,100 BTC.  I send 1,000 BTC to the dealer, "saving" myself 100 BTC.  Because the transaction volume was false, I am left (at some point in the future when the multiplier re-adjusts) with 91 BTC, and the dealer is left with 909 BTC (roughly).

Regardless, I think your idea has merit as an experimental altcoin (it IS an interesting idea), just not exactly in the way you describe.

I think you still need a reasonable way to distribute currency at the beginning that doesn't just involve a multiplier (the way you describe it, it would be a 100% premine with a single person holding on to all of the currency until they decided to distribute it how they choose), but creates some method of distributing new currency to new users across many years.

I think that transaction volume should be indicated in "Altcoin days destroyed" instead of straight-up transaction volume over a given period of time.  This would prevent, to an extent, gaming of the system, though holders of large numbers of Altcoin days could theoretically game the system one time.  Maybe they put Altcoin days up for sale to be destroyed upon the date and time of the highest bidder's choosing or something.

I also think that some people might be more concerned with coins being added or taken from their account on an unpredictable basis than they would be of the price fluctuations inherent in Bitcoin.  Would people rather have a fluctuating number of coins in their wallet based on a best estimate of transaction volume, or would they rather have a fluctuating price based on free market buying and selling?

And finally, couldn't a decrease in transaction volume, which would cause people to lose coins from their wallets, theoretically feedback to itself in a deflationary spiral?  Something along the lines of, "Well, I only have 90 coins instead of 100 that I had yesterday, so I'm not going to buy that computer."  And then they only have 80 coins, then 70, etc, because no one is buying anything?  I mean, I'm not making the argument that Bitcoin doesn't also have the same potential problem, but this doesn't fix potential deflation-related problems.

You are right, there is a psychological effect of, gee I had 100 btc yesterday, and today I only have 90, but the dollar value should remain roughly the same if the multiplier is doing its job. So if your 100 btc were worth $1000, then your 90 btc should be worth approximately the same, $1000.

Note that in practice I would expect the multiplier to change slowly, so that daily changes in your btc count might only be 0.5% or less. Compare that to the situation today where the value of bitcoins is bouncing up and down 15% every day. Right now it is hard for vendors to use bitcoins because they have to have a live link to an exchange to keep their prices in sync, which is a big hassle and uncertainty. With a stability multiplier the vendor can set a single price in btc and the value will remain constant over a long period of time. No need to be constantly updating your prices. For a vendor with thousands of items in inventory that is a game changing advantage.

How about the non-psychological effect of cheating my car dealer out of 91 BTC?  Even though you don't see it in the price, the value that a person is holding still fluctuates.

You said that in practice, even if someone tried to game it, the daily changes might be 0.5% or less.  I don't have enough of a predictive spirit to know whether that is true, which is why I think this would be an interesting experiment, to see what would really happen.  If the multiplier doesn't change quickly enough, it won't be a true enough indicator of economic activity, and the price could vary greatly.  If the multiplier changes too quickly, it would be too easy to game.  There would certainly need to be some sort of balance between the two.

If the vendor sets up a link to an exchange, it doesn't matter if they sell 100 items or 10,000, it's the same amount of work to set up said link.  Not really a game-changer IMO.

You still haven't really touched on how you would initially distribute a currency like this.  If not through mining, then how?

Well, in the beginning one person would have the entire pool which could be started at some convenient number of coins, say 1000. Then the Adam would pay some of them to Eve, say 250. So on and so forth.

Now, in thinking about this, I see there is a mistake in my plan because if the multiplier were applied to all coins equally then Eve's pool (imagine she held onto it) would always be worth 25% of the total which would mean her wallet would grow in value. So, to make it work we need to only apply the multiplier to the coins being transacted. That way the value of Eve's coins stays the same if she holds onto them. Now, as you said above this seems to create a situation where you can increase the number of coins you have just by doing fake transactions, but this is not strictly true because remember that the multiplier can be positive or negative, so if you did your transaction during a downturn then the value of the coins might decrease slightly instead of increase. In any case, the hope would be that the change on any one transaction would be so small that it would not be worth creating fake transactions. In fact, using a transaction processing fee linked to the multiplier might prevent the benefit entirely.

You can see one of the advantages of this system compared to bitcoins the way they are now: if Eve were to hold onto her btc which the capitalization grew, her 25% could turn into millions of dollars even though the original value of the transaction might be, say $20. But with a multiplier her coins will never be worth more than the original $20, because they are price stable.

[sd]

You are right, there is a psychological effect of, gee I had 100 btc yesterday, and today I only have 90, but the dollar value should remain roughly the same if the multiplier is doing its job. So if your 100 btc were worth $1000, then your 90 btc should be worth approximately the same, $1000.

Note that in practice I would expect the multiplier to change slowly, so that daily changes in your btc count might only be 0.5% or less. Compare that to the situation today where the value of bitcoins is bouncing up and down 15% every day. Right now it is hard for vendors to use bitcoins because they have to have a live link to an exchange to keep their prices in sync, which is a big hassle and uncertainty. With a stability multiplier the vendor can set a single price in btc and the value will remain constant over a long period of time. No need to be constantly updating your prices. For a vendor with thousands of items in inventory that is a game changing advantage.

You are proposing an exchange rate mechanism that can only be based on inputs that can be gamed by false transactions. There is no way a cryptocurrency can tell the difference between a hedge fund buying ten thousand coins for a few million and me buying a single pizza from a guy on these forums for the same number of coins. It can't tell the entire transaction thoughput of visa worth billions from a bunch of kids gambling fractions of a cent on something like satoshidice.

The Eurozone tried an exchange rate mechanism and it fell apart. And that's with knowledgeable people actively managing it.

[glitch003]

For such a genius, your code has some pretty glaring inefficiencies to it.  


You could optimize this to a single if statement of the form if(items < 1 || slots < 1 || slots > items) return 0;

      if( items < 1 || slots < 1 ) return 0;
      if( slots > items ) return 0;

This is done for clarity, not efficiency. Since the two tests are conceptually different, I separate them into different lines. The savings by combining the statements is not significant enough that it is preferable to the two-statement version.

You allocate arrays at a size of 100 and implement your own inefficient array grow algorithm which is less efficient than using a datastructure that supports growing natively.  

int[] aiNumeratorFactors = new int[100];

And the array grow:

if( aiNumeratorFactors[0] == aiNumeratorFactors.length - 1 ){ // need to expand list
               int[] aiNumeratorFactors_new = new int[aiNumeratorFactors.length * 2];
               System.arraycopy( aiNumeratorFactors, 0, aiNumeratorFactors_new, 0, aiNumeratorFactors.length );
               aiNumeratorFactors = aiNumeratorFactors_new;
            }

It is faster to do this. If you use collections class, like ArrayList, then each access must be through a method, as opposed to an array reference, which is much faster because it does not have call overhead. Also, if you read the source code to the add() method in ArrayList you can see that it does two internal calls making it much less efficient than my version. In fact, even the method ArrayList uses to expand its own array is slower than the direct memory allocation I do here, once again because of additional method calls in its ensureCapacity() method.

After inserting data into your arrays, you sort them.  It would instead be more efficient to simply insert the data into the arrays in the right order.  Essentially doing the sorting logic on insert instead of after the fact.

      java.util.Arrays.sort( aiNumeratorFactors );
      java.util.Arrays.sort( aiDenominatorFactors );

How do you know what the right order is? Each list of factors begins as a union of the factors of multiple numbers. For example, if you have 15! then you have factors for 15, factors for 14, factors for 13, 12, 11, 10, etc. So you have sets like {3, 5}{2, 7}{13}{2,2,3} etc. These sets must be made into a union: {3,5,2,7,13,2,23} and then sorted. When you are creating the union there is no way to know where each element will appear in the sorted array ahead of time.

Ok, post the code for your factor() method so that I can create a runnable demo.  I will prove to you that I can make your code run faster.

[Rincewind]

Well, in the beginning one person would have the entire pool which could be started at some convenient number of coins, say 1000. Then the Adam would pay some of them to Eve, say 250. So on and so forth.

Now, in thinking about this, I see there is a mistake in my plan because if the multiplier were applied to all coins equally then Eve's pool (imagine she held onto it) would always be worth 25% of the total which would mean her wallet would grow in value.

This would make Adam the first man in history to keep 75% of his wealth away from his wife, and Eve the first woman in history to hold onto everything she did manage to get.

[Jason]

Note that in practice I would expect the multiplier to change slowly, so that daily changes in your btc count might only be 0.5% or less. Compare that to the situation today where the value of bitcoins is bouncing up and down 15% every day. Right now it is hard for vendors to use bitcoins because they have to have a live link to an exchange to keep their prices in sync, which is a big hassle and uncertainty. With a stability multiplier the vendor can set a single price in btc and the value will remain constant over a long period of time. No need to be constantly updating your prices. For a vendor with thousands of items in inventory that is a game changing advantage.

You bring up an interesting point, and the market has already come up with a solution for this with futures contracts.

Instead of worrying about fluctuations in the value of bitcoin, it should be possible to place your bitcoins in escrow and make a deal with a broker to pay you some price for your bitcoins on some pre-agreed date.  The value for the price should be at least equal to the value on the date you place the coins in escrow plus the money market interest rate you could get at a bank, potentially more.

Now the person entering into a contract with you to buy the coins would be taking the risk if the value dropped, but I think there is plenty of demand to do this given the price history for the past several years.

I'm not sure what effect this would have on the volatility of BTC at the exchanges (I suspect it would reduce it, but that's just a guess), but it would relieve merchants from having to worry about it and even allow them to make some small returns on their coins rather than paying a company like bitpay to convert their bitcoins into fiat currency on a daily (or more frequent) basis.

[snaxion]

Snippet war! Everyone post a snippet of what they have written. I will evaluate and declare a winner

10 PRINT "YOU GOT A BITCOIN!"
20 GOTO 10

On the leaderboard, we have Greyhawk.

[acoindr]

In the context of moving the decimal point so the number of units of a thing a person has changes whilst the value they hold doesn't change you are saying that currencies and stocks behave differently. You are either mistaken or deliberately trolling.

sd, I believe what we have here is a hang up due to semantics. Let me quote your earlier text:

I assume coins would be split so there are more in circulation. Yes it's exactly the same as moving the decimal place as far as value is concerned but it's still done by major companies all the time. See http://en.wikipedia.org/wiki/Stock_split

Bold emphasis mine. By saying "exactly the same" as far as value is concerned and including that major companies do it all the time you suggest to the reader the consequences of moving the decimal for currency and stocks is the same. It is not.

If you double the amount of currency in a system the per unit purchasing power of each holder is essentially reduced by half, but if amount of currency is doubled equally among holders net purchasing power stays the same; so all you've done is change the numbers, not value. I'm sure we agree. If you do a 2 for 1 stock split of a strong company then the total market value of the shares each holder has will be roughly the same since the market will value each share at half the pre-split price; again all you've done is change the numbers, not value.

To this point I'm sure we are in agreement. However, as time goes on the holders of currency maintain the same net purchasing power, yet something different happens for owners of stock split shares; what usually happens is they find by doing absolutely nothing the value of each of their shares regains its pre-split price, making them twice as wealthy in shares as they were. This is due to the external affect of the market (notably, in an inflationary environment). So while stock split holders gain wealth, holders of a doubled currency do not. That is a key difference. There are also other factors which may severely affect market price such as company mismanagement etc. This is why I said the comparison of stocks to currency isn't apt.

But this appears to be over semantics. If I reword your text as follows I believe we are in complete agreement:

"Yes it's exactly the same as moving the decimal place as far as [initial] value is concerned but it's still done by major companies all the time."

I hesitated to respond because I don't want to distract from the exchange between Blitzen and glitch003 so I'll repost the challenge of the latter:

Ok, post the code for your factor() method so that I can create a runnable demo.  I will prove to you that I can make your code run faster.

[thezerg]

OP

I am spending my time writing this not because I care anything about you but because I am offended at your graceless attitude towards our current devs who are working hard and doing a great job.  And they should know that "we the people" are merely amused by people like you.


On intelligence:
You seem to have no contextual social awareness.  So if you are smart it is only in narrow subdomains. 

And you seem to have actually taken an IQ test and are boasting your scores; 2 behaviors rarely exhibited by the group in which you claim membership.

Domain knowledge (hamiltonian cycle etc) is no measure of intelligence as it is easily acquired but you seem unaware of this.

You seem to be unaware of the massive gaps in your own proposals.

You seem to have no real understanding of project longevity -- of how the evolution of the importance and criticality of a project creates problems.  You are completely unwilling to contribute, but you seem to be unable to recognize that all projects and contributors juggle similar time constraints and so often the implemented solution is not optimal, simply expedient.  And some shortcuts which are irrelevant when bitcoin is valued at .02 can become very important when it is 50 bucks.


Your ideas...

have already been considered and implemented in alt-coins as some have suggested.  At least the ones that aren't totally stupid.

ignore the hard problems... like how to spontaneously derive a trust metric using an algorithm that cannot be defeated even if examined.


Also, adjusting the balance in everybody's account rather then the price of goods will fool absolutely nobody.

And FYI, Bitcoin transfer or txn volume has no causal correlation to the price of a bitcoin in USD and only a large-time statistical correlation.  And the price of BTC/USD vs BTC/silver vs BTC/web hosting are also not correlated so your single adjustment cannot hold more then one commodity steady.  And it cannot even do that, because you are suggesting a maximum adjustment of what was it, .5% but we are seeing 25% volatility on a daily basis. 

You have made absolutely zero consideration of self-interested (i.e. antagonistic) agents.  And miss completely obvious strategies like "calculate the same algorithm (its FOSS) just before the network does.  If it is going to reduce your coins, sell to another currency/commodity, if it will increase them buy coins."  You have obviously only coded in an environment where all the programs are essentially considered to be benignly working towards the same goal -- that is, a normal corporate project.

When you were asked what you have done, a reasonable response would have been to point to a large OSS project that you have contributed to instead of your silly code snippets that have no applicability.


In the end you present yourself as rude and stupid.  Truly this is amateur hour -- you are presenting yourself as such.  At the same time, thx for the laughs!

[SgtSpike]

Ok, that answers the last question.  What about the two right before it that you conveniently avoided?

The fact of the matter is, there is no way to determine true transaction volume without knowing who is sending to who.  Therefore, this multiplier could be manipulated by anyone at any time for any reason, and would not be a reliably corollary for supply (and therefore price) to base itself upon.  You seem to want to simply ignore this glaring flaw in your argument for price stability.

I don't see why it is necessary to discriminate the change address. When a node confirms a transaction it has complete knowledge of the amounts of bitcoins involved in the transaction.

It is true that clients can create spurious volume by ping ponging transactions back and forth, but I accept that as a possible source of error. In truth, we can imagine transactions of different importance. For example, two parties might be doing a business deal, but another transaction might be some guy juggling the coins in his accounts to tidy them up. The multiplication metric does not attempt to judge how "worthy" a transaction is, it just gauges the overall volume.

So you think that if I send a transaction of 1 BTC to someone out of an address holding a 100 BTC input, that counting all 100 BTC as transaction volume is ok?  99 BTC of that isn't true economic activity, and shouldn't be an indicator of such.

Here's an example of how to game your system.

I plan to buy a car for 1,000 BTC.
I send that 1,000 BTC on a wild goose chase across many many different addresses, to generate false transaction volume and increase the multiplier.  I now have 1,100 BTC.  I send 1,000 BTC to the dealer, "saving" myself 100 BTC.  Because the transaction volume was false, I am left (at some point in the future when the multiplier re-adjusts) with 91 BTC, and the dealer is left with 909 BTC (roughly).

Regardless, I think your idea has merit as an experimental altcoin (it IS an interesting idea), just not exactly in the way you describe.

I think you still need a reasonable way to distribute currency at the beginning that doesn't just involve a multiplier (the way you describe it, it would be a 100% premine with a single person holding on to all of the currency until they decided to distribute it how they choose), but creates some method of distributing new currency to new users across many years.

I think that transaction volume should be indicated in "Altcoin days destroyed" instead of straight-up transaction volume over a given period of time.  This would prevent, to an extent, gaming of the system, though holders of large numbers of Altcoin days could theoretically game the system one time.  Maybe they put Altcoin days up for sale to be destroyed upon the date and time of the highest bidder's choosing or something.

I also think that some people might be more concerned with coins being added or taken from their account on an unpredictable basis than they would be of the price fluctuations inherent in Bitcoin.  Would people rather have a fluctuating number of coins in their wallet based on a best estimate of transaction volume, or would they rather have a fluctuating price based on free market buying and selling?

And finally, couldn't a decrease in transaction volume, which would cause people to lose coins from their wallets, theoretically feedback to itself in a deflationary spiral?  Something along the lines of, "Well, I only have 90 coins instead of 100 that I had yesterday, so I'm not going to buy that computer."  And then they only have 80 coins, then 70, etc, because no one is buying anything?  I mean, I'm not making the argument that Bitcoin doesn't also have the same potential problem, but this doesn't fix potential deflation-related problems.

You are right, there is a psychological effect of, gee I had 100 btc yesterday, and today I only have 90, but the dollar value should remain roughly the same if the multiplier is doing its job. So if your 100 btc were worth $1000, then your 90 btc should be worth approximately the same, $1000.

Note that in practice I would expect the multiplier to change slowly, so that daily changes in your btc count might only be 0.5% or less. Compare that to the situation today where the value of bitcoins is bouncing up and down 15% every day. Right now it is hard for vendors to use bitcoins because they have to have a live link to an exchange to keep their prices in sync, which is a big hassle and uncertainty. With a stability multiplier the vendor can set a single price in btc and the value will remain constant over a long period of time. No need to be constantly updating your prices. For a vendor with thousands of items in inventory that is a game changing advantage.

How about the non-psychological effect of cheating my car dealer out of 91 BTC?  Even though you don't see it in the price, the value that a person is holding still fluctuates.

You said that in practice, even if someone tried to game it, the daily changes might be 0.5% or less.  I don't have enough of a predictive spirit to know whether that is true, which is why I think this would be an interesting experiment, to see what would really happen.  If the multiplier doesn't change quickly enough, it won't be a true enough indicator of economic activity, and the price could vary greatly.  If the multiplier changes too quickly, it would be too easy to game.  There would certainly need to be some sort of balance between the two.

If the vendor sets up a link to an exchange, it doesn't matter if they sell 100 items or 10,000, it's the same amount of work to set up said link.  Not really a game-changer IMO.

You still haven't really touched on how you would initially distribute a currency like this.  If not through mining, then how?

Well, in the beginning one person would have the entire pool which could be started at some convenient number of coins, say 1000. Then the Adam would pay some of them to Eve, say 250. So on and so forth.

Now, in thinking about this, I see there is a mistake in my plan because if the multiplier were applied to all coins equally then Eve's pool (imagine she held onto it) would always be worth 25% of the total which would mean her wallet would grow in value. So, to make it work we need to only apply the multiplier to the coins being transacted. That way the value of Eve's coins stays the same if she holds onto them. Now, as you said above this seems to create a situation where you can increase the number of coins you have just by doing fake transactions, but this is not strictly true because remember that the multiplier can be positive or negative, so if you did your transaction during a downturn then the value of the coins might decrease slightly instead of increase. In any case, the hope would be that the change on any one transaction would be so small that it would not be worth creating fake transactions. In fact, using a transaction processing fee linked to the multiplier might prevent the benefit entirely.

You can see one of the advantages of this system compared to bitcoins the way they are now: if Eve were to hold onto her btc which the capitalization grew, her 25% could turn into millions of dollars even though the original value of the transaction might be, say $20. But with a multiplier her coins will never be worth more than the original $20, because they are price stable.

Apply the multiplier to the coins being transacted?  Then people would most certainly be sending coins to themselves!  The multiplier is public information, so any time the multiplier is greater than 1, people would send themselves coins constantly, to continually increase the number of coins they have.  Which would, in turn, increase the multiplier even further, and it'd just spiral upward in fake inflation forever.

It seems like the longer this discussion continues, the more elementary the mistakes you are making in your logic.

[notme]

Right now, I not planning on re-arranging my life to take an unpaid position as a bitcoin developer.

You don't need to be unpaid. If your abilities are as good as you claim you should be able to find plenty of people willing to donate.

For example, just look at how quickly the OSX packaging for Armory bounty was raised.

That's a nice thought, but I checked out the donations to the Armory address and it came to about 200 bitcoins. That would last me about 2 weeks.

You require $216,000/year to subside?  

When you know the difference between a Hamiltonian cycle and a Mercier cycle you get paid the big bucks.

WTF is a Mercier cycle?  I know Hamiltonian cycles, but I've never heard of a Mercier cycle, and google (regular and scholar) doesn't have a clue either.

Also, just because you make that much now doesn't mean you need that much.  What you're trying to say is you are greedy and aren't willing to give up your cushy paycheck to push forward the state of the art of public technology.  You'd rather suck the teat of the corporate monstrosity and empower the already powerful.  I hope you have some survival skills for when the shit hits the fan.  You may be okay if you are with a defense contractor, but your conscience won't be.

[Blowfeld]

The Fed doesn't pay me enough to put up with this, but ok... here is byte code for x86 that translates either a decimal or hexadecimal string to a binary value (yes, I actually wrote the byte code, and yes, I can read and write x86 machine encodings in hex):

31C053515657555231F68A0280F8307C1080F8397F0B2C3083C6015083C201EBE9C7C50A000000C 7C10100000031DB89F783FE00741058F7E101C383EE0189C8F7E589C1EBEB89D85A01FA5D5F5E59 5BC331C053515657555231F68A0280F8307C0980F8397F042C30EB0C80F8417C1080F8467F0B2C4 B83C6015083C201EBDBC7C510000000EB9F

The decimal reader is at offset 0 and expects a non-digit terminated string at an address in the EDX register. The hex reader is at offset 136 and expects the same input. Both routines return the answer in EAX register. Total bytes: 136.

Here is a more readable piece of code in Java if you are not into machine language:

   /** Number of combinations
    *  In the case that items > slots this value is items! / (slots! * (items - slots)!) .
    *  Goes up to Choose( 66, 33 ) = 7219428434016265740, the maximum that fits in a long.
    *  This is an optimal implementation that uses factorization to reach the largest exact values possible.
    *  Try Choose( 60, 30 ) in a web-based calculator, for example, and you will not get an exact answer.
    *  This is because naive implementations do not use factorization.
    *  @param items  The count of unique things to be combined.
    *  @param slots  The number of slots or opportunities into which to combine them.
    *  @return number of possible unique combinations or 0 in the event of an error or invalid input or -1 in the event of an overflow
    */
   public final static long combinationCount( int items, int slots ){
      if( items < 1 || slots < 1 ) return 0;
      if( slots > items ) return 0;
      if( slots == items ) return 1;
      int extra = items - slots;
      if( extra > slots ){
         slots = extra;
         extra = items - slots;  // extra always has as many or fewer items than slots
      }
      int[] aiNumeratorFactors = new int[100];
      for( int xNumeratorFactorial = items; xNumeratorFactorial > slots; xNumeratorFactorial-- ){
         int[] factors = factor( xNumeratorFactorial );
         if( factors == null ) return 0; // an error has occurred
         for( int xFactor = 1; xFactor <= factors[0]; xFactor++ ){ // add factors to numerator factors list
            if( aiNumeratorFactors[0] == aiNumeratorFactors.length - 1 ){ // need to expand list
               int[] aiNumeratorFactors_new = new int[aiNumeratorFactors.length * 2];
               System.arraycopy( aiNumeratorFactors, 0, aiNumeratorFactors_new, 0, aiNumeratorFactors.length );
               aiNumeratorFactors = aiNumeratorFactors_new;
            }
            aiNumeratorFactors[0]++;
            aiNumeratorFactors[aiNumeratorFactors[0]] = factors[xFactor];
         }
      }
      int[] aiDenominatorFactors = new int[100];
      for( int xDenominatorFactorial = extra; xDenominatorFactorial > 1; xDenominatorFactorial-- ){
         int[] factors = factor( xDenominatorFactorial );
         if( factors == null ) return 0; // an error has occurred
         for( int xFactor = 1; xFactor <= factors[0]; xFactor++ ){ // add factors to numerator factors list
            if( aiDenominatorFactors[0] == aiDenominatorFactors.length - 1 ){ // need to expand list
               int[] aiDenominatorFactors_new = new int[aiDenominatorFactors.length * 2];
               System.arraycopy( aiDenominatorFactors, 0, aiDenominatorFactors_new, 0, aiDenominatorFactors.length );
               aiDenominatorFactors = aiDenominatorFactors_new;
            }
            aiDenominatorFactors[0]++;
            aiDenominatorFactors[aiDenominatorFactors[0]] = factors[xFactor];
         }
      }
      int[] aiNumeratorFactors_fitted = new int[aiNumeratorFactors[0]];
      System.arraycopy( aiNumeratorFactors, 1, aiNumeratorFactors_fitted, 0, aiNumeratorFactors[0] );
      aiNumeratorFactors = aiNumeratorFactors_fitted;
      int[] aiDenominatorFactors_fitted = new int[aiDenominatorFactors[0]];
      System.arraycopy( aiDenominatorFactors, 1, aiDenominatorFactors_fitted, 0, aiDenominatorFactors[0]);
      aiDenominatorFactors = aiDenominatorFactors_fitted;
      java.util.Arrays.sort( aiNumeratorFactors );
      java.util.Arrays.sort( aiDenominatorFactors );
      long nTotal = 1;
      int xNumerator = 0;
      int xDenominator = 0;
      while( true ){
         if( xNumerator == aiNumeratorFactors.length ) return nTotal;
         if( xDenominator < aiDenominatorFactors.length && aiNumeratorFactors[xNumerator] == aiDenominatorFactors[xDenominator] ){
            xDenominator++;
         } else {
            if( Long.MAX_VALUE / nTotal < aiNumeratorFactors[xNumerator] ) return -1; // overflow
            nTotal *= aiNumeratorFactors[xNumerator];
         }
         xNumerator++;
      }
   }

Snippet war! Everyone post a snippet of what they have written. I will evaluate and declare a winner

While I agree with a few things blinken has to say, this is ridiculous.  The following code should emulate blinken's bloatware.  Complete with returning zero on invalid inputs and returning -1 on overflow.

Code:

#include <stdio.h>
#define MAXLONGLONG 0x7FFFFFFFFFFFFFFF

/* Returns GCD(a, b) using Euclid's algorithm of antiquity */
long int euclid(long unsigned int a, long unsigned int b)
{ return a%b==0 ? b : euclid(b, a%b); }

/* Returns n choose m */
long int combin(long int n, long int m)
{
  long int i;
  long unsigned int N=1;
  long unsigned int D=1;
  if (m+m>n) m=n-m;
  if (m < 0) N=0;
  for (i=0; i<m; i+=1)
  {
    long unsigned int t = euclid(n-i, m-i);
    long unsigned int u = euclid(D, (n-i)/t);
    long unsigned int v = euclid(N, (m-i)/t);
    if (MAXLONGLONG / (N/v) <= (n-i)/t/u) { N=-1; break; }
    N = N/v * ((n-i)/t/u);
    D = D/u * ((m-i)/t/v);
  }
  return N;
}

Here is the test harness:

Code:

void testcombin(long int n, long int m)
{ printf("%ld choose %ld = %ld\n", n, m, combin(n, m)); }

void main(void)
{
  testcombin(2, -1);
  testcombin(2, 3);
  testcombin(6, 0);
  testcombin(6, 2);
  testcombin(10, 7);
  testcombin(15, 7);
  testcombin(63, 30);
  testcombin(66, 33);
  testcombin(121976, 4);
  testcombin(3810778, 3);
  testcombin(4294967295, 2);
  testcombin(4294967296, 2);  // 2^32 choose 2 = 2^63.  One too big.
}

And here is the test output:

Code:

2 choose -1 = 0
2 choose 3 = 0
6 choose 0 = 1
6 choose 2 = 15
10 choose 7 = 120
15 choose 7 = 6435
63 choose 30 = 860778005594247069
66 choose 33 = 7219428434016265740
121976 choose 4 = 9222845730360011050
3810778 choose 3 = 9223364155031292776
4294967295 choose 2 = 9223372030412324865
4294967296 choose 2 = -1

[markm]

So java is bloatware compared to C ? This is news?

Or could the java have been written as concisely without loss of efficiency?

-MarkM-

[Monster Tent]

You dont think that as bitcoin scales the velocity of developer incentives would also scale ?

Or do you envisage a network the size of visa having only 1  dev still being paid from donations ?

[markm]

What, visa has two paid devs?!?! Cheaters! No wonder they're ahead of us. No fair!

-MarkM-

[Blinken]

For such a genius, your code has some pretty glaring inefficiencies to it.  


You could optimize this to a single if statement of the form if(items < 1 || slots < 1 || slots > items) return 0;

      if( items < 1 || slots < 1 ) return 0;
      if( slots > items ) return 0;

Ok, post the code for your factor() method so that I can create a runnable demo.  I will prove to you that I can make your code run faster.

Here is the code for factor:

   /** Factor a number.
    *  Example: 24 will return { 4, 2, 2, 2, 3 } where 4 is the number of factors and 2 x 2 x 2 x 3 = 24
    *  @param iNumberToFactor
    *  @return The factors in a one-based array.

• = count of factors. Null in the event of an error or invalid input.

    */
   public final static int[] factor( int iNumberToFactor ){
      if( iNumberToFactor < 1 ) return null;
      int iCapacity = 100;
      int[] factors = new int[iCapacity + 1];
      int xPrime = -1;
      int iMaxFactor = (int)(java.lang.Math.sqrt( (double)iNumberToFactor )) + 1;
      int iRemainder = iNumberToFactor;
      while( true ){
         xPrime++;
         if( primes[xPrime] > iMaxFactor || primes[xPrime] == iRemainder || iRemainder % primes[xPrime] == 0 ){
            if( factors.length == iCapacity + 1 ){ // expand buffer
               iCapacity *= 2;
               int[] factors_new = new int[iCapacity + 1];
               System.arraycopy( factors, 0, factors_new, 0, factors.length );
               factors = factors_new;
            }
            factors[0]++;
            if( primes[xPrime] > iMaxFactor ){
               factors[factors[0]] = iRemainder;
            } else {
               factors[factors[0]] = primes[xPrime];
            }
            if( primes[xPrime] > iMaxFactor || primes[xPrime] == iRemainder ){
               int[] factors_exact_size = new int[factors[0] + 1];
               System.arraycopy( factors, 0, factors_exact_size, 0, factors[0] + 1);
               return factors_exact_size;
            }
            iRemainder /= primes[xPrime];
            xPrime = -1;
         }
      }
   }


Factor depends on a table of primes which is this:


final public static int[] primes = {
   2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61, 67, 71, 73, 79, 83, 89, 97,
   101, 103, 107, 109, 113, 127, 131, 137, 139, 149, 151, 157, 163, 167, 173, 179, 181, 191, 193, 197, 199, 211, 223, 227, 229,
   233, 239, 241, 251, 257, 263, 269, 271, 277, 281, 283, 293, 307, 311, 313, 317, 331, 337, 347, 349, 353, 359, 367, 373, 379,
   383, 389, 397, 401, 409, 419, 421, 431, 433, 439, 443, 449, 457, 461, 463, 467, 479, 487, 491, 499, 503, 509, 521, 523, 541,
.....
   49667, 49669, 49681, 49697, 49711, 49727, 49739, 49741, 49747, 49757, 49783, 49787, 49789, 49801, 49807, 49811, 49823, 49831, 49843, 49853, 49871, 49877, 49891, 49919, 49921,
   49927, 49937, 49939, 49943, 49957, 49991, 49993, 49999 };   
}

I have not included the entire table because it is large, but you can easily fill in the missing values yourself from online sources.

[Blinken]

The Fed doesn't pay me enough to put up with this, but ok... here is byte code for x86 that translates either a decimal or hexadecimal string to a binary value (yes, I actually wrote the byte code, and yes, I can read and write x86 machine encodings in hex):

31C053515657555231F68A0280F8307C1080F8397F0B2C3083C6015083C201EBE9C7C50A000000C 7C10100000031DB89F783FE00741058F7E101C383EE0189C8F7E589C1EBEB89D85A01FA5D5F5E59 5BC331C053515657555231F68A0280F8307C0980F8397F042C30EB0C80F8417C1080F8467F0B2C4 B83C6015083C201EBDBC7C510000000EB9F

The decimal reader is at offset 0 and expects a non-digit terminated string at an address in the EDX register. The hex reader is at offset 136 and expects the same input. Both routines return the answer in EAX register. Total bytes: 136.
While I agree with a few things blinken has to say, this is ridiculous.  The following code should emulate blinken's bloatware.  Complete with returning zero on invalid inputs and returning -1 on overflow.

Code:

#include <stdio.h>
#define MAXLONGLONG 0x7FFFFFFFFFFFFFFF

/* Returns GCD(a, b) using Euclid's algorithm of antiquity */
long int euclid(long unsigned int a, long unsigned int b)
{ return a%b==0 ? b : euclid(b, a%b); }

/* Returns n choose m */
long int combin(long int n, long int m)
{
  long int i;
  long unsigned int N=1;
  long unsigned int D=1;
  if (m+m>n) m=n-m;
  if (m < 0) N=0;
  for (i=0; i<m; i+=1)
  {
    long unsigned int t = euclid(n-i, m-i);
    long unsigned int u = euclid(D, (n-i)/t);
    long unsigned int v = euclid(N, (m-i)/t);
    if (MAXLONGLONG / (N/v) <= (n-i)/t/u) { N=-1; break; }
    N = N/v * ((n-i)/t/u);
    D = D/u * ((m-i)/t/v);
  }
  return N;
}

Here is the test harness:

Code:

void testcombin(long int n, long int m)
{ printf("%ld choose %ld = %ld\n", n, m, combin(n, m)); }

void main(void)
{
  testcombin(2, -1);
  testcombin(2, 3);
  testcombin(6, 0);
  testcombin(6, 2);
  testcombin(10, 7);
  testcombin(15, 7);
  testcombin(63, 30);
  testcombin(66, 33);
  testcombin(121976, 4);
  testcombin(3810778, 3);
  testcombin(4294967295, 2);
  testcombin(4294967296, 2);  // 2^32 choose 2 = 2^63.  One too big.
}

And here is the test output:

Code:

2 choose -1 = 0
2 choose 3 = 0
6 choose 0 = 1
6 choose 2 = 15
10 choose 7 = 120
15 choose 7 = 6435
63 choose 30 = 860778005594247069
66 choose 33 = 7219428434016265740
121976 choose 4 = 9222845730360011050
3810778 choose 3 = 9223364155031292776
4294967295 choose 2 = 9223372030412324865
4294967296 choose 2 = -1

That is very good. I did not think of using Euclid's algorithm. I should send you a bitcoin for that one.