You’re such a blessing MoD, thank you. Super helpful.
I managed to mess up my wallet in ways i can’t seem to fix making this, so I hope y’all appreciate it. It’s dangerous because it forges the raw Tx from scratch. This is because there is no rpc command for:
'sendfromaddress’
which means the only way to actually send from a particular address using RPC is to forge the raw transaction. It blew my mind when I learned that; there is no simple way to send coins from one address to another using RPC.
Anyway, please read all the commented code before you run it. Before it actually sends any money it will confirm with you one last time if you’re sure. You will need to tell it your wallet password, please be careful saving that to your hard drive. It will only unlock your wallet for 1 second to sign the transactions. I have tested the program several times and am confident that it does what it should do.
This is just the first iteration!!! It will only get better from here!
3 Likes
I am still failing to understand the basic idea about the unseeded auction…
Perhaps drawings could help.
There’s another one after this that’s even more complicated, but I will need a little more time (and thought) to put that one together.
6 Likes
I suppose that one participant can have several registered address pairs.
In any case, it seems that the situation is the same before and after the auction…
The colors flip. Red -> purple. Think of 1 red square as 10,000 NSR and 1 purple square as $20.
2 Likes
In this one, users are color-coded. Please be aware that the 1:1 price ratio is enforced for the sake of pictorial representation, and actually represents a real price point in NSR:NBT
- Red: As one of the three initial stabilizers (who are red, teal and purple), red submits the 1:1 bid regularly using a bot on one address pair. At the beginning of the auction, red submits whatever liquidity needs to be converted via auction through the other pair (for convenience), blindly trusting that other participants will find the correct price.
- Yellow: Yellow has 2 address pairs to be used strategically. Yellow is trying to drum up support for Red’s initial bid, so submits more nbt than nsr. Shortly thereafter, yellow puts in nsr using an alternative address so the illusion of a participant with a high price point stays. As the auction approaches close, yellow submits extra nsr to reflect the market price.
- Black: Black is assumed to be several anonymous individuals. They try to guess the auction closing price, and so have low risk and gain little reward, but contribute to the volume and integrity of the auction. They always win big when the auction is unstable, their cost otherwise is Tx fees and minting opportunity costs.
- Brown: Brown is running a script to submit 3 times per auction at the market price with more volume on the last submission. Brown reveals a market that is saturated in NBT and in need of a burn, so it’s not surprising that Nu ends up seeding NSR. Brown will sell the NSR recieved for NBT immediately, so the open market will be leveraged to help recover the peg.
- Blue: Blue is one of the initial stabilizers, and tends to be bullish on NSR on the open market. Blue finds the auctions to be a good way to consistently turn NSR into NBT at a fair price.
- Purple: Purple is also one of the initial stabilizers, and finds the auctions a fun way to buy NSR. The bot runs at the normal time, but purple doubles the volume later in the auction once the seed choice seems fairly obvious.
- Nu: Nu seeds with NSR. There are a lot of NBT going around, it is very difficult to sell NBT for >$1, so NSR price is relatively high (assuming the peg will be regained, which Nu always assumes). Nu will get a good price.
- Green: Green notices that the seed wasn’t big enough to mop up the difference between the auction price and the market price and swoops in to grab some of the profit.
The auction price is then concluded with 23 NSR units and 23 NBT units. This price can be used in grants with full integrity up to the seed. For instance, if a unit = 100 NBT, the total amount for grants referencing this auction price within the next auction period should not be more than 600 NBT. As the auction volume was 2,300 NBT a manipulating grant proposer would need to spend 4x as much pushing the market as can be gained.
This process allows for motions that determine reward real-time. For example: a pool that rewards some NBT’s worth of NSR at the going rate. That way, the rewards are stable, but the user is getting NSR instead of NBT (avoid paying exchange fees).
4 Likes
Thank you for your efforts to illustrate the process with pictures. It really helps understanding how this kind of auction works.
With this kind of auction held as seeded auction, tier 6 and tier 5 could swap places, right?
In my mind, this kind of effort brings burns up to tier 4 in terms on how long term they are. While it is true that developer funds can be accessed quite readily, the long term implications of taking from developer funds are much more severe than the implications of using auction funds. Parked NBT is really the longest term thing we can do, and so should really be changed monthly or yearly rather than daily and weekly. Reserving a bit in each block for voting on the seed each auction can give an organic daily or weekly control over the supply.
We are still in phase 1. You can tell because I’m still the only one submitting to auctions.
1 Like
Unseeded auctions are down until further notice. I’m working on fixing an exploit similar to DDoSing.
Basically, the essence of it is that I should be charging participants based on the number of inputs they send and outputs they use to receive.
Does anyone know the size in bytes of an input and an output in the Nu network? I was going to use 200 bytes per input and 40 bytes per output as a conservative guess.
1 Like
Too bad the auctions are down - I was just considering to participate again.
I have a question about the requirement to register an address in order to participate in the auction.
How hard would it be to automate that process? Ideally nobody would have to register an address. Each address that is used to transfer funds to the auction deposit address (NSR or NBT) would be registered automatically and would be the address to which funds would be sent back after the auction.
I’m not aware of a RPC command that displays the sending address of a transaction.
Is that the problem with automatically registering addresses?
As long as the number of participants is manageable the manual registration process might suffice. If this auction ever grows bigger - which I hope it does (up to seeded auctions! - the registration part needs some automation as well, don’t you think?
Regarding that DDoS: a developer who can read the code might answer that question precisely.
Looking at transaction details at blockexplorer.nu I come to the conclusion that your ballpark guess for input and output sizes is quite precise.
Click on “Extra Details” on blockexplorer.nu in the top right corner right above the timestamp of the transaction to find more information on the bottom.
Thanks for the info about input and output sizes. Where are you seeih their sizes? All I see is the raw hash.
Regarding auctions being down, when they go up again I hope to have both automated continual participation (that I will use at the very least) and automated announcements (I already registered nuauction.net and have figured out vaguely how to put up text).
For automated registration, the obstacle is that an nbt address needs to be linked to an nsr address. Finding the sender’s address is not a problem, the auction already does that using “decoderawtransaction”. We could set up criteria for abstracting the process like NuLagoon does, but I think it’s better to do it like how the TLLP software associates API keys with NBT addresses. That is, have the server and client communicate and directly register the address pair / check that the pair is indeed registered properly.
However, please note that automatic registration comes after automated participation and announcements. So far, I have not had much call for making registration automatic, so it’s not really on my mind much yet.
1 Like
I see automatic registration as one day being as simpe as running the automated participation software for an auction period. For the server’s perspective:
Auction software receives request to add pair. It verifies that pair doesn’t already exist. If it does, tell participant to talk to the auctioneer. If it doesn’t, tentatively add address pair to auction. If funds are submitted to the next auction via BOTH addresses in the pair pair, add it as a permanent pair. Otherwise, send any funds back and discard the pair.
Isn’t that what gets written in the block and consumes space there?
Will try to wrap my mind around those diagrams. Tks for taking the time to draw them.
So if I want to know the space consumed, which the fee is based off of, I take that script (which is in hexadecimal) and find the number of characters then divide by 2 to get the number of bytes, right? I did that and came out with 107-108 bytes for most transactions, but I saw this one:
http://blockexplorer.nu/transactions/173260d11e17172e3c4725600a6575a81176aee5b833a01fb611a21762269048
which has an input with 139 bytes.
The outputs are always 20 bytes from what I can tell. With the 17byte overhead on outputs, that puts outputs at 37 bytes, so 40 should be fine. The inputs are really where the variation happens. The overhead on inputs is 49 bytes, so that large input would be 188 bytes. I found these overheads on bitcoin pages though, so I’m not sure they’re the same here. https://en.bitcoin.it/wiki/Transaction#general_format_.28inside_a_block.29_of_each_input_of_a_transaction_-_Txin
Yeah, my bad.
Obviously each character is hex (16 bit), so you need to divide the number of characters by 2 to get the number of bytes (because one byte equals 16x16 bits).
Alright, I’m back up and running. The auction program can now handle variable fees and data-based fees like it should. Also, check it out:
http://nuauction.net/
3 Likes
I see a lot of potential in your automatic auction regarding daily control of the supply.
I am watching every day the liquidity information, and adjust the rates every 3 days or so but it is kind of time consuming for no real effect over the very short term.
Perhaps every 2 weeks is more appropriate regarding parking rates…
1 Like
Yah, you really shouldn’t expect to see an effect from park rates on timescales shorter than a month. Seeded auctions can affect the market on the timescale of the auction, which is weekly now but could just as easily be daily. Voting for the seed is a much more effective supply control over sub-month time scales than park rate voting.
2 Likes