I think i will vote for this motion rather than nagalim’s proposal because it s easier to understand to me and its seems that some parts have already been used for peg maintenance over the past few days.
I’m a little bit confused how @tomjoad’s post is a reason to prefer this motion over cad85024e62334e3a52e65b70a746d2c94d510c8
Both motions only sell NSR (T6) if the buy side liquidity drops below 25% and @Nagalim’s version at least includes an amount of time the buy side liquidity needs to be low before NSR get sold.
As BTC (T4) are being used to buy NBT as soon as the buy side is below 40% or 35%, respectively, one might assume that NSR are only being sold as soon as the BTC funds are already dry, because otherwise the BTC are used to keep the buy side above 25%.
Dividends play no role in @Nagalim’s version - or did I really miss that part?
So why is this motion here preferred?
What part confuses you? Both motions are very similar and @Nagalim even outlined the major differences.
No offence intended, but I sense a smack of preference for this motion because it’s created by @JordanLee.
If it makes a difference, I don’t really care. I probably wouldn’t have even drafted my motion if JL had made an official thread with a [draft] tag. That was really all I wanted, and it ended up with a motion fork, so w/e.
And although one motion is buried in the middle of a thread, that motion is preferred over a similar one that is governing the use of funds even more precisely.
It’s a little bit frustrating to see a lot of discussion going on, but relevant people like feed providers not participating and still making a decision based a reasoning I do no know and can’t follow.
This is different from my experience in the past.
Maybe it’s not the situation that has changed but my perception instead.
I might have become too involved thinking and discussing about how to tie the tiers to each other, how to create a set of rules that guides the NSR holders as well as people members of FLOT or other functions.
It seems that my desire for heaving rules that follow SMART criteria doesn’t find common ground.
I already bowed out from heavy participation for some days in the last week and the week before that. I might need to expand that to get a more distanced view back.
OT: @masterOfDisaster, have you ever thought about creating a feed yourself?
The more, the merrier
Sorry for the delay in my answer. To be honest, it would require a lot of time for me to understand the subtile aspects of @Nagalim’s proposal. @Nagalim is extremely analytical and very scientific. I do not have the brain cpu to grasp quickly all the details. t seems that we have used the 40% threshold proposed by @JordanLee to trigger the sell liquidity replenishment a couple of times. That is why I chose his. I wish you could generate your own feeds as suggested by @willy .
EDIT: I have not favored @JordanLee 's motion because it is JL.
There are plenty of motions created by JL that I did not vote for.
Also, there are motions that JL do not agree with that I have voted for. The last one in date is the dividends motion created by @Nagalim .
Yah, it keep triggering over and over again. It’s triggering right now. Mine introduces a velocity from 35% to 40% to give some bounce to the trigger rather than having it just be a floor that triggers continuously.
@mhps limits his response to triggers to 3/month. I ask you, which setup would be better for him, the one that requires a signature every day or the one that gives a little more slack and a lot more smack?
More people will understand it once they arrive at the decision point.
Every motion can be changed ammended by just another motion. It’s good we start to think far ahead and get prepared, so when time is ready, we have the right solution ready.
I think my fitting-based predictive solution is more adaptive, robust, and easy to adjust, if the calculation can be done on a webpage.
It was my main driver to get started rather sooner than later. I chose for JL’s perspective although I can see certain advantages in Nagalim’s as spelled out by Jordan. I think time will tell which parameters work best and amendments will be made. More than happy to support those when time comes.
Same disclaimer here as Cryptog made; I have voted for and against JL’s motions in the past. Don’t think the situation has changed lately. Taken a more distanced view back is something I had to do a couple of times as the complexity of some of the motions is pretty high sometimes. Won’t be the last one to admit that sometimes I’m having a hard time to get through some of them and that is not necessarily a problem of the author, just the nature of Nu.
A post was split to a new topic: Ramp up FLOT operations instead of sudden start?
@assistant motion vote f99ddf406a32d39be7d614c13dc1ce63c96e4003
Here are the details for the Motion Vote on f99ddf406a32d39be7d614c13dc1ce63c96e4003:
Blocks: 5077 (
Share Days: 1344682675 (
This, meaning JL’s motion, has passed.
When all the motions to join FLOT pass there will be 8 signers. @erasmospunk mentioned for NBT or NSR the addresses are most ideally 3-of-5, although it seems possible (if rather tricky) to push to 4-of-6. Bitcoin allows up to 15-of-15 multisig so it can handle all of us.
For now I prefer 3-of-5 for NSR and NBT, and we’ll need to form two overlapping groups. There will be 2 overlapping members, who should be the most available and perhaps the most anonymous. Given forum participation I think @masterofdisaster and @cryptog could be in both groups. In that case I’ll propose @dhume, @mhps and @ttutdxh to deal with NSR, where @woodstockmerkle, @jooize and myself would handle NBT.
First we should try to set up an NBT address to get started (at least for testing) and prepare for a takeover from FSRT. I’ll throw in my pubkey for a testnet address:
“isvalid” : true,
“address” : “bDWN25hetBu3efe7jcWBNaDdMFU38ZJ2si”,
“ismine” : true,
“isscript” : false,
“pubkey” : “03be3cc2a51715848833546898c57f3a2d83fd53274eb5c55c04d74615b57bf1bb”,
“iscompressed” : true,
“account” : “”
Your suggested team groups sound good to me.
Can I run two wallets simultaneously to separate FLOT from my private? I would at this time need
nud for OS X. I own a Raspberry Pi 1, but need to get an SD card reader for installation. Is an RPi 1 sufficient or should I purchase the RPi 2?
I could install a distribution via a USB stick for the testing phase, and later set it up the way I want for production use. Is Peerbox suitable for this by the way?
I haven’t figured out all the details, but I’m confident I will. How do you intend your setup to be?
Is utilizing a VPS discouraged or out of the question? Availability should be higher, though rarely be a problem anyway (power outages, ISP issues). They’re convenient, but a point of trust of course.
You can run two wallets, the cost is that you need to store 2 copies of the blockchain. If it’s just for signing etc. one should be able to strip away all the blockchain functionality from nud, which would be some work. By the way, if anyone else did a lightweight implementation of the relevant functionalities needed for multisig, please let me know.
I would personally discourage storing your private keys remotely. We’ll aim to put all signing functionality into one lightweight package so we won’t need nud all the time. If anyone’s private key is compromised we’ll move to a new multi-sig address, so there’s some robustness against e.g. losing your phone, but probably won’t help if the keys are quietly stolen by the operators of your remote server.
If you mean for the test-net, you can do anything you want.
What about BTC?
All of 8 signers. Perhaps 5-of-8 would be the best.
Alright. Can I do testnet operations through the debug window?
If you are running on testnet then yes. Otherwise no.
I just found that running nu / nud on testnet creates an entirely separate datadir. So given enough RAM one can conceivably run separate instances on testnet and mainnet with little extra effort. My current machine doesn’t have the resources so I’ll rely on someone else to try it.