Nxt Forum

Please login or register.

Login with username, password and session length
Advanced search  

News:

Latest Nxt Client 1.11.10 - NEW RELEASE: Ardor 2.0.6e TestNet - The Ignis ICO is over!! Ardor genesis snapshots will happen in the last week of December

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - cc001

Pages: [1] 2 3 ... 42
1
Hey guys,

We are already in the works of launching SAE  2.0 (old stuff, new front end, added features).
I'll try and see if we can sustain adding this too to the project. If its only server issues, I am glad to host this for you.
Please do let me know if there's space for any sort of collaboration.

Regards

first rule of Nxt: never do business with Freebieservers  :o

2
Core Development Discussion / Re: Nxt 2.0 design
« on: February 23, 2016, 07:30:38 am »
If 1Gb blochain takes 24 hours to download

hm?? It indeed looks to me that some numbers and assumptions are a bit unrealistic..?

1. after 2 years of Nxt, our blockchain is 1-2 GB, in one year it should be 43GB? taking into account that we have less and less volume and transactions that doesn't look like a very accurate prediction to me.
2. 24 hours to download 1Gb? Theoretically, a 50mbit line downloads 1GB in 3min. even if you get only 10% it takes only 30min. Why 24h?
3. 100tx/min is about current bitcoin load. Bitcoin, with 6 years of network-effect-boosted growth. With current Nxt growth speed, it will take years until we reach such values.

It sounds a bit like the 1000tx/s talks in the early Nxt days...

On what assumptions do you base those numbers?

3
Core Development Discussion / Re: PoS Algorithm
« on: February 19, 2016, 10:14:03 pm »
and I'm not saying Caspar is better
I had a feeling that this is exactly what you where implying, but good, since it is not.

Can you explain why it is not better? I'd like to discuss and understand the pros and cons of the algos, based on facts. Not just a simple statement, based on some gut feeling ;)

4
Core Development Discussion / Re: PoS Algorithm
« on: February 19, 2016, 08:19:23 pm »
Why would I not use some of my stake to gain stake, ooh yeah, cause I could lose it all by getting DDos ed a few times, just when I am about to forge.

The main goal of forging is to keep the network safe. The network is the most safe if there are a lot of honest forgers and no dishonest forgers. so, the main goal for an algorithm must be to attract honest forgers and discourage dishonest forgers.
You don't have to forge if you don't want to. But there are people who are willing to forge and who are willing to install some measurements to protect their nodes from failures and ddoses and what ever.

Quote
It is not cause ether dwarves nxt in marketing that their coin architecture ideas are better.
It's not about marketing or hype, I want to talk and think about the algorithm (and I'm not saying Caspar is better)

5
Core Development Discussion / Re: PoS Algorithm
« on: February 19, 2016, 07:33:09 pm »
I would not like the idea that all of my investment could be confiscated just because I had something else to focus on in real life...  :o

Not all, just the amount you are willing to risk to forge with.

I'm not sure yet if it doesn't have tendency to become centralized because only a few are able or willing to implement a lot of security stuff to make sure that their node is always online, that their generated blocks are correct, etc..., to protect their deposit.
On the other side, I think it would be possible to use dynamic parameters (for example the percentage you lose if you are dishonest, or in other words the risk you take) that could control the amount of forgers pretty accurate (by market equilibriums, similar to the difficulty-adjustment-algorithm in bitcoin). I think this way it would be possible to have always 1000 forgers, or for example 1% forgers of all nodes.

6
Core Development Discussion / PoS Algorithm
« on: February 19, 2016, 07:07:48 pm »
On the Daily Decrypt is an interesting interview with the developer of Caspar, the PoS Algorithm of Ethereum:
https://www.youtube.com/watch?v=StMBdBfwn8c

I try to summarize the main difference to our PoS algo from a non-expert-view. Correct me if I'm wrong:
In Caspar you can't just forge with all of your stake just "for free", but you have to make a deposit (the size of it it up to you). This deposit can be lost if you're dishonest or if you don't forge at all (being offline, etc...). Meaning, the bigger the deposit you make, the higher your incentive to forge honest and make sure that your node stays online, the hardware does no fail, etc... Or in other words, it gets really expensive to be dishonest. You do not only have to buy a big stake (as it is in Nxt), but you can lose it all (which is not the case in Nxt)

So, what to the experts out there think about caspar?
What are the differences between Caspar and the PoS Algo in Nxt?
Do they have good ideas we could borrow? (->Nxt2.0 fNXT?)
Maybe our algo is too simple, and doesn't give enough incentive to be a "really good forger"?

7
General Discussion / Re: How would you like the client to look
« on: February 19, 2016, 03:47:41 pm »
how do you think the NXT client should look to make it easier/friendlier?
I like the idea to have a simple beginner mode for new users which should be very easy to use, and show only very basic features. The advanced mode could have the possibility to show/hide separate features (configurable with some kind of a checkbox list).

Another improvement would be if all the complicated entry forms (for example the creation of a new MS Currency) could be hidden behind a "Usecase-Layer". So, the user would simply select "Create new crowdfunding", and define some basic crowdfunding parameters (target, time, etc...). In the background, the system would automatically create a new MS Currency with the correct parameters. Additionally, for advanced users, we could let the system show the prepopulated "Create new MS Currency"-mask, maybe the advanced user would want to adjust some parameters.

This means the UI would be more UseCase-centric, instead of being feature-centric. The use case layer could even integrate multiple different features "behind the scene", for example create a new MS Currency for voting, create the poll and distribute the newly created currency tokens to specific asset holders. Everything hidden behind a "Create new poll for asset holders"-layer.
May be difficult to implement, but would make all the features much more useful and more easy to use.

Quote
I'm wondering what if JLP works towards the 2.0 scalability while NXT 1.8 and/or 1.9 has user friendliness improvements.
Sounds good to me!

8
Core Development Discussion / Re: Nxt 2.0 design
« on: February 18, 2016, 09:36:16 pm »
Meanwhile http://www.coindesk.com/researchers-redesign-scaling-decentralized-blockchains/
"... The increasing popularity of bitcoin as a digital currency has made scalability a "primary and urgent concern" for the bitcoin network, the authors say, touching upon a topic that has been hotly debated for months in the bitcoin space."

yes, but Bitcoin has 100 times more transactions per day. If we don't find new users we will never need to think about scalability. even if we get traction, it will take a long time until scalability is a "primary and urgend concern" for Nxt. It is ok to think in advance about future problems, but scalability it is not our primary problem right now. It doesn't make sense to build a factory that can produce 100 Lambos [hey Marc ;) ] per day, if you can sell only one per month.

9
Core Development Discussion / Re: Nxt 2.0 design
« on: February 18, 2016, 09:07:31 pm »
I agree, if you ask 'what is the biggest problem nxt has today?' it is adoption. The amount of transactions is only 2000 per day :( Many of the new features (like shuffling, MS) need much more work to get user friendly enough to reach adoption.

Scalability is not our problem today. Finding new users is our challenge.

This! FULL ACK

10
Core Development Discussion / Re: Nxt 2.0 design
« on: February 18, 2016, 02:09:24 pm »
a snapshot from before the 2.0 discussion began makes definitively no sense because it will take at least 1 year until the 2.0 hardfork will happen. 1 year in crypto is like 10 years in "real" markets. You wouldn't want to distribute the assets of a brand new tech product (which is still highly unknown how it will work, how it will look like, and it will not be ready within the next 10 years!) based on the market distribution/situation from before it even has been mentioned, would you?

11
Core Development Discussion / Re: Nxt 2.0 design
« on: February 18, 2016, 12:54:53 pm »
How about we settle this issue like man by ... voting by stake.

I suggest two poles:
A. Timing of snapshot for distribution:
(1) Block 621000 i.e. 1.7 hard fork
(2) Some pre-announced block, say 3 month from now, well ahead of the actual 2.0 fork
(3) 2.0 hard fork

B. Method of distribution:
(1) 1 fNXT for 1 NXT
(2) Like (1) but omit NXT accounts without announced public key
(3) Like (2) but only distribute fNXT to NXT accounts which registered their interest by setting an account property.

I like voting. But lets discuss the polls and the selectable options first, before setting up the polls. Or add at least an option "Something else, check forum".
Maybe a new thread, where you adapt the op post and include the different proposed options to vote on?

12
Core Development Discussion / Re: Nxt 2.0 design
« on: February 18, 2016, 11:48:00 am »
Quote
Do the 1:1 allocation. Base the allocation on a snapshot of Nxt distribution the day before the 2.0 announcement and outline.

I like this idea, we can base the distribution 1:1 on the distribution which existed at the 1.7 fork, block 621000, which serves as a notable milestone from just before the 2.0 discussion started. This would be simple to calculate and validate.
I'd like to get more opinions on this proposal.

I don't like this idea. I think it is not reasonable to take a snapshot of the distribution before a discussion, before everything is defined and clear, and one year, or probably even longer, before something which is not defined yet will be implemented. JL is right that the market should play until the happening.

13
Core Development Discussion / Re: Nxt 2.0 design
« on: February 18, 2016, 11:44:02 am »
If it's a good asset that investors believe in, why will they sell it? Selling means they don't believe in the asset and would sell anyway because the asset is not delivering on the promises.

Good point. The only question is: What will get you more profit/value in the future? The asset or NXT and fNXT. Bad assets will go down, good assets will stay alive.

14
Core Development Discussion / Re: Nxt 2.0 design
« on: February 18, 2016, 10:31:07 am »
What about including the value of assets in the initial fNXT distribution, but with a lower weight?

example (parameter are arguable):
2/3 of all fNXT are distributed according to the NXT holding, meaning 666'666'666 fNXT are distributed to the NXT holders with a 1:2/3 rate.
the other 1/3 of fNXT (333'333'333) are distributed to asset holders in the following way:
We take for example the top 20 assets (rated by volume over the last 30 days, or something more sophisticated). For every holding of such an assets, its value in NXT is calculated. All those NXT-values combined are the stack to which the 1/3 fNXT are distributed evenly.

I see a few debatable points with this approach:
1. do we want to include asset holders somehow into the distribution calculation at all?
2. all parameters (2/3, top 20 assets, etc...)
3. which assets are valid for the distribution? top 20 by what value? fake assets?
4. what is the value of one asset in NXT? For example the average value over the last 20 trades?
5. which accounts holding the valid assets are valid? How to exclude issuer accounts? (maybe count only accounts that hold less than 1/3 of the amount of assets?)

Maybe we could generate a temporary distribution list and give the account holders some time to intervene if they think something is not correct?

I think NXT 2.0 is very deep change, so we could also use a fair amount of time to manage and verify the distribution of fNXT (write scripts, lists, check objections of the account holders, etc...)

15
EvilDave wrote a pretty comprehensive guide to handle the transition. Information in this post and links contained should help you solve any doubts - https://nxtforum.org/nrs-releases/nrs-v1-6-2/msg201497/#msg201497
thx

16
the changelog writes:
Quote
The getAccountTransactions and getAccountTransactionIds APIs have been restricted to always return only the non-phased transactions. Those APIs have also been deprecated and will be removed in 1.6. The getBlockchainTransactions API should be used instead, which has the same behavior but returns both phased and non-phased transactions (by default, unless either phasedOnly or nonPhasedOnly parameters is specified). Do not simply replace getAccountTransactions with getBlockchainTransactions in your client code without an understanding of how phased transactions work and without being prepared to handle them correctly.

so, where can I find some info how to handle them correctly, and how to switch from getAccountTransactionIds to getBlockchainTransactions?
Are simple NXT Transfers and asset-related-transactions (bids, asks, etc...) even affected by this prunable-thing ?

17
Yeah, sad news, sorry guys. Dario does not want to continue the work on the site, and he wants to shut down the server because it costs him quite some money. But I am in talks with him, trying to figure out if (and how) it is possible to take over the project and continue it on another server. He agrees to hand over the code. Maybe it is not too late ;)

cc001: maybe we can work something out via Foundation/TNSSE.

Let's be honest: I LIKED the site.

If we can work something out and you think we can help, let me know (PM or Skype (damelon365))

 :)

Yeah, I liked it too (and still would like it...) and I don't agree with his "nxt dying"-statement (he removed it, btw...).
We can have his code, and I would try to adapt it to 1.7.5, but we need a new server to run it.
I'll contact you when I know more.

18
General Discussion / Re: Price speculation
« on: February 08, 2016, 04:11:42 pm »

19
Yeah, sad news, sorry guys. Dario does not want to continue the work on the site, and he wants to shut down the server because it costs him quite some money. But I am in talks with him, trying to figure out if (and how) it is possible to take over the project and continue it on another server. He agrees to hand over the code. Maybe it is not too late ;)

20
General Discussion / Re: Price speculation
« on: February 02, 2016, 06:28:47 am »
Anyone know if nxtreporting plan to upgrade to 1.7.4+?

yep :)

Pages: [1] 2 3 ... 42