It isn’t clear to me what you are proposing, because I’m not sure what is meant by “provisionary group”. It seems to imply that the signers will change, but I don’t see an advantage to that. We need to get enough of the right kind of signers right from the start to protect the large amount of shareholder value they will control. If we get the right signers from the start, then there is no need to make changes later.
Some want more complex rules governing the use of funds. I have no doubt that the rules articulated in my draft motion can be improved upon, and will be in time. However, the project to get a group of signers managing tier 4 and some tier 6 funds is not showing decisive progress and is overdue at this point. It is irresponsible of shareholders to not have any provisions in place for short term (rapid) use of tier 6 liquidity. What is needed is a short and simple iteration to bring progress. Then further refinements can be made. The simple rules I proposed are quite comparable to what is already occurring with tier 4 liquidity. It is status quo. The only thing that is really new is using multisig addresses to hold funds, and everyone can agree that is an important improvement. So let’s get that important improvement implemented and then discuss additional improvements individually.
Are there any specific suggestions for changing the actual text of the draft motion? I want to hash it soon.
“If the total liquidity in tiers 1, 2 and 3 across all currencies is greater than 100,000 NBT with less than 35% on the buy side, NSR will be sold. If the total liquidity is less than 100,000 NBT, a threshold of 25% will be used. The speed at which shares are brought to market is up to the discretion of signers and future shareholder motions.”
There’s a very deep occurance here, wherein you are allowing someone to buy as much NBT as they want and sticking all the funds in T4. Interestingly enough, it is in a signer’s personal interest to increase T4, but that’s not the biggest concern to me. The 100,000 NBT limit becomes very critical, as these rules could stimulate signers to bring all NBT to market, potentially selling to a single entity, and ending up with BTC. They can then sell right back to us after BTC crashes and we lose. Are we really willing to just straight up placing 100,000 NBT bets on the price of BTC?
The solution that @JordanLee has set in place is to use the share buyback motion to perform NSR buybacks when T4 goes over $80,000. That’s a good solution, honestly. One of my concerns is with the $80,000 number in light of the 100,000 NBT number. The $80,000 in my mind can be treated as a sort of collateral for the sellside NBT in the event that both funds are drained entirely via vast manipulation or oscillating market pressures. I would like to have a 100% collateral instead of an 80% one and would argue for a FLOT nbt cap that coincides with the T4 cap (which is of course 80,000 at the moment).
The other concern I have is with the 40% number. I’d like this to be 30%. As I’ve shown, market oscillations can hurt if they happen faster than we can perform buybacks. We should keep a large virtual spread.
It is just a suggestion and signers advancing a motion to get themselves elected to FLOT can include whatever content they want, so long as it specifies that they are to be a member of FLOT. They can ask for whatever compensation they need as well, although at least a couple people have already indicated they won’t charge to be a signer.
This is a good opportunity to point out that perhaps the best way to position yourself to be a paid B&C Exchange signer is to first become a FLOT signer. With the 4.0 B&C release nearly ready, the time to begin selecting B&C signers is coming soon.
Nagalim has suggested the threshold for using tier 4 funds to balance be 30% instead of 40% and that the threshold for using tier 6 funds be 35% instead of 25%. What does everyone else think about these two specific suggestions? I’m mainly concerned that a mere 5% difference in the threshold for tier 4 and tier 6 means we will be likely to engage balancing efforts using tier 4 and 6 simultaneously. I would rather see us use just tier 4 first, then tier 5 (parking) to top tier 4 up if needed, and then tier 6 only if the previous actions aren’t producing the results we would like. We can utilise tier 4, 5 and 6 all simultaneously if needed, but I think we should be escalating from tier 4 to 4 and 5 to 4, 5 and 6 as needed. Most interventions will only require tier 4. A minority will require tier 5 in addition to tier 4. A minority of tier 5 use cases will escalate to include use of tier 6 in addition to 4 and 5. I’m concerned @Nagalim’s proposal will unnecessarily increase the use of tier 6 liquidity.
I’m in favor of any structure that leads to clearer delineations between tiers. Complexity will lead to redundant efforts between groups at times, and more frustration for the multisig groups that are required to act. So, I prefer a greater difference between T4 and T6 thresholds. 40% (T4) and 25% (T6) feel about right to me in the absence of empirical data. Once B&C Exchange is operational it is unlikely we would ever experience a >25% drop in buy-side liquidity over a 24 hour period if the majority of our liquidity contracts are of set length and irrevocable during times of panic.
Mr. and Ms. Right Signers don’t just appear out of the blue. A coherent architecture of tiered liquidity need to be constrcted and understood before potential signers realize they can be up to the task and be willing to become a signer. Changes WILL happen. With multiple signers changes of signers can be accomodated.
Democracy takes time to find concensus.
If changes of rules such as the hard rate limits and way the limits are used are envisioned, it would be close enough to how the provisionary group I proposed work.
But what can you do if a signer wants to quit before the one year term specified in the draft ends?
I agree. But I don’t have strong opinions on the numbers 25%, 30% 40% … they are all made up from thinking rather than measuring.
Things will get sorted out as long as a group is commited and properly authorised but monitored. So I would like to see a clause in the motion that the group can excercise discretion, and decision making of the group is visible to the shareholders all the time.
Currently, we have over 100,000 NBT (~200,000 currently), so it would still be 25%. My adjustments are:
Reduce T4 to 30% instead of 40%. This is because 40% does not give enough spread and we will get gamed (in my opinion, @mhps is right that this is conjecture).
Reduce T4 sell side to 80,000 NBT to coincide with the $80,000 buy side in T4. I think this is an important point for an internal consistency of having 100% reserve within T4.
Increase T6 to 35% when total liquidity drops below 100,000 NBT (otherwise leave it at the 25% @JordanLee originally proposed) . I am willing to concede this point, but I think it stands as a good marketing scheme to state that if our T1-3 liquidity drops we will be willing to dilute NSR more easily (gives more confidence in the peg).
I think the difference between 30% and 25% is vaster than you think. I also like the idea of T6 stepping in front of T4 when T1-3 liquidity totals drop below 100,000 NBT. I’d possibly be willing to compromise somewhere around 35% for T4 support. 40% is just begging to get gamed.
Another, more vague point I am trying to make is about how T6 is sent to market. It is not going to be like buying NBT with BTC, it will be vastly more important what the price for the NSR is because that’s the illiquid market. It is not a bad thing to get a head start on it and do it slowly over larger time periods. Ideally contribute to the liquidity of the NSR market like this:
There are 2 reserves. Let’s assume an attacker chooses to evaporate both reserves into each other, what would that look like? If you give me point 2) and we have a 100% reserve, it would look like this:
Attacker buys 10% of NBT liquidity (20,000 NBT) breaking the 40% threshold. This causes signers to start dumping NBT. Attacker buys all of it (total: 100,000 NBT). He does this when BTC is high, because he has the opportunity to time it while Nu does not (signers are obligated to push back).
T4 now has 160,000 and begins to buyback NSR. This is good, but isn’t super fast. The statement here is that turning NBT into BTC is fast while turning NSR into BTC is slow. This causes a buildup of BTC in tier 4 (which is actually a liability).
Attacker sells NBT fast again, tripping signers and selling T4 back down below $80,000.
In that circumstance, the attacker was able to win a gamble with us of a large amount of money. Our saving grace was the use of funds to buyback NSR and the possible repurcussions that could have had. Increasing the spread to 30% dampens the impact of fluctuations. We will always be vulnerable to this kind of attack as long as we peg BTC, but we can raise the liquidity bar required to interact with our signers directly.
The attack scenario articulated by Nagalim has a premise that the BTC price can be predicted, which I don’t accept.
He makes some valid points about asymmetries in liquidity between tier 4 sell side and tier 6 (buy side), but I believe that asymmetry is of minimal importance when selecting the threshold at which to intervene in the currency market.
Let’s pretend we move the % up to 49%. Now, the signers are basically constantly selling and buying, much like T1-3. Except now the volatility risk is not decentralized, it is essentially taken directly out of Nu’s marketcap. The % gap (‘virtual spread’ as I call it) allows us to dampen the effects of volatility using park rates and decentralized liquidity. A wider spread allows us to sustain a wider volume of volatility before we engage multisig funds directly.
If I want to sell a lot of nbt it would be better for me to put it up as sell side, kick the percentage over the 40% barrier, and force signers to buy from me at the spread premium (or just under so I step in front of the other custodians). The threshold determines how much liquidity I need to activate the signers, in all scenarios.
Put up 100,000 buy side. Force signers to sell at $0.99.
Take down buys and put up 100,000 sell side. Force signers to buy at $1.01.
Profit at Nu’s expense.
If we go from 40% to 30% we make it so the threshold for that kind of manipulation is $40k instead of $20k (Assuming 200k total liquidity). If we factor in T5 and things like fixed cost and ‘shift’ in additional to normal supply and demand rules, doubling the threshold can give us a good bit more of a comfort zone than even that $20k. With a 30% threshold the amount of liquidity required to attack the network in such a way more than doubles over a 40% threshold.
A signer does not need to run a full node, simply sign a Tx that is passed to them. (I think)
A signer must be available for signing consistently, which means reachable by bit message or whatever. @JordanLee made the suggestion 5 days a week and 45 weeks a year. FLOP should coordinate so there’s always signers available.
Retrieve unspent outputs for the multisig address. It better not involve scanning the blockchain oneself, but I don’t know anything about the API of the blockexplorer. If we can’t properly automate fetching this data from the blockexplorer we can create a small database to keep track of the outputs, and put it on a server or github. I prefer github either way in case blockexplorer is unavailable.
A first signer “proposing” a transaction would choose suitable outputs and sign a transaction. Without nud you’ll need to keep the private key and do some scripting.
The signed transaction is broadcasted (e.g. on the forum, via github). The next signer picks it up, signs it, and broadcast via the same medium, so on so forth.
When there are enough signatures somebody would use sendrawtransaction to put it through the network.
(5. Somebody with access to the blockchain or blockexplorer would update the unspent outputs)
I prefer not to use Bitmessage in any part of the main workflow as it’s not suitable for mobile networks.
It isn’t clear whether full Bitcoin nodes will be needed, because it depends on which multisig client signers decide to use. Armory is popular and requires a full Bitcoin node. There are web wallets as well as local thin clients that also support multisig transactions. Which software is best for Bitcoin multisig transactions needs to be researched and resolved. For NBT and NSR, signers will need to manage funds using a Nu client via RPC, or command line. The process of creating an NSR or NBT multisig address and spending from it is described in detail here. The process isn’t exactly user friendly but it doesn’t require programming skills or anything like that.
As Nagalim mentioned, availability will need to be coordinated so that enough signers are always available to form a transaction at any time. It isn’t clear how formalised this will need to be, but with multiple backup signers, scheduling time you will be unavailable probably doesn’t need to be done meticulously.
Signers need to watch liquidity figures on a daily basis and be available for contact by other signers. It would be ideal if they are regular forum readers.
When it is time to transfer funds, in the case of an NSR or NBT address, one signer will start by creating and signing a raw transaction, then send the raw transaction to the second signer, who signs it and passes to the next signer until it has enough signatures, at which point it will be published to the Nu network. The process with Bitcoin is likely to be even easier.
While I can’t predict how often action will need to be taken, it is likely to be between once a week and once a month. After doing it a couple times, I think signers will find the process easy and comfortable.
Does anyone have any additional questions about what it means to be a signer?
no, but people need to be signing the same Txn that is passed around. Signing separate transactions at the same time using different signers is a fork of the FLOT.
no
no, these are private keys
not unless there is consensus about the mistake. So please make sure you can verify the Txns you sign.
So it’s not passing around, it’s more like the first signer signs and broadcasts to everyone else to sign and broadcast like @dysconnect said above. Sounds chaotic if there are 7 signers.
That doesn’t answer the question, which is a matter of policy. A sends passphrases to B and says 'Hey sign it for me while I am on holiday please".
No, the first signer signs, then the next signer signs, but it doesn’t matter who the next signer is (any other member of FLOT). Then that signer passes it on. If a signer signs a different chain of signatures they are forking the transaction.