elective-stereophonic
elective-stereophonic
Show Posts - Jetboy  
Please login or register.

Login with username, password and session length
Advanced search  

News:

Latest Stable Nxt Client: Nxt 1.12.2

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

Pages: [1] 2 3
1
LIQUID / Re: Dividend Day!
« on: March 03, 2016, 11:46:35 am »
February 2016 Profits Paid

Assets: 324,536
Capital: 8,658,347
ROI: 16.38%
Total Profit: 2,210,160
Divs Paid: 1,436,604
Div/Asset: 4.427

This month has been a bit of a mixed bag.  The bot code has been trading very well all month. Unfortunately, first week of February during testing it, I entered a very large trade which went against me.  Mike and I worked on this for a few weeks to try to see a way out of it, but we couldn't quite get it done.  Last week we decided to close it and take the loss rather than risk the entire fund.

The balance sheet is correct now and accounts for this loss.  I still decided to pay the almost 1.5M in dividends because those were bot profits. However, I will be moving the Div % back to 50 to start building capital again.

I'm still optimistic going forward, but as you can imagine this loss hit us both pretty hard, many sleepless nights.  I'm hoping that ETH and MAID will continue their high volume to allow us to recover it soon.  I still consider LQD a buy and will be using half of my divs to accumulate more shares to those investors who would like to sell.

LibertyNow

Thanks for coming around with a story (at least) and of course the dividends.

I suggest you organise a vote on wether there should be any dividends paid for a while. If the losses are not covered in any other way very quickly, it makes much more financial sense to retain all profits to rebuild the capital base quicker.

I for one would rather you compound and restore to february standards (which were very good) than getting measly payouts.

Br,

2
Core Development Discussion / Re: Nxt 2.0 design
« on: February 24, 2016, 03:12:33 pm »
JLP: I need some time to reconsider as I didn't understand yet that the account will be global.

Also, I need to reformulate into clean requirements rather than, as you point out, implementation fuzz.

3
Core Development Discussion / Re: Nxt 2.0 design
« on: February 24, 2016, 01:39:31 pm »
If the default is not to prune the NXT child chain, most people will not change the default and this will ensure enough archival copies. Besides, users will prefer to keep their own transaction records available, which for most would be on the NXT child chain, this is a good reason for them not to prune it. The blockchain download time will still improve a lot, even if by default those old transactions will not be pruned, because they don't need to be processed, only downloaded and saved. A new node will first download the fNXT chain only, verifying transactions on it and forgers' effective balances, then once it is up to date download the latest state snapshot, verifying its hash as published in the fNXT chain, and then start downloading the missing prunable transactions from the NXT child chain, but it only needs to verify their hashes, not actually execute any account balance changes or modify derived objects based on them. This download will happen in the background, like the download of prunable messages and tagged data happens now, the node already being fully functional.

It is only when we have high transaction volume and the difference in size between pruned and non-pruned blockchain becomes substantial that people will actively start changing the default to prune. If we get there, it means we are already successful, it will be a good problem to have, and then we can think about some financial motivation for people to run archival nodes.

Ok, Jean-Luc. If we even punish "child pruners" a little, I completely agree that this is swiftly becoming a non issue for a long time. Again, we need a very high probability of a large full archive population within the children.

I'm overstating the point because a lot of decision makers around the world are more than anything looking to derisk as much as possible. Keeping the envelope as small as possible in a transaprent and easy way really helps.

4
Core Development Discussion / Re: Nxt 2.0 child chain tokens pegged to fNXT
« on: February 24, 2016, 01:28:21 pm »
This looks a bit like my proposal:

https://nxtforum.org/index.php?topic=10828.msg210728#msg210728

Essentially, NXT tokens will gradually migrate into the parent chain where it will be "locked" and used for forging. On existing NXT, the total amount of NXT and the new native token will always equal to 1B minus burn. NXT will cease to be a settlement token. After a grace period, remaining NXT on the special child (which we now call NXT) are simply converted into a tradable asset (which can be "exchanged" into new native currency by sending it to the mother chain).

There is no pegging, just a 1:1 swap where any transfer of NXT into the main chain will yield the same amount back in the new currency.

In effect, we inflate the total economy in total amount of tokens but, it happens in a predictable and gradular process where market forces can play themselves out without crashing the sound part of the AE econonomy. This is not a problem because NXT 2.0 will have expanded the total value of the system as well.

We don't even need to to code all this (only the "locking" of NXT on the parent chain). It would be an excellent use case for Ethereum and probably great exhibit of NXT as well.

5
Core Development Discussion / Re: Nxt 2.0 design
« on: February 24, 2016, 12:37:14 pm »
There is no connection between forging accounts and nodes. In fact, a lot of effort has gone into making it hard to determine on which node (IP address) a forger is forging. Therefore such a restriction, requiring the forger to run an archival node, cannot be enforced.

Aye, that makes great sense. But rather than leaving archiving to chance and good humour, we should seek to encourage it such that the probability of a fine archival population is high. Certainly you would find that interests which have something valuable to protect will carry the cost of running one but, there is also the "everybody else will fix this problem" effect seen when someone dies on the street with noone helping: Collective disassociation of responsibility.

Also, a low number of nodes could be subjected to banal attacks where resilience would increase with number.

6
Anyway, having 13,328,411 NXT minable by brute force is an excellent honeypot. Keep those accounts under surveillance and we have a better chance to react to unforeseen vectors.
There is no way to tell if any have been mined by brute force or not. And even if there were, there is nothing that can be done. We are not a centralized system.

It is rather likely you would see relative dramatic activity on the account population if they were subject to a brute mine. They could be worth monitoring.

7
Let's look at actual numbers, how many accounts currently have non-zero NXT balance, and how many of them have or do not have public keys announced:

Code: [Select]
> select count(*), sum(account.balance)/100000000 from account, public_key where account.latest=true and public_key.latest=true and account.id = public_key.account_id and public_key.public_key is null and account.balance > 0
COUNT(*) | SUM(ACCOUNT.BALANCE) / 100000000
18558    | 13328411.78690082
(1 row, 561 ms)

> select count(*), sum(account.balance)/100000000 from account, public_key where account.latest=true and public_key.latest=true and account.id = public_key.account_id and public_key.public_key is not null and account.balance > 0
COUNT(*) | SUM(ACCOUNT.BALANCE) / 100000000
26559    | 986655806.10675888
(1 row, 469 ms)

So we have 18,558 accounts without public keys, holding a total of 13,328,411 NXT, and 26,559 accounts with public keys, holding a total of 986,655,806 NXT.

The number of accounts without public keys is disturbingly high, and it is also a large amount of dark NXT they hold.

Not to derail the thread but there are other solutions. Anyway, having 13,328,411 NXT minable by brute force is an excellent honeypot. Keep those accounts under surveillance and we have a better chance to react to unforeseen vectors.

8
Core Development Discussion / Re: Nxt 2.0 design
« on: February 24, 2016, 11:11:11 am »
To add to that, since the fNXT chain would be growing at a much slower rate than the NXT chain now, pruning of the forging chain, if ever required, would need to be done less often, say every 5-10 years. This is important because when even the forging chain is pruned, there would be no mechanism to easily validate transactions that occurred before the pruning, as even their hashes will be gone. This would require figuring out some other way of trusting existing archival nodes. And keeping transaction records for at least a certain number of years is a legal requirement for businesses, we should first consider what are the most common record retention requirements before implementing a pruning that makes it impossible to verify old records.

It could vary but a lot of financial and audit regulation is based on fairly international standards (like IRFS, GAAP etc). It's 10 years here in Norway.

I would say some of the beauty with blockchain thinking today, is retaining a full history from genesis and up. In that regard, there will always be a tug of war between the size of the blockchain and the usability of a complete dataset.

Pruning is rather risky unless archival nodes are paid for their service, so you could contemplate a solution where forging can only be done by full nodes, archiving included.

Also, please consider my solution proposal for the "NXT/fNXT" problem.

9
Regarding the amount in circulation...

We need to start with a reasonable amount and not too much - its that 1:1 or less i don't know.

We don't want so little that in the early days fNXT fees for side chains are too expensive that it stops people experimenting.
In the future assuming its successful each fNXT might be too expensive but then we should have a plan to change the SW and in a special block distribute fNXT to all holders - a kind of dilution is always possible.
We can even by voting make this decentralised and democratic.

What I do know is thats its important "How" we do it, because NXT is a young but important marketplace to many and we should not be careless with this in the pursuit of fNXT.

Once you stretch the fNXT distribution in time, the risk window is much more open than with a predictable and instant scheme. The ratio, allocation logic and distribution needs to be 100% predictable and transparent so that even retards understand it. Else, you risk a lapse of faith and boom goes the economy.

10
Core Development Discussion / Re: Nxt 2.0 design
« on: February 24, 2016, 08:30:51 am »

6) A lof on NXT is probably stranded and will never make it to Mother.


A lot of ?

But apart from that.....interesting.

Yes, a lot of!

Sorry my english not so god, but practice for benefit glorious nation of Norway!

11
Ok, dependent on jetboy's proposal:
Does it matter what the ratio is? All of the fnxt is all of the fnxt, whatever the ratio. 100% is the same whether it's 10 tokens or 1000000000.

Sorry, just read that this thread wasn't one for counter proposals! Of course, 100% is 100% but there has to be a lot of NXT which is stranded. Why strand a lot of fNXT as well?

12
Edit: Deleted due to irrelevance.

13
Core Development Discussion / Re: Nxt 2.0 design
« on: February 23, 2016, 09:19:34 pm »
Here is a solution proposal to the NXT/fNXT problem (For ease of reference and a keen sense of mythos, I call this proposal "The Jetstep")

Mother = The forging chain
GoNX = Ye Good ol'e NXT (NXT as we know it today)
Nu = The new base currency of GoNX
Event_Type_X = a transaction type which exclusively tranfers NXT from a GoNX account to a Mother account
Kuang = An account which issues all fresh Nu.
Grace period = From fork one to fork two

Before the grace period:

Nu is instanced by Kuang. Nu is exchangeable from NXT. Mother is open to new accounts but not forging.

In the grace period:

NXT will remain the forging token. As such, it will gradually migrate from GoNX to Mother. It cannot migrate back. On GoNX, the total amount of NXT and Nu together will always equal one billion minus burned NXT, 999,997,096 at the moment of writing. Whenever event_type_x is used to transfer NXT to Mother, Kuang will transfer the same amount of Nu back to the originator of the event_type_x transaction.

As long as a GoNX account has NXT, transaction fees must be paid to the forger in NXT. The amount will NOT be reimbursed by Kuang. Once depleted of NXT, transaction fees will be paid in Nu. NXT lost in transaction fees count as burn.

All tradeables will be in Nu. This means NXT will not be a viable currency anymore. Assets you bought one day in NXT, will now be sold for Nu (and hopefully other pairings, except NXT)

The total amount of NXT+Nu tokens on GoNX will always be 1 billion minus burn.

After grace period:

Remaining NXT on GoNX is converted to a tradeable Asset token. Kuang will continue to issue Nu once NXT is transferred from GoNX to Mother. Transaction fees will only be in Nu.

What will happen?

No battleplan survives meeting the enemy, but let's try discuss what may happen. I think:

1) Since the total Nu+NXT on GoNX is always 1 billion minus burn, we simply form a consensus that they are interchangable for a while.
2) Many will open accounts on Mother, transfer their NXT and receive the corresponding amount of Nu back. It's a 1:1 swap.
3) Some will not bother and rather just sell their NXT for Nu and go on with their lives.
4) Since transaction fees in NXT are not reimbursed, you have a huge incentive to not hold NXT during the grace period.
5) There is really not any particular incentive to disturb the asset market. Mass asset liquidation may occur prior to the grace period because people regard pure NXT as a better investment. Sound assets will receive their fair share of love while the (perceived or real) unsound ones will crash some day anyway. Since there is no unfair or unpredictable allocation scheme between NXT/fNXT, people don't have to take any risks. It's a gradual process, not instant.
6) A lof on NXT is probably stranded and will never make it to Mother.
7) Since there may be half a billion NXT on Mother + half a billion NXT and Nu on GoNX, the total economy is expanded. So is the system and it's value due to scalability and new features.

This means the end of NXT as a currency and it's start as a pure share. The share grants a say in the power to destroy or protect the integrity of history. It also yields dividends.

Please help me in refining this proposal to the point where we all agree it's sound. A currency exists because of consensus. If we can reach it, the problem is solved.






14
Nxt Improvement Proposals / Re: Full exchange modularity
« on: February 12, 2016, 02:09:38 pm »
The 2.0 design is the right way to implement trading using tokens other than NXT. Attempting to do it on 1.0 using asset to asset trading is a dead end, waste of development time, and not portable to 2.0.

First of all, this wasn't all about asset/asset - But any/any, where any is a container with one or more asset, ms coin or commodity entity in it. It's weird and crazy but the wild is weird and crazy and people need weird and crazy things. I see NXT more as a multipurpose platform that can be used for a variety of applications which will never reveal NXT [to its users] as it's backend for services and transactions.

Secondly, I agree this is mostly a non-issue with the proposed 2.0, either because the proposal solves practical problems by itself or modularity could be implemented in the same go.

Thirdly, I side with Loco thinking one year is a looong time on this scene and freezing the platform could repel potential investors (i.e users). This thread is not the right space to discuss this but we can't be both passive and open for business.


15
Nxt Community News and Announcements / [ANN] Directional vote for NXT 2.0
« on: February 12, 2016, 01:55:43 pm »
As the current McCoy in residence (I'm right and I smoke cigarettes), I want to organise a vote concerning the agenda of NXT 2.0

JLP recently submitted dev's ideas in https://nxtforum.org/core-development-discussion/nxt-2-0-design/  . This has caused support, debate, concerns, visions, fear, hope and a few people to take their clothes off.

The idea of the vote is to gauge the sentiment on what 2.0 is about in the first place; define what's on the agenda. Once this is settled, discourse can continue constructively within that frame. A vote requires participation to be legit, so of course everyone interested should

a) submit what they feel strongly should be on the agenda for 2.0
b) perform the actual task of voting

I think we can agree that dev's agenda is 'scalability' and 'flexibility', so we already have three entries to vote over:

1) Scalability
2) Flexibility
3) Scalability and Flexibility
4) ... your suggestion

Of course, should no other alternatives come up, it will be a poor vote. The outcome of the directional vote should give us all some bearings on how to proceed forward. This is not a vote on implementation or any concrete suggestion.

Time is money and we have neither to spill, so if there's genuine interest in this, I want to hold the vote before march 1.

16
Core Development Discussion / Re: Nxt 2.0 design
« on: February 09, 2016, 06:04:12 pm »
If storage is the problem, why not change the forgingpower example to archiving. So you get chains that get the old block histories stored

Storage in a distributed system can translate to bandwidth challenges as well. Also bottom up operations can get very resource consuming. There are archives already storing everything. As I understand you, you suggest a classic event sourcing solution to this problem: Snapshots. Once you have reached a certain operational size, you snapshot the state and start all over with the snapshot at the bottom. The full shebang gets stored in archives. This is watering out the first generation blockchain concept, so if you go down that avenue, why on earth should any user application have the blockchain locally at it's host at all?

This implies a division where some participants take care of the blockchain and other participants only concern themselves with their specific transactions. The division proposed by core dev is a good step in this direction. Which I personally believe is needed.

Say what you want people, but storage and bandwidth in Africa (or anywhere else for that matter) for mobile devices don't support bloated blockchains.

17
Core Development Discussion / Re: Nxt 2.0 design
« on: February 09, 2016, 05:19:51 pm »
I like the concept of sub-chains (do they have to be "child" chains?) but my initial thought is that a split between tokens to secure the main chain and tokens for the proposed Nxt sub-chain is a risky idea.  The economics of the whole system would change pretty drastically, but I do agree it is ultimately better to decouple the price of the forging token from assets/items/etc in the Nxt economy.  The forging NXT would need to have strong incentives for holding and a liquid market, but I'm concerned the free-market result would end up looking like NSC.

Thanks for your reply!
This is a bit the idea ( i have made an image but cannot find the upload option...):




I'm also quite new to this, but I don't think the forging power is the "problem".

First of all, the parent chain (upper in the hierarchy) will only do forging, for everyone, and nothing else.

The children are like NXT today in either full featured (like NXT now) or specified form for a purpose (pure money system, pure asset exchange etc).

They will validate transactions, but only the top parent chain can forge the blocks (as far as I understand).

The problem which is sought solved is the size of the blockchain and scalability. If a chain just grows and grows, it's possible to become too big at some point. And overloaded, like Bitcoin appears to be now.

18
Core Development Discussion / Re: Nxt 2.0 design
« on: February 09, 2016, 04:19:48 pm »
I think we can let the fear dissipate a bit. With such a small community with very little commercial interest, we should be able to solve most issues with a minimum of loss.

There are a number of economic and technical scenarios that need to be worked out and solved before one would go ahead and implement it. I previously raised concern about how fNXT/Milck distribution would happen and that's just one of many things that has to be expored and ironed out. There should also be a discussion about how much of a concern bloat is, who says every user needs to sustain their own local copy of a full blockchain in the first place? Will bloat really be a problem for nodes? Are there other ways to mitigate bloat? Should children be more flexible and radical then hitherto suggested? What is the true role of the motherchain? Forging only? What effects can pruning have on a public archive?

Let's not also forget that devs have a lot of stake, both literally and figuratiely. They don't want to do anything that ruins their own efforts and posessions.

EDIT: Neawanna, I ilke your question. Less tx in-block and faster confirm times makes fivedouble sense in this world. This also makes sense in Milck economy, I think. Another thing to explore!

19
Core Development Discussion / Re: Nxt 2.0 design
« on: February 09, 2016, 02:28:52 pm »
I for one will read the OP many, many times and actually try to understand it properly.

I think the key message here is an ecology of connected chains and then we can all argue the details in the coming months?

How about MILCK, Riker? Like magick.

20
Core Development Discussion / Re: Nxt 2.0 design
« on: February 09, 2016, 01:33:58 pm »
- MILK (motherchain token)

MILK - fNXT 1-0

Pages: [1] 2 3
elective-stereophonic
elective-stereophonic
assembly
assembly