Test net nodes: please update to 0.8.6, and delete your old blockchain.
done for
testnxt-*.cloudapp.net
Topic: NXT :: descendant of Bitcoin - Updated Information - page 513. (Read 2761624 times)
done for
testnxt-*.cloudapp.net
BTC38 is asking about which coin to add next on their exchange. Please take a few minutes to let them know about Nxt:
https://bitcointalksearch.org/topic/m.5525645
voted,https://bitcointalksearch.org/topic/m.5525645
have broadcast this news to all Chinese group.
Is JL available for new dev core team consideration post CFB?
My understanding is that he is here long term jean-luc
If you can get asset trades denominated in other assets implemented, then NXT AE would be able to dominate all other centralized exchanges. Basically all cryptos supported by the gateway could be directly traded against any other crypto. It would be fantastic!
After trading, people could withdraw directly to their wallet whatever crypto they have assets for
I think this is a much bigger change than assets supporting fractions, but maybe its a conditional handling in Order.java for all the trades of an asset denominated in another asset. Even if BTC is the only other asset something can be denominated in, that would get us 90% of the benefit, but I think the way the code is structured, it would be almost the same work to allow arbitrary denominations based in other assets.
James
If you can get asset trades denominated in other assets implemented, then NXT AE would be able to dominate all other centralized exchanges. Basically all cryptos supported by the gateway could be directly traded against any other crypto. It would be fantastic!
After trading, people could withdraw directly to their wallet whatever crypto they have assets for
I think this is a much bigger change than assets supporting fractions, but maybe its a conditional handling in Order.java for all the trades of an asset denominated in another asset. Even if BTC is the only other asset something can be denominated in, that would get us 90% of the benefit, but I think the way the code is structured, it would be almost the same work to allow arbitrary denominations based in other assets.
James
I'm a little unclear on this, so apologies if my understanding is flawed.
Could this be done atomically with chained transactions?
For example:
BTC -> NXT && NXT -> LTC
BTC -> NXT && NXT -> DOGE
etc...
Everything would be converted to NXT as intermediate hold, then immediately used to purchase the new asset. If chained transactions can apply with atomicity, then goal is achieved.
Direct trading gives us the best advantage, well actually, it makes us the same as the exchanges as far as trading pairs
Is JL available for new dev core team consideration post CFB?
As I said, I will approach the candidates once we have some names and know how the newcomers would be able to contribute.
Who is going to conduct the technical interviews?
good question we are decentralized, but I think you are the person best placed to do so, at the end you would work toghetter not?
BTW how long will you stay on this project?
Good question. It's about time NXT 'Ground Control' got some attention.
jean-luc
If you can get asset trades denominated in other assets implemented, then NXT AE would be able to dominate all other centralized exchanges. Basically all cryptos supported by the gateway could be directly traded against any other crypto. It would be fantastic!
After trading, people could withdraw directly to their wallet whatever crypto they have assets for
I think this is a much bigger change than assets supporting fractions, but maybe its a conditional handling in Order.java for all the trades of an asset denominated in another asset. Even if BTC is the only other asset something can be denominated in, that would get us 90% of the benefit, but I think the way the code is structured, it would be almost the same work to allow arbitrary denominations based in other assets.
James
If you can get asset trades denominated in other assets implemented, then NXT AE would be able to dominate all other centralized exchanges. Basically all cryptos supported by the gateway could be directly traded against any other crypto. It would be fantastic!
After trading, people could withdraw directly to their wallet whatever crypto they have assets for
I think this is a much bigger change than assets supporting fractions, but maybe its a conditional handling in Order.java for all the trades of an asset denominated in another asset. Even if BTC is the only other asset something can be denominated in, that would get us 90% of the benefit, but I think the way the code is structured, it would be almost the same work to allow arbitrary denominations based in other assets.
James
http://www.reddit.com/r/CryptoCurrency/comments/1zo234/i_am_doing_some_research_and_would_like_to_hear/
A guy is asking for
A guy is asking for
Quote
"I hope to be able to compare Ripple, Ethereum, Mastercoin, NXT and Coloured Coins - what features they offer, what advantages they have over one another, what are the drawbacks to various approaches taken and so forth.
I would like to know your opinion on what are the strengths and weaknesses of the above mentioned systems. Why do you think one is better than the other? Which one will be the one most widely used and why?"
Not very important, but still a good training I would like to know your opinion on what are the strengths and weaknesses of the above mentioned systems. Why do you think one is better than the other? Which one will be the one most widely used and why?"
Looking at making Assets support fractions, I think it is a matter of changing:
quantity = Integer.parseInt(quantityValue); -> parseLong
and making Nxt.MAX_ASSET_QUANTITY multiplied by 100000000
IssueAsset.java, PlaceBidOrder.java, PlaceAskOrder.java and TransferAsset.java seem to be the only places that needs to be changed other than Order.java lines 69 to 71:
private volatile int quantity;
private Order(Long id, Account account, Long assetId, int quantity, long price) {
just need to change the int to a long
There might be a few other places as I have only just now started looking at this code, but I dont think getting fractional assets will be that hard at all. We would need to change the client code to multiply everything by 100000000, but I think it is worth doing to get support for fractional assets in AE
quantity = Integer.parseInt(quantityValue); -> parseLong
and making Nxt.MAX_ASSET_QUANTITY multiplied by 100000000
IssueAsset.java, PlaceBidOrder.java, PlaceAskOrder.java and TransferAsset.java seem to be the only places that needs to be changed other than Order.java lines 69 to 71:
private volatile int quantity;
private Order(Long id, Account account, Long assetId, int quantity, long price) {
just need to change the int to a long
There might be a few other places as I have only just now started looking at this code, but I dont think getting fractional assets will be that hard at all. We would need to change the client code to multiply everything by 100000000, but I think it is worth doing to get support for fractional assets in AE
Wait, I at first thought you were talking about fractional prices which is what I am busy thinking about. You mean fractional asset quantities? Why is that even necessary?
Down the road when we want to support direct swapping of BTC with DOGE, we can specify in the order that it is to be denominated in an asset instead of NXT. Prices would definitely need fractions, and that means assets need fractions
James
TF
Still thinking about this transparency aka determinism part... and reviewing mthcl's paper draft.
Looking at making Assets support fractions, I think it is a matter of changing:
quantity = Integer.parseInt(quantityValue); -> parseLong
and making Nxt.MAX_ASSET_QUANTITY multiplied by 100000000
IssueAsset.java, PlaceBidOrder.java, PlaceAskOrder.java and TransferAsset.java seem to be the only places that needs to be changed other than Order.java lines 69 to 71:
private volatile int quantity;
private Order(Long id, Account account, Long assetId, int quantity, long price) {
just need to change the int to a long
There might be a few other places as I have only just now started looking at this code, but I dont think getting fractional assets will be that hard at all. We would need to change the client code to multiply everything by 100000000, but I think it is worth doing to get support for fractional assets in AE
James
quantity = Integer.parseInt(quantityValue); -> parseLong
and making Nxt.MAX_ASSET_QUANTITY multiplied by 100000000
IssueAsset.java, PlaceBidOrder.java, PlaceAskOrder.java and TransferAsset.java seem to be the only places that needs to be changed other than Order.java lines 69 to 71:
private volatile int quantity;
private Order(Long id, Account account, Long assetId, int quantity, long price) {
just need to change the int to a long
There might be a few other places as I have only just now started looking at this code, but I dont think getting fractional assets will be that hard at all. We would need to change the client code to multiply everything by 100000000, but I think it is worth doing to get support for fractional assets in AE
James
When I do it next week you will be able to see how much more complicated it is.
I am really scared what would happen if I just let people make changes in the code thinking they understand it... better sell my Nxt first.
Strong quality controls on released code should be addressed. Accepting any random patch will lead to the destruction of NXT very quickly.
For example, the Bitcoin development process:
https://en.bitcoin.it/wiki/Development_process
And, another example -- the lengthy process of getting a Linux kernel patch approved:
https://www.kernel.org/doc/Documentation/SubmittingPatches
Now, I don't think we need anything that convoluted for NXT. But, a knowledgeable gatekeeper will be needed at first to ensure the quality of the core.
Could that be you, Jean-Luc?
I would help to put together a team with the required skillset. You are the lead developer. Would you like to have a team?
Looking at making Assets support fractions, I think it is a matter of changing:
quantity = Integer.parseInt(quantityValue); -> parseLong
and making Nxt.MAX_ASSET_QUANTITY multiplied by 100000000
IssueAsset.java, PlaceBidOrder.java, PlaceAskOrder.java and TransferAsset.java seem to be the only places that needs to be changed other than Order.java lines 69 to 71:
private volatile int quantity;
private Order(Long id, Account account, Long assetId, int quantity, long price) {
just need to change the int to a long
There might be a few other places as I have only just now started looking at this code, but I dont think getting fractional assets will be that hard at all. We would need to change the client code to multiply everything by 100000000, but I think it is worth doing to get support for fractional assets in AE
quantity = Integer.parseInt(quantityValue); -> parseLong
and making Nxt.MAX_ASSET_QUANTITY multiplied by 100000000
IssueAsset.java, PlaceBidOrder.java, PlaceAskOrder.java and TransferAsset.java seem to be the only places that needs to be changed other than Order.java lines 69 to 71:
private volatile int quantity;
private Order(Long id, Account account, Long assetId, int quantity, long price) {
just need to change the int to a long
There might be a few other places as I have only just now started looking at this code, but I dont think getting fractional assets will be that hard at all. We would need to change the client code to multiply everything by 100000000, but I think it is worth doing to get support for fractional assets in AE
Wait, I at first thought you were talking about fractional prices which is what I am busy thinking about. You mean fractional asset quantities? Why is that even necessary?
As I said, I will approach the candidates once we have some names and know how the newcomers would be able to contribute.
Who is going to conduct the technical interviews?
That was my question number one.
I wrote you a pm, could you please find some time to have a look at it?
I was looking forward to Pooled Forging for one very simple reason: To forge on a VPS without exposing the private key to my primary NXT account...
am I the only one who thinks forging on a VPS is a bad idea?
I completely agree with you. I don't currently forge on a VPS and will not unless I can do so safely.
Did you read my proposal? In example case would only put 10 NXT at risk, but forging on behalf of 185,010.
And, the 10 NXT probably not even necessary...
Basically pooled forging would just be for personal use and not intended for different people to pool. Now, if the API for this had a destination acct for any fees earned, then the security of the 10 NXT forging acct is not that important. It could even be done on a webwallet acct. The restriction is that all destination accts have to be the same.
This way, nobody exposes their password on a VPS, but everybody can forge with 100% of their NXT all the time as long as the webwallet site enables forging for all the accts.
James
Yes, I posted the exact same thing a few pages ago. I think we should implement Pool forging, it's new and unique and would be useful when we have full TF capabilities, so why no implement now.
TF
Looking at making Assets support fractions, I think it is a matter of changing:
quantity = Integer.parseInt(quantityValue); -> parseLong
and making Nxt.MAX_ASSET_QUANTITY multiplied by 100000000
IssueAsset.java, PlaceBidOrder.java, PlaceAskOrder.java and TransferAsset.java seem to be the only places that needs to be changed other than Order.java lines 69 to 71:
private volatile int quantity;
private Order(Long id, Account account, Long assetId, int quantity, long price) {
just need to change the int to a long
There might be a few other places as I have only just now started looking at this code, but I dont think getting fractional assets will be that hard at all. We would need to change the client code to multiply everything by 100000000, but I think it is worth doing to get support for fractional assets in AE
James
quantity = Integer.parseInt(quantityValue); -> parseLong
and making Nxt.MAX_ASSET_QUANTITY multiplied by 100000000
IssueAsset.java, PlaceBidOrder.java, PlaceAskOrder.java and TransferAsset.java seem to be the only places that needs to be changed other than Order.java lines 69 to 71:
private volatile int quantity;
private Order(Long id, Account account, Long assetId, int quantity, long price) {
just need to change the int to a long
There might be a few other places as I have only just now started looking at this code, but I dont think getting fractional assets will be that hard at all. We would need to change the client code to multiply everything by 100000000, but I think it is worth doing to get support for fractional assets in AE
James
When I do it next week you will be able to see how much more complicated it is.
I am really scared what would happen if I just let people make changes in the code thinking they understand it... better sell my Nxt first.
I must say, just having everything so organized makes it a lot more understandable than when it was all in one file.
James
Edit: by the way, my statement about not being that hard was in reference to you doing it. unlike with NXT cents inconsistent treatment, Asset quantity seems to be universally the same and relatively isolated in the code
Do we have new nxt infographic(some pictures, logo) ?
As I said, I will approach the candidates once we have some names and know how the newcomers would be able to contribute.
Who is going to conduct the technical interviews?
good question we are decentralized, but I think you are the person best placed to do so, at the end you would work toghetter not?
BTW how long will you stay on this project?
Since its just a few lines change, i was hoping I could get some personal feedback on it
Ur lines is not enough. Changes in other parts r necessary.
If you can also add comments to the other asset functions, that will allow for non-forking updates with the feature to denominate trades in terms of another asset. That also requires supporting fractions for assets,which seems messier, but "quantity" seems to be the only int around so maybe not so bad of a change?
James
As I said, I will approach the candidates once we have some names and know how the newcomers would be able to contribute.
Who is going to conduct the technical interviews?
Jump to: