NXT :: descendant of Bitcoin - Updated Information

[Jean-Luc]

So, we would need a new version for blocks?

Of course not. If we do it on test net, we cut off the old test net blockchain before the first no longer valid block.

[1714150924]

1714150924

[ChuckOne]

What do we need to get to 1440 blocks per day?

http://87.230.14.1/nxt/nxt.cgi?action=40&sub=7

[pinarello]

CORE DEV TEAM

Some questions:

1, How could one join? Whom to contact?

NXTtechDEV team when installed imo

2, Are there any candidates?

Not that we know of.


3, Do we have a bounty for them? Unclaimed coins or should we put together some Nxt for this?

Yes from unclaimed coins, when no more unclaimed coins fundraising

My candidate for joining the dev team is CIYAM.

Does Ciyam wants this himself did you ask?

I have also contacted Jean-Luc and am now awaiting his answer.
When we know whom to contact in order to get the core dev team together and we have the candidates, I will contact them one by one asking them if they would be interested.

AFAIK there is only Jean-Luc actively working on the core. Am I right?

right.

[ChuckOne]

So, we would need a new version for blocks?

Of course not. If we do it on test net, we cut off the old test net blockchain before the first no longer valid block.

For sure. I was talking about the real net.

[mcjavar]

CORE DEV TEAM

Some questions:

1, How could one join? Whom to contact?

NXTtechDEV team when installed imo

2, Are there any candidates?

Not that we know of.


3, Do we have a bounty for them? Unclaimed coins or should we put together some Nxt for this?

Yes from unclaimed coins, when no more unclaimed coins fundraising

My candidate for joining the dev team is CIYAM.

Does Ciyam wants this himself did you ask?

I have also contacted Jean-Luc and am now awaiting his answer.
When we know whom to contact in order to get the core dev team together and we have the candidates, I will contact them one by one asking them if they would be interested.

AFAIK there is only Jean-Luc actively working on the core. Am I right?

right.

As I said, I will approach the candidates once we have some names and know how the newcomers would be able to contribute.

[Jean-Luc]

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

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.

[jl777]

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.

Attachment.java needs changes too:

    public static class ColoredCoinsAssetTransfer implements Attachment, Serializable
line 400:
       private final int quantity;

        public ColoredCoinsAssetTransfer(Long assetId, int quantity) {

            this.assetId = assetId;
            this.quantity = quantity;

        }

needs to be:
       private final String comment;
       private final int quantity;

        public ColoredCoinsAssetTransfer(Long assetId, int quantity, String comment) {

            this.assetId = assetId;
            this.quantity = quantity;
            this.comment = comment == null ? "" : comment;

        }

Did I miss anything else?

James

P.S. changing quantity to satoshis seems to have a bunch of ints all over the place that needs changing, but I dont see anything structural that needs to be changed.

[Jean-Luc]

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?

[jl777]

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.

Yes. The byte representation of asset transfer attachment does not expect a comment at the end. If we decide asset transfer need comments, this will have to be added to all asset transfers, and existing ones invalidated, so blocks containing old asset transfers on test net will not be accepted by new code and a fork will form. This is testnet only, so it is doable, but wouldn't be possible if AE was already live.

PLEASE add this. It is critically important to a lot of gateway features.

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

[pinarello]

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?

[S3MKi]

Do we have new nxt infographic(some pictures, logo) ?

[jl777]

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

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.

This is why I just posted here and not formal pull request. Java is not my language so everything is fuzzy, but it is similar enough to C that I can understand kind of what is going on.

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

[Come-from-Beyond]

What do we need to get to 1440 blocks per day?

http://87.230.14.1/nxt/nxt.cgi?action=40&sub=7

TF

[msin]

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...

Maybe this is the ONLY use case for pooled forging. It is for letting people split their NXT into a bunch of accts to minimize any damage losing a single account would cause. Then then can create a forging acct even on some public shared server, but only risking 10 NXT.

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.

[mcjavar]

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?

[Jean-Luc]

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

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?

[mcjavar]

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

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?

[ChuckOne]

What do we need to get to 1440 blocks per day?

http://87.230.14.1/nxt/nxt.cgi?action=40&sub=7

TF

Still thinking about this transparency aka determinism part... and reviewing mthcl's paper draft.

[jl777]

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

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?

For instance, somebody deposits 1.345 DOGE. right now I have to issue 1 DOGE asset and 345 milliDOGE assets. Very klunky and confusing. With BTC asset, we will have to go to microBTC. Yuk!

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

[salsacz]

http://www.reddit.com/r/CryptoCurrency/comments/1zo234/i_am_doing_some_research_and_would_like_to_hear/

A guy is asking for

"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