The reason this 15 second period exist is to prevent slighly unsynchronized node to be excluded from the network am i right?
So if Anna send block 15sec too soon. Some nodes will accept it but some other will refuse it because it's >15sec for them?
When you got magic numbers like this that try to fudge timing details, then it is likely the code in entirely wrong and needs some serious analysis or simulation. I wouldn't trust code like this that tries to add some arbitrary delay to fix a fundamental flaw in the distributed algorithm. That is why for asynchronous parallel processes, you better have a good spec. of you'll be forever hunting down bugs. |
|
|
|
Never heard of www.crypto.stKraken is known... they actually discovered a major namecoin flaw. crypto-trade has got a nice site. didn't know they accepted DVC. The problem with these are they are all american exchanges, we need to go international. |
|
|
|
Actually, I'd very much recommend rewriting it completely.
Putting all the essential calculation stuff into a library and making a servlet that just calls the library.
And then make unit tests for every class, every function.
You're dealing with a market cap of 63M$, your users should feel save and should be able to verify that they can feel that way.
Yes, same sentiment here. Make the critical stuff testable too. Gut the entire code base. It's becoming completely unmaintainable at its current form. Let's start from scratch and do this right! http://bitcoin-ng.boards.net/ |
|
|
|
Why not show off how smart you really are, just post some actual logic errors that lead to people losing money? My guess is that you tried to and couldn't find any, so you decided to make a copy of it and call it NGC.
That indeed is an interesting idea. So I wait till every gets fixed and mature. Then I reboot NXT. How do you like that plan? You already said you were going to copy NXT and call it NGC. That is the reason you are here, hoping to find some tidbits that will help your NXT clone. Not a copy, a better version. As it is NXT holders a losing money left and right. Wallets getting hacked, DGEX not returning coins, negative balances etc. |
|
|
|
Well, looks like they indeed are having problems. So I guess Vircurex and Cryptsy for now. How about justcoin (i.e. Norway)? Anyone know of any other international exchange? |
|
|
|
Why not show off how smart you really are, just post some actual logic errors that lead to people losing money? My guess is that you tried to and couldn't find any, so you decided to make a copy of it and call it NGC.
That indeed is an interesting idea. So I wait till every gets fixed and mature. Then I reboot NXT. How do you like that plan? |
|
|
|
Please do not rush in it. IXC has waited for years. It can wait for other two days.
First: it't good we take the time to evaluate how much credible is this exchange. We don't wanna put IXC followers in danger.
Second: consider the volume exchange possible. For example: what is the volume exchanged of DVC and NMC daily?
Third: I do not speak chinese, despite I have a friend of mine speaking quite a good chinese.
Fourth: I don't think chinese is important. Chinese people speak english.
Fifth: if there is one with an authority here is not me. Frictionlesscoin or MarkM do.
Sixth: let's try to take a united decision, well evaluated one.
I'm sure both of You has IXC's best interests at heart. My opinion?
If, if and only if this can be proved to be a serious/decent exchange (not considering momentary problems otherwise we should exclude Vircurex, Criptsy and MtGox too), to have visibility on the chinese market is a great opportunity.
Bter has been around for a while now. I used it once a long time ago. I does not matter if there is any liquidity over there. Typically there is not much. People from mainland or taiwan don't normally speak english. Were did you get that idea? Indians yes, but not chinese. I go for pushing for BTER. |
|
|
|
Do we have enough volume to spread over multiple exchanges without the volume at each being thereby diluted?
One exchange with good liquidity and good rep might be better than a whole bunch of pump and dump exchanges where basically the only activity we'd be likely to see would be the pump and dump people trying to screw around with the exchange rates etc?
-MarkM-
I agree the spreading out to too many exchanges makes liquidity a problem. However, if an exchange gives us access to another international market, then the better. So far, IXC is only traded in North American exchanges. Vircurex (Canada) and Cryptsy (USA). |
|
|
|
BTER has all kinds of problems lately it seems. Such as no withdrawals.
Also it seems to be one of the scam-of-the-day exchanges, do we want to be thought to be just another one of the daily scams?
-MarkM-
Never used it. Thought it was a good start. Any other alternative exchange to start with? Otherwise you MarkM, could you not convince the dvc almoner Unthinkingbit to give bounties for a new exchange: BTC-DVC / BTC-IXC (+ others SHA coins?) This could be in line with your idea to keep them together, mining as well as exchange. We should seriously consider BTER because it is tied to the chinese market. This will give visibility of IXC. Could you folks try to contact them? I heard somewhere that DVC was doing to be listed. BTER has already listed DVC-LTC Why not IXC? Yes. It would be good for them to list us. The visibility with the Chinese is very important. Dexter, can you approach them? Do you know any chinese? |
|
|
|
@Frictionless. I see that you know what you're talking about with regard to programming. In fact, you may very well be a brilliant programmer, but the problem is, no one cares. Why? Because you have taken it upon yourself as a right to criticize but have not contributed anything productive. You haven't earned that right yet. In order to earn the right to be heard you should contribute, even in small amount, not with criticism, but with real productive help. Once you do that then you've earned the right to criticize and others will actually listen to you. As it stands, people just think you are a jerk, and using Simon Crowell, a known jerk, as an example doesn't help your cause. Simon Crowell may be rich and be a star power broker, but I believe he has very few "real" deep long lasting friendships, if any.
You have not gone about this in an effective way. If you had played this right you would have contributed in a huge way and others would have sung your praises and others would have gladly signed up for your next generation plan. In fact they would have become your best sales people and you would have had more folks sign up to help with your development and vision. But as it stands there are only a few willing to help you and your chances of developing a great system are slim to none.
Why would I contribute to what obviously looks like a Ponzi scheme? You all first explain to me why this entire shenanigan is any different from a Ponzi scheme? |
|
|
|
There does seem to be a lot of excessive locking. For example: Transaction transaction = Transaction.getTransaction(buffer);
synchronized (Nxt.transactions) {
transaction.index = ++transactionCounter;
}
In 0.5.0 this looks like: Transaction transaction = Transaction.getTransaction(buffer);
transaction.index = transactionCounter.incrementAndGet();
I am afraid CfB and BCNext may get mad at me, but 0.5.0 relies heavily on the Concurrent API... in your dreams. |
|
|
|
synchronized long getBalance() {
return balance;
}
synchronized long getUnconfirmedBalance() {
return unconfirmedBalance;
}
void addToBalance(long amount) throws Exception {
synchronized (this) {
this.balance += amount;
}
updatePeerWeights();
}
void addToUnconfirmedBalance(long amount) throws Exception {
synchronized (this) {
this.unconfirmedBalance += amount;
}
updateUserUnconfirmedBalance();
}
void addToBalanceAndUnconfirmedBalance(long amount) throws Exception {
synchronized (this) {
this.balance += amount;
this.unconfirmedBalance += amount;
}
updatePeerWeights();
updateUserUnconfirmedBalance();
}
sigh... synchronized (this) ... how ignorant can you get! |
|
|
|
For the people who don't code, this is essentially, "if you see some kind of error, just ignore it."
 Actually not. This is a paradigm heavily used in Erlang. If u tried to recover after an exception or even logged it, u would just consume resources without real profit. No, it's more like, if I see some kind of error, let me keep quiet about it!Can you explain how that would effect the actual functionality of the system. Isn't it the same as someone submitting improperly signed transactions so those should be ignored? You keep bringing up issues with the code but without actual explanations of how those issues are supposed to screw things up. It depends where you put it... it's dangerous in most places though because it doesn't class or report the exception and prevent you from seeing any other bugs that might arise while a function is executing. Basically: "Regardless of the error that arises, keep running and do not report it." http://stackoverflow.com/questions/2416316/why-is-the-catchexception-almost-always-a-bad-ideaIt's what I write when I'm in a rush and don't really care when I get some kind of error so long as the program does more or less what I want it to; ideally you would address it properly, but if you're writing something like a program for something non-critical it doesn't really matter.Yes, maybe NXT handling money is a non-critical application. |
|
|
|
For the people who don't code, this is essentially, "if you see some kind of error, just ignore it."
Actually not. This is a paradigm heavily used in Erlang. If u tried to recover after an exception or even logged it, u would just consume resources without real profit. No, it's more like, if I see some kind of error, let me keep quiet about it!Can you explain how that would effect the actual functionality of the system. Isn't it the same as someone submitting improperly signed transactions so those should be ignored? You keep bringing up issues with the code but without actual explanations of how those issues are supposed to screw things up. It's in over 18 places in the code. Anyway, it is bad practice because if an unexpected error happens (which it always does), you do want to know that something happened. To assume that you can ignore this because you think you know what you are doing is just bad practice. Folks, I don't need to explain to you guys who to write code properly! |
|
|
|
BTER has all kinds of problems lately it seems. Such as no withdrawals.
Also it seems to be one of the scam-of-the-day exchanges, do we want to be thought to be just another one of the daily scams?
-MarkM-
Never used it. Thought it was a good start. Any other alternative exchange to start with? Otherwise you MarkM, could you not convince the dvc almoner Unthinkingbit to give bounties for a new exchange: BTC-DVC / BTC-IXC (+ others SHA coins?) This could be in line with your idea to keep them together, mining as well as exchange. We should seriously consider BTER because it is tied to the chinese market. This will give visibility of IXC. Could you folks try to contact them? I heard somewhere that DVC was doing to be listed. |
|
|
|
For the people who don't code, this is essentially, "if you see some kind of error, just ignore it."
Actually not. This is a paradigm heavily used in Erlang. If u tried to recover after an exception or even logged it, u would just consume resources without real profit. No, it's more like, if I see some kind of error, let me keep quiet about it! |
|
|
|
There does seem to be a lot of excessive locking. For example: Transaction transaction = Transaction.getTransaction(buffer);
synchronized (Nxt.transactions) {
transaction.index = ++transactionCounter;
}
Since all you are really doing is setting a transaction number, you should be using AtomicInteger. This would eliminate the lock completely But, in general, you should consider minimizing the scopes of your locks. For example, here, you're locking the entire transactions array to update a single transaction. It would be better to lock around that specific transaction so as not to block other pieces of code attempting to inspect / edit other transactions. Also, there are a number of places where reader-writer locks are more appropriate than using synchronized (e.g. when dealing users, which should change relatively infrequently). This extra locking can help scalability down the road. Valid points, but there was a special rule set - code must be readable by a novice programmer. Concurrent API is for more experienced programmers. I used Concurrent API in my code a couple of times but I was trying to follow the rule. Maybe you should rephrase that "code must be writable by a novice programmer who has never understood Java concurrent api." So you're saying you made up a rule to hide your ignorance. " Thou shall not use concurrent API because I don't understand it" |
|
|
|
My favorite snippet of code: More than 18 times in the code. Reminds me of all these coin holders who have their head in the sand. |
|
|
|
There does seem to be a lot of excessive locking. For example: Transaction transaction = Transaction.getTransaction(buffer);
synchronized (Nxt.transactions) {
transaction.index = ++transactionCounter;
}
Since all you are really doing is setting a transaction number, you should be using AtomicInteger. This would eliminate the lock completely But, in general, you should consider minimizing the scopes of your locks. For example, here, you're locking the entire transactions array to update a single transaction. It would be better to lock around that specific transaction so as not to block other pieces of code attempting to inspect / edit other transactions. Also, there are a number of places where reader-writer locks are more appropriate than using synchronized (e.g. when dealing users, which should change relatively infrequently). This extra locking can help scalability down the road. Yeah, let's just throw as many synchronized blocks all over the place because we really don't know what we're doing.I would have been impressed if the code didn't use a single synchronized block. That would be an indication of a very well designed system. Sigh. |
|
|
|
My thesis is that the price is going to plateau.
28nm is already near the limit. Moving to 28nm to 20nm might get you like a 25% increase, but not an order of magnitude like going from 55nm to 28nm. AMD GPU for example, the latest generation is like 25% better than the previous.
We are also reaching the limit in power for these machines. If I heard right, the Neptune requires power beyond what residential circuits can handle.
Then you have the cost os the power supplies (which you neglect), these aren't getting cheaper. As you go higher and demand greater efficiencies, they just get more expensive.
So I doubt you'll see folks lowering their prices a lot. In fact you are seeing this now, nobody wants to lower their price to match Cointerra.
It is $3 per GHs now for Cointerra, possibly worse case we are seeing $2 per GHs long term.
Look at GPU from AMD, they've remained relatively constant with barely any improvement in technology in the past 3 years. A 5990 board performs just as well as a R9 290x (2 generations later). You are wrong  Comparisons with GPU's are invalid. People dont buy $500 GPU's because they are profitable (miners aside, but they are a tiny minority). Nor do they stop buying GPU's because they no longer "profitable", so prices and margins are mostly determined by the competition. This is 100% different with bitcoin asics. The first asics could be sold their weight in pure gold, literally (the chips), because they were operationally immensely profitable. Even today bitcoin asics generate FAR more in mining revenue than they cost to operate (ie, electricity/hosting costs). WHich is why you see insane high marginal profits. Thats not going to last. Price per GH will roughly follow price per bitcon / difficulty until you approach marginal cost. Assuming the price of bitcoin doesnt explode next year like it did in the past year, the cost of these asics will collapse just as fast as difficulty goes up. No one will want to pay $3 per GH if difficulty is 50B and estimated break even on the purchase is measured in decades rather than months. So vendors wil have a choice: reduce prices or hardly sell anything at all. Considering right now, these asics command a gross margin thats in the region of 10000%, which do you think is most likely? That they will stop selling, or sell for "only" 5000% margin, until one day, "only" 100% margin? Keep in mind even intel doesnt get 100% gross margins on average. Older bitcoin asics like avalon can already be bought for $5 per chip. These chips are not that much cheaper to produce than 28nm ones. You will be able to buy coincraft A1"s for that price this year. Ok, let's go with the $5 per chip as the floor price. If coincraft chips dive to that, then let's calculate the cost of this kind of system. A single coincraft is 25 GHs, so a 1.25 THs will consume 50 chips. At $5 per chip, that would be $250. Add the power supply at $750. The case, logic board, the embedded processor etc. add $200. Total, $1,200. So we are roughly talking about $1 per GHs. So I going to make this claim, the floor may like be $1 per GHs. It won't be $0.1 per GHs or $0.001 per GHs. |
|
|
|
|
Show Posts
