The only argument I've heard so far for leaving it as-is is because BTC did it that way, and Satoshi knows best. The only other reason I could think of is because it's more complicated code. This can't be an issue with the fact that we're pushing a pretty large update to the wallets soon that will have a change far greater than changing the halving schedule.
I've posted my ideas regarding this on the official forum. No need to repeat it. The new change is needed for chain stability. It adds already complicated code, but that is needed. The problem you describe can be solved with solutions that don't add extra complexity to the code. Like posted on the other forum, your problem is part of a bigger economic problem that has to be tackled any way. Look at our NLG friends. They dropped the reward 10x, because they expected that that would make the price going up. It didn't happen. What did happen was that the price dropped further. To continue: the first drop would be from 12.5 to 6.25 (and according to you the price would almost double, so let's say 20000), then the next drop it goes to 3.125 (and according to you the price would almost double again, 40000), next drop 1.5625 (again almost double of price?, 80000)... now what's the economic logic behind every price increase if the drops become smaller and smaller? As the price increases more and more bag holders would start selling, pushing the price down. This is even without taking into consideration that there would be a healthy Auroracoin economy that would stabilize the price by itself (by providing sufficient liquidity). Finally, it easier to pump the price from 10000 to 20000 than from 40000 to 80000. So, if the first halving is a bit bumpy, the next halvings will have less and less effect as the price would go up.
|
|
|
I'm sorry I came across a bit harsh before. I was getting a little alarmed when hearing you were going to fiddle with the supply In principle the supply will remain untouched. The only exception that I see is implementing Proof of Transaction if the total amount of coins is insufficient for a proper AUR-based economy (undefined yet what that would be).
|
|
|
The first halving of Bitcoin had no measurable effect on the price (the price increase before and after that time could have more be attributed to more people discovering Bitcoin and the fraudulent actions by MtGox at that time. At the block where the halving happened, the price hardly reacted, the largest changes happened with weeks of interval.
If the economy and money supply is healthy enough (the latter is already the case for AUR, the first not so yet), there should be no shock in price. Also, I've had already discussions with the ISX people on measures to stabilize the price on their Icelandic exchange. The price calculations/speculations from Guđmundur (new Icelandic MBA that the foundation had a 5 hour talk with last week) are part of determining strategies for this.
But if people want this discussion (IMHO it is a solution for a problem that does not exist), the official Auroracoin forums is the place to do that.
|
|
|
Hallo allemaal,
Zoals jullie weten heb ik de afgelopen twee jaren veel tijd, moeite en geld in NLG gestopt om dat ik erin geloofde dat NLG een verschil kan maken. Toch zijn er afgelopen week dingen voorgevallen die mij hebben laten besluiten om me helemaal uit de NLG community terug te trekken. NLG is niet meer hetgeen waar ik twee jaar geleden veel potentie in zag.
Ik zal zodra de kans zich voordoet (voornamelijk bij het vervallen van een domein) de diverse projecten die ik nog steeds beheer ontmantelen. Daarnaast zal ik ook geen gestikkerde euro's meer in omloop brengen en de poolserver voor Guldenminer zal offline gaan.
Dit bericht is meer ter informatie en niet een reden om een discussie met mij te openen.
Met vriendelijke groet,
BioMike
|
|
|
Is there already some kind of software ( to convert ISK prices into AUR instantly) developed to make it easy for retailers to accept Aurora coins?
My personally developed PriceAPI does that: http://ercinee.eu/Payment system is also on the planning, but other things need to be done first.
|
|
|
The mining pool (which is GHash.io) has dropped below 50%.
|
|
|
People should be cautious when receiving coins. One miner (AVNY6cjEbr3GRaXeFHrxtzAAsWfn8eg53Y) has >50% hashing power.
I would like to ask the pool owner mining to this address to contact me.
great, 51% is the last thing this coin need I'm developing monitoring software, and noticed this when I started it this morning. While this is something we don't really want, it is currently the reality. That's why I'm giving this warning. I guess it will happen more often in the future. If people want to protect themselves against a double spend attack, people should at least wait for a block found by pools AYovB1fohMrn7FSnVF8iDAJzVQvY7D8ykr or AHA5ib4eehh5Gkonv4ZPMZDz3zTS5wn6X5 (together about 40% hash rate) before confirming a transaction. The first one is my own private pool, the other is AURpool, which is run by LTEX (dev team member). What about the solution Gulden is using to protect them from double spend attacks? Hi...how can a person double spend ? ... I never understood that. thx Question 1: The solution Gulden uses. From what I understood, they checkpoint at each block. This in fact prevents orphaning of the chain, but IMHO also makes the whole chain less flexible. [edit] It is also a centralized solution. [/edit] Question 2: The thing that is important is the chain which provided the most work wins. If someone has 51% mining speed he could send a transaction, start mining in a separate chain (not broadcasted to the real chain), transaction is confirmed (and the transaction is not further looked at), the attacker now broadcasts his longer chain without the initial transaction. He now has 1) his "never send" coins, plus 2) the results of the invalidated transaction (for example funds on an exchange).
|
|
|
People should be cautious when receiving coins. One miner (AVNY6cjEbr3GRaXeFHrxtzAAsWfn8eg53Y) has >50% hashing power.
I would like to ask the pool owner mining to this address to contact me.
great, 51% is the last thing this coin need I'm developing monitoring software, and noticed this when I started it this morning. While this is something we don't really want, it is currently the reality. That's why I'm giving this warning. I guess it will happen more often in the future. If people want to protect themselves against a double spend attack, people should at least wait for a block found by pools AYovB1fohMrn7FSnVF8iDAJzVQvY7D8ykr or AHA5ib4eehh5Gkonv4ZPMZDz3zTS5wn6X5 (together about 40% hash rate) before confirming a transaction. The first one is my own private pool, the other is AURpool, which is run by LTEX (dev team member). wouldn't it be sufficient (or better?) to just wait for some amount of confirmations regardless of the miner? After all: cost to orphan those blocks (by building a parallel longer chain) is the same, no matter who mined it, no? Yes, you are correct. I made a thinking error here. I have to rethink my monitoring software. Thank you for pointing this out.
|
|
|
People should be cautious when receiving coins. One miner (AVNY6cjEbr3GRaXeFHrxtzAAsWfn8eg53Y) has >50% hashing power.
I would like to ask the pool owner mining to this address to contact me.
great, 51% is the last thing this coin need I'm developing monitoring software, and noticed this when I started it this morning. While this is something we don't really want, it is currently the reality. That's why I'm giving this warning. I guess it will happen more often in the future. If people want to protect themselves against a double spend attack, people should at least wait for a block found by pools AYovB1fohMrn7FSnVF8iDAJzVQvY7D8ykr or AHA5ib4eehh5Gkonv4ZPMZDz3zTS5wn6X5 (together about 40% hash rate) before confirming a transaction. The first one is my own private pool, the other is AURpool, which is run by LTEX (dev team member).
|
|
|
People should be cautious when receiving coins. One miner (AVNY6cjEbr3GRaXeFHrxtzAAsWfn8eg53Y) has >50% hashing power.
I would like to ask the pool owner mining to this address to contact me.
|
|
|
Right now on cryptsy there are no open sell orders, even if "AUR depth" is displaying sell orders pending. So...
According to their chat, other coins seem to have such problem as well (so not sure if there is really problem or just no sell orders). My guess was always that the depth chart is buffered (it always lags). See how/if it catches up.
|
|
|
Although it has been speculated on many times that Cryptsy would go Gox (for years now), they are still here and seem to keep providing their service. The trouble, however is that the deposits and withdrawals seem to get harder and harder all the time. So yes, I would also advise to take caution with Cryptsy for now and not leave more than 1BTC in value on there. Bittrex.com is picking up volume fast now, a good alternative if you ask me! Very diplomatic language LTEX. When "providing their service" means to you: "taking double fee", because of sending only halve the amount of coins the customer asked for, transfering only 80% of the coins they substract from your cryptsy balance and these to thefts combined with a customer support that never gives you a clear answer or a refund, then you are 100% right, this is exactly how to discribe what "providing their service" contains at cryptsy. I have paid fees only for the amount which I received. The only thing is that I was not able to use my withdrawal- tickets properly.) This is criminal. Volontary or not, it's the same than a lawyers charging 5h when the real number is 2h. This is criminal - and Crypsy are actually gaming the system to keep slow down withdraw ''run to the bank'' process, while increasing a LOT their fee. As far as I remember the "free withdrawal tickets" are a gift from Cryptsy (Every other exchange just charges withdrawals). Normal withdrawal rates are calculated with what is being paid out. In your example it would be the "first consult would be free", but except having a 3h consult, the lawyer has other things to attend to and terminates the consult after 1.5 h.
|
|
|
Can't wait to have everyone AUR owner out of this trap. Danger zone.
I'm out of crapland. Using bittrex now. Same here.
|
|
|
This afternoon my personal pool had about 35% hashrate. Another jumppool also about 35%, rest was divided among 3-4 other pools. I'm building software to monitor this type of data, so that's why I know.
|
|
|
People using the CEX.IO exchange, please withdraw your AUR, as it will be delisted due to GHash.IO multipool suspension!
|
|
|
Ok "Knab" also reacted that their "financial and customer services have not been adjusted to my type of transactions" and cancelled the account. Next in line is SNS Bank ( http://www.snsbank.nl). I had contact with an other entrepreneur and he said he had no difficulties with them.
|
|
|
@RealBitcoin: I think it is more that they don't understand crypto's or are not bothered by it.
@Cryptology: Yes, that is something I'll try if it doesn't work here in the Netherlands. I do prefer a Dutch bank, because it would be easier communicating with them (my German is not that great).
|
|
|
I'm in the process of starting a cryptocurrency related company (the company exists, but need a business bank account to operate) and had my first block last week when trying to open an account with "ABN-AMRO" (my personal bank) in the Netherlands. Their statement boiled down that they choose to not open new accounts for companies dealing with crypto's. Accounts that were already opened before their policy change could continue to operate. Their policy is however open for change in the future.
Yesterday I opened an account with "Knab" in the Netherlands as well, but it is still under supervision of approval (I also asked an employee through their chat system, but she couldn't tell if it would pass their checks).
|
|
|
I'm proud to announce the initial release of our priceAPI. It provides an easy to use API to obtain the current spot price of Auroracoin in BTC, ISK, EUR and USD. Documentation and links can be found on the following website: http://www.ercinee.eu/Suggestions for improvement are welcome.
|
|
|
|