Market is completely irrational, nothing makes sense in this space… It’s the age of memes and mooning fueled by rocket air…
2 Likes
One conclusion for Filecoin is that the market don’t seem to care about current supply, because if they did then the price should see a downward pressure larger then general crypto market movements, because they print Filecoins in a rate that would make failed country blush. 
8 Likes
Agreed, this is heading towards a major Meltdown, its not even funny…
There is a whole topic discussing this, maybe you could look at it. I am not sure of the link at this time and I cannot find it either.
One of the big issues was the buffer that some 80 or 85% of tokens available at the start allows the network to be a lot more dynamic, allows it to cope with so much more when events happen. For instance a unusually large inflow of data, or a unusual outflow of rewards.
I am of the opinion after that discussion that distributing all the tokens at the start is the wrong way to go.
Not against there being a higher total to start with (eg 50% given out) and MAID people receive a proportional amount of SNT for each MAID.
Cannot see any real issues with say 50% being given out for MAID (old 10%) + the (old) 5% reserve. There would still be enough of a buffer.
But the 4.3 bn supply under the current system is a myth. The recycling of tokens means the supply to be sold over time can be 50, 60, 70, whatever bn. What will the market actually see. Perhaps it will only see the amount estimated to be “out there”. If its estimated there is 2 bn in the hands of holders then the market sees 2bn, and really would this not be the amount they should be seeing.
And would not having a pool at the start be wise? Well the original plans was for the pool to be that 80/85% of 4bn. People went into the ICO believing this was the case. As said above maybe 50% might be a good compromise if you feel there is a need to change the original concept.
Also what is the actual benefit? Will people see their SNT worth more? 6.7SNT with 4.3bn available worth more than 1SNT with 0.64bn available. More than likely the same value. So why change what people bought into the ICO with and believed for all these years to be the case? There needs to be a very good reason for doing so in my opinion.
The buffer in the network cannot be underestimated and you even suggested a work around for this. Why have a work around when the original did it for you anyhow. See below comment.
7 Likes
Which do you think has a bigger effect on the price - x10 monetary inflation or x40000 increase in token holders?
The Safe token can be increased a maximum of x10 times, while the current 16k holders can be increased tens of thousands of times to a maximum of 8000 million people. That is why the relationship between monetary inflation and holders growth is the important thing.
If the monetary inflation makes x2 for 1 month, but if for the same month the number of users goes up x10 times, then it is logical for the price of the token to go up. In your example of Filecoin, I think we are witnessing just that.
Privacy. Security. Freedom
3 Likes
One benefit would be sections cannot create coins and this could be a pretty good safety feature. It’s all a big thinking pot right now, but removing the network from creating anything would be good.
13 Likes
I would have thought that the sections have the remaining tokens already and split the section wallet when the section splits. No need to be creating them except on network start. The same process as needed to issue tokens to MAID holders
Yes, that’s true, however if a section goes bad and creates coins, it’s similar to saying take the section wallet and expand it or doublespend it. A lot will come down to how this can be audited and almost real time audits. It’s to do with the tension of totally private “cash” and the ability to create it, in this case via a bad section.
If normal users we can see a spentbook entry and that’s all fine iff sections have not allowed X in and Y out where Y > X. If we can audit that X and Y are always equal then it’s goog.
I have this debate in my mind
- If code is working and no section is byzantine (our and other project assumption of 66/50 takeover cannot happen) then no need to audit.
- If auditable then we can tell if code went bad or there was a bug.
@danda and I have poked at this a bit. My feeling is getting to simplicity and proven codebase then we can have trust in sections and not need to audit. It’s a debate though for sure!
There is a possibility of adding auditability while maintaining privacy, but it will require scraping the address space for spentbook, which is really not nice. We could have some kind of gather all statements per section etc. but that’s all a black hole IMO.
I am 100% not on the side of the argument that all money supply must be auditable, but I do believe code should be. It’s a debate with no clear winner, although can have some deep-felt beliefs in the blockchain world which make sense if you think single container of all transactions.
The other thing that can be done is … say take an extreme case, every coin has an address, every address has an owner. Then you cannot have more than one owner. So all addresses are a register or even a CRDT with no tombstones (so no history). Then the supply is locked and we know folk have it, without having to know the folk.
So a deeper discussion than it seems. DBCs for example would tout zero auditability as a privacy win, where zcash/monero tout auditability as essential, even in a privacy cash system. I am unconvinced that both these arguments consider everything available.
6 Likes
But there is no creation. The sections start with the predefined amount, exactly the same as MAID holders start with their’s.
Its only a creation in the respect that the start condition has the tokens in the wallets. There is no “run time” creation.
And if a section does not control its own wallet then there is a level of security where a wallet cannot hack its own wallet so to speak. Thus it requires two section to be bad, conclude together, hack the wallet.
Now if you give all tokens to people then under your description of events a bad section could still cause issues as well. So the idea of initial sections have all the remaining coins and split when section split is as secure as giving all tokens to maid holders???
2 Likes
Kinda/sorta. A section wallet is dynamic as the section is dynamic (so sync issues there as churn happens and we really need a crdt that recognises majorities over churn and so on, not impossible, but not simple as the Section Actor acts like a single entity but can be in flux, again we do handle this quite well, but not completely, yet). We will likely use 1-time keys that will help as it prevents any old section from moving coins etc. So good from that perspective.
In these thought experiments, I assume 1 section is bad then it’s likely many of them, based on the attack to get a section. It’s a huge thing to get a section takeover and will likely mean you get many of them.
Yes if
- There is no audit trail
- There is no 1:1 map between coins and owners
… perhaps more
Right now, for clarity a bad section would likely be able to perform considerable damage, perhaps limited to a dead address space for a while, but coins are the danger point if section shave Authority to spend/move their “own” coins validly. IF they don’t “own” any then it’s more difficult for them.
3 Likes
But they will, when resources are paid for. Also for the “pools” workaround to give (hopefully) similar benefit as just having the 85% owned by network at start.
1 Like
Not if resources are paid direct to nodes though, which is an option, not the proposal above, but an option. Gd point though, pay sections does give them at least some money. I presume it’s a small amount that perhaps clients/Adults can attest was paid out?
Agreed.
To be clear though here we (maybe just me 
) are looking at something many don’t. So most projects and algorithms say given the super/majority of nodes are honest … Here we are saying what if the opposite is true. So it sounds like wild west nothing thought of, but we are way beyond that assumption of being always true and looking to detach all authority to mutate from the network.
6 Likes
One possible way might be to have a two tiered wallet system for sections.
The lesser one is along the concept of the pool where tokens from resources sold are paid into (rewards paid out of) and if it gets too low it then gets topped up from the major wallet.
Now the major wallet is not held by the section but is a wallet requiring multiple section signatures (however this would work) to transfer tokens to the section’s pool. This way there is multiple sections (n of m) agreeing to supply more funds to the section.
Maybe this wallet is like the wallet from a parent section some levels back. Thus the wallet is for many sections to refill their pool wallets. As the sections split this wallet will be split so that there is never too many sections involved. But say at least 8 sections.
Eventually sections will only have their pool wallets because there is never enough in the upper wallet to refill the pool wallets and the pool wallets never get too large anyhow
That’s an idea but still feels like moving the problem a bit. My preference is kill all old keys (so they cannot be “sold” to hackers etc.) So using old wallets my require a bit more thinking?
Perhaps if there were section wallets/pools they alone (not users cash) could be linked to an array of coins (array being seperate registers representing each coin or something). Then section have this extra hassle of spending only what they can form such arrays?
I feel it’s best though that the network itself cannot mutate anything (i.e. it’s just a recording device and we could replace it with a single container of users signed “stuff”). I feel this gives us the best we can get where a bad network/section/container can only refuse to give us data or give us old data but no more. Then we can make that cross platform/network/storage etc.
4 Likes
There is always the option for a foundation to keep spare tokens to feed the net like a mother feeds a baby until he is old enough.
Privacy. Security. Freedom
3 Likes
Launching with no supply owned by the network is a sensible proposal particularly because of the network’s sybil security model, which lets on new nodes only when there’s need for space. If coins owned by the network were to be hacked or cheaply mined by an attacker, they can more easily afford to pay for the data uploads required to “fill” the network and get more of their nodes accepted. There’s more to it than that, but that’s the gist. Having the strongest believers of the network instead be the decentralized stewards, custodians, and spreaders of the coins may be the better compromise. If you think about it, that’s what the role that the network would be tasked to play and that role would instead be given to a large number of believers.
Additionally, if there’s no honey pot, there’s less of an incentive for section elders to misbehave as @dirvine points out above–the elders should have zero power to mutate anything. I would also personally prefer for the network to own a proportion of coins to dole out to late comers (not 85%, maybe closer to 30% for the aforementioned economic sybil resistance), but that personal preference is overruled by the need for security.
Finally, I also like the proposal because it should keep things very simple thus allowing for faster launch yet with strong security guarantees. As long as the network is upgradable, the token holders can collectively vote in the future to add a network-owned wallet/pool when the security guarantees have been figured out so that bad sections can’t steal coins.
12 Likes
Seems similar to what the proposal is with the foundation being the mass of MAID holders until launch and subsequently any holder of the network token.
4 Likes
The suggestion is to copy something we know works in practice because Storj is implementing it on their network. When all farmers know that they will receive a subsidy if the yield of Safe tokens falls below a certain level, it is more likely that these people will endure the difficult hungry days and weeks.
Privacy. Security. Freedom
1 Like
Strangely similar graphs.
Edit: not sure why it goes from 182 to 184. Here’s a more accurate something:
So, as I started out with saying, it might be a difficult thing to do depending on how far to take anonymization.
(where “can’t” translates into “other things were higher priority”, like anonymity etc.)
And also, from that first post (which David has already gone into details with above):
This summarises the reasons to want that:
Was not a suggestion for it to be done, just described the first idea that came across for how it could be done.
I have no opinion on what the market should be seeing. But what you are talking about above are three different things; supply, velocity and GDP.
The supply of tokens within the DBCs will be real. It’s not a myth.
Depending on the velocity, you might get a GDP of "50, 60, 70 whatever bn", but that is not the supply.
Great points @Bogard.
5 Likes