Cool. I’m thinking we do a 24-hour sma from both polo and bter (volume weighted average) and input the 70,80,90,100% as like hardcode or whatever. Friday can be manual. The separation of bot operator/API and withdrawals/account owner is really interesting too, though it’ll probably add to the total overall cost.
So, we would need to write wrappers for bter and polo and do that price feed stuff. How much are we willing to put up for bounty?
automation also helps to make it distributed. we just need several honest account owners to run the bot in their accounts and hand back NSRs on friday.
I suspect a bot that can do buy backs bit by bit (or with other strategies unsuitable for a human) can buy back at far better prices. The bot can pay for the bounty quite possibly.
then we would need some nubots like MoD’s gateways for NBT. In that way FLOT can sent BTCs and receive NSR 
I guess nubot can send back NSR automatically to T4 if configured to do so?
That idea is as simple as ingenious!
It should go to a separate thread not to get lost in this thread.
It would help with NSR buybacks as well as with NSR sales (e.g. to fill T4 buy side, or in general: remove NBT from circulation).
I don’t think so.
Plus it would require API credentials which are allowed to withdraw funds. I would not want to use that kind of credentials…
Right. I was thinking this bot could be a marketmaker if equipted with a feed.
Maybe this part of discussion should be moved there? Could @CoinGame do it? Starting from –
It still requires the trust of one person to keep the bot running. And, a FLOT team member can determine the buyback time simply by being the last person to sign a transfer. Those are both points of weakness that exist with a sole executor, except with the added cost of development.
Automating things feels like the right thing to do, but the expense of doing so wouldn’t generate a lot of incremental benefit for shareholders. Let’s keep things simple and find one trusted executor who can use their judgement to maximize the number of shares purchased each week.
I agree that finding a execution person to do it manually is the least resistance path and we should do it now. But it’s like assigning sell-side custodians to distribute shareholders-paid liquidity in Nu’s early days. For the long term selling NSR following the NBT liquid provision scheme is still the way to go, I think.
I was not only thinking of the current situation with centralized exchanges when being intrigued by that idea.
I was rather thinking of B&C Exchange as well!
I’m close to getting a headache trying to imagine it and I’m not sure whether it’s possible on a technical level, but…
If funds are sent to a BCE deposit address that is essentially a multisig address which the reputed signers control. There’s an address on BCE as well that allows initializing actions like withdrawing the funds, putting them on orders, etc.
As far as I understand, these BCE addresses can be multisig as well.
It would be awesome to support different levels of signers for different actions.
That could allow a scheme in which withdrawing funds requires 3 of 5 while putting funds into orders requires only 1 of 5.
The FLOT could have funds in addresses which any FLOT member could use to operate a NuBot with them while 3 of the members would be required to withdraw them.
I was letting this thread running on its own before intervening, to make sure requirements are clear to everybody (they are not ) . I am in favour of designing and implementing a software solution for automating NSR buybacks.
So, can we start together drafting a design document? Let’s write a list of user stories … I’ll make a new post reply and make it a “wiki” so everybody can edit it
User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system.
Feel free to edit this post, is a wiki. Make sure you add edit reason at the bottom if you change something.
NBB+NBP is intended as a software system to automate NSR buybacks on the available markets. It requires one or more operator to configure and keep it running. It should be easy to configure and run, open source, and should use a publicly known pricing policy.
##NBP
####NBP-01
NBP is a service that requires 24/7 uptime and should have high availability and reliability since it provides a core service to the Nu network. (4)
####NBP-02
NBP should expose an entry point that accepts HTTP get request and reply with a price, expressed in BTC with 8 decimal digits precision. It should also provide a timestamp at which the value has been refreshed.
####NBP-03
NBP should implement some DoS protection mechanism.
####NBP-04
The price is calculated in weekly cycles (1) as required by current buyback strategy :
####NBP-05
The pricefeed operators should be able to configure the parameters for the cycle. (6)
##NBB
####NBB-01
An elected operator can download the source code and binary. The main scope of the bot is to place limit buy orders for NSR below market price.
####NBB-02
The bot will work on available markets with an active NSR/BTC market. At the time of this writing being Poloniex and BTER.
####NBB-03
The bot operator will manually fund his exchange account with BTC, create an API key pair, configure the bot and run it.
####NBB-04
The bot needs to connect to an external price feed that is active 24/7 . The price will be verified locally and used to determine the limit buy price (2).
####NBB-05
The bot operator needs to manually withdraw funds from his account as defined by his operational details.
####NBB-06
As soon as NBB obtained and verified a buy price the whole BTC balance will be used to enter a single limit buy order (3).
####NBB-07
If the price feed is not available or considered unreliable, the bot should stop and do nothing.
####NBB-08
The NBB operator can configure a list of IP addresses of nodes of price feeds. feed1, feed2, feedN. A minimum number of x nodes is required to work …
####NBB-09
Every two hours the bot checks active orders and … ?
###Discussion
(1) Do we want the bot to operate on weekly cycles or continuously ?
(2) This way, the operator doesn’t have any control on pricing. Ana a price feed requires a price-feed operator and maintainer.
(3) Are you sure you want a single buy order? Maybe its better to distribute it, parametric orderbooks are already built so its no brainer… Is a matter of defining which book type and the replenish-wall strategy (how often, under which conditions?)
(4)To realize this condition this service should either require an operator, some redundancy and decent infrastructure, or it can be distributed and replicated across multiple volunteer nodes, similarly to the DNS seed server.
(5) please enter some proposals for the formula used to compute ICP
(6) if we deploy the feeds across a network of volunteer nodes, how can we know the config parameters are the same for all nodes
(7) …
Thanks for the draft.
####NBP-04
The price is calculated in weekly cycles
There is no reason to run it in a weekly cycle even the buy back amount is determined once a week. The price can sweep at a faster or even randomized pace to make it harder to game.
- an initial cycle price (ICP) is computed every Sunday, 23:59 PM UTC, using this formula based on market price : 12-hour Moving Average . (5)
.
####NBB-03
The bot operator will create an API key pair, configure the bot and run it. The bot operator will either manually fund his exchange account with BTC, or let external bodies, such as FLOT, fund it.
.
####NBB-06
As soon as NBB obtained and verified a buy price the whole BTC balance will be used to enter a single limit buy order
It could sell a random fraction of the total amount.
So coupled with unpredictable selling cycle, if you see a good price you should buy immediately since the price won’t last and if you see the same price next time, you don’t know how much will be on sale.
We are programming a bot. We can afford to be complicated, at least after an initial simple-strategy trial period as given in the original draft.
mmm, wait, how is “once a week” different from “weekly cycle”? I am not sure I understand this sentence correctly.
I like the random element, I am sure it must be somewhere embedded in the price calculation. The price frequency is a good proposal : everybody knows the algorithm, but no-one knows the execution time.
Can we please dig deeper into this?
We need a definition of cycle . Since buybacks are designed to start the cycle at low price and increase it at the end of it, it can be caracterized by : a) a total cycle length b)an initial price c)a final price d)a final time at which orders at not placed e) a pointer to the next cycle being f) price increments in % g)how often increment the price …
At each cycle beginnings we may or maynot randomise all or some of these variables. They should all have a lower and upper bound.
(parenthesis : See? not so straighforward as you guys make it sound . )
if we go with quasi random-length cycles should we replace “Sunday, 23:59 PM UTC,” with , “at some unknown point during the weekend” ?
Let’s, for the sake of convenience that walls are placed mon to thursday (like now)… This means basically that during the weekend the price is free to do whatever it wants (and also be manipulated, like it is being manipulated now?) .
Then you suggest to compute the Initial Price using the “Moving average 12 hours” ? Something is not exact here : 1) if its computed once, it cannot be a moving average, it’s an average. 2) if, it’s an average, do you suggest to make it weighted by volume? How often should volume and price be sampled?
right!
Why do you think it won’t last? Maybe you can say “you don’t know how long it will last” .
Good point
let’s keep this ball rolling please
How about:
ICP is a 72 hour average of Friday through Sunday. Orders are placed the first Monday between 75% and 65% parametrically (the randomness is unneccesary in my opinion. Just do a first come first serve thing.) If every order is eaten on Monday, subtract 5% from the price feed for all of next week. On Thursday, it’ll be 95%-105% based on a 24-hour average. On Friday it should successively put up orders starting at 100% and going up to 150% (you can put some randomness here, maybe make the 150% fuzzy with ±5%). At 150%, cancel all orders and wait till Monday.
Could you please make some example with detailed pricing pre-cycle, during cycle in both scenarios (orders getting and not getting consumed during early days of the cycle) ?
ICP (72 hour average): $1. Funds: $100
Monday:
$33 at $0.65, $34 at $0.7, $33 at $0.75
Tuesday (24 hour average, assume it’s still $1):
$33 at $0.75, $34 at $0.8, $33 at $0.85
Wednesday ($1):
$33 at $0.85, $34 at $0.9, $33 at $0.95
Thursday ($1):
$33 at $0.95, $34 at $1, $33 at $1.05
Friday ($1):
$10 at $1.00, $1.05, $1.1, etc. until $1.5 (prices fuzzed with ±%1 so you might have $1.06 instead of $1.05). Place them every hour (fuzz by 10 minutes). If an order gets eaten at say $1.1, don’t go to $1.15, do $1.1 again. Then, if the funds run out, end the buybacks and delete all orders.
If people sell all funds on monday, the next week everything will be the same, except all prices are lowered by %5, so the ICP for the next week is $0.95 instead of $1. Then, if they are all bought again, the ICP lowers another 5%.
What if we put up an “opposite” ask order of NSR? Say if buyback places a bid at 70% market price, then there should be an ask order of comparable size at 130%. In the end there should be nearly matching ask and bid orders near 100% market price. If the buy wall isn’t consumed by Friday we do something else, such as lifingt the sell wall do open-market purchase. This way it’s probably easier to buy at the “actual” price that people are willing to sell NSR, resisting upward manipulation that occurs during buyback.
that something powerful on an hypotethical NSR/NBT pair
Fundamentally we don’t know the ‘actual’ price. Setting the buy wall could cause Nu to sell under the ‘actual’ price.