Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - hadrian

Pages: 1 ... 18 19 20 21 22 23 24 [25] 26 27 28 29 30 31 32
361
KeyID / Re: [DNS] v0.0.2 - Trade the snapshot and fight for delegate pay
« on: October 03, 2014, 06:24:12 pm »
Are DNS keys deterministic like in BitSharesX? I'm assuming so since it's using the same toolkit but just want to be sure so I can plan my backup strategy.

Don't make assumptions

Sent from my SCH-I535 using Tapatalk

Does this mean , "No"? ???

Also, I was wondering about registering a KeyID for each member of my family. Would this slow down the client significantly (say, four IDs) like in BitSharesX? I'm assuming so since it's using the same toolkit but just want to be sure so I can plan my backup strategy ID registering strategy. :P :P :P

362
Random Discussion / Re: Can we cut a bit the 'bit' overuse?
« on: September 30, 2014, 07:38:26 pm »
bit

363
BitShares AGS / Official AGS Distribution (Resolved)
« on: September 30, 2014, 07:00:50 pm »
I now consider this resolved: https://bitsharestalk.org/index.php?topic=9760.msg126795#msg126795



Is there an official source of information on the distribution of AGS, from which to create genesis blocks?

There seems to be a discrepancy between agsexplorer and a couple of the genesis blocks for DACs. If there is an issue it should be resolved before too many DACs are released.

As an  example of a discrepancy there is address 14fXr2UTa17CadcZ911N7TBFqMLpqsfNae

agsexplorer shows the supposed balance of AGS here: http://www1.agsexplorer.com/balances/14fXr2UTa17CadcZ911N7TBFqMLpqsfNae

The genesis blocks for Lotto and for DNS have a lower amount than expected from agsexplorer. See the following posts:

https://bitsharestalk.org/index.php?topic=9380.msg122241#msg122241

https://bitsharestalk.org/index.php?topic=4879.msg64977#msg64977

N.B. the DNS figure was supposed to show "a little extra" than would be expected from an AGS balance, so the discrepancy here is actually a little larger than it seems...

The discrepancy bothers me because:
  • It will persist through all future DACs, unless resolved
  • I don't understand it
  • I haven't seen any explanation for it

Does anyone have any insight here?

Edit: I've used strike-through on a sentence which is wrong

364
KeyID / Re: [DNS] ** LAST CHANCE TO CHECK ALLOCATION **
« on: September 27, 2014, 07:15:41 pm »
Something's not right with address 14fXr2UTa17CadcZ911N7TBFqMLpqsfNae

The same problem arose with Lottoshares here: https://bitsharestalk.org/index.php?topic=4879.msg64977#msg64977

AGS Explorer shows 566.53948028 AGS
Your number for this address is 56596237510000

The numbers aren't THAT far out, but other addresses don't seem to have this problem.
I'm curious as to the cause of the discrepancy...

Is it bad form to quote myself? Dunno...

Anyway, is there an explanation for the discrepancy for address 14fXr2UTa17CadcZ911N7TBFqMLpqsfNae?

The figures on AGSexplorer don't seem to match those reported for the genesis blocks.

It's happened with LottoShares and DNS. Will it occur with all DACs? It bothers me because I don't understand it...

365
KeyID / Re: [DNS] ** LAST CHANCE TO CHECK ALLOCATION **
« on: September 26, 2014, 09:35:26 pm »
Something's not right with address 14fXr2UTa17CadcZ911N7TBFqMLpqsfNae

The same problem arose with Lottoshares here: https://bitsharestalk.org/index.php?topic=4879.msg64977#msg64977

AGS Explorer shows 566.53948028 AGS
Your number for this address is 56596237510000

The numbers aren't THAT far out, but other addresses don't seem to have this problem.
I'm curious as to the cause of the discrepancy...

366
General Discussion / Re: Coinmarketapp is coming and BTSX is included
« on: September 26, 2014, 07:34:13 pm »
The screens look pretty slick but I don't like how they hijacked the coinmarket name for their own use.  They are NOT associated with coinmarketcap.com

i think this is a clever marketing step! The provide the marketcapapp so why not using the name ;) my 2 btsx

I like how you said "my 2 btsx". Clever, I think I may hijack that  :P

Why do people say, "my 2 btsx", when there's another phrase?

...Just my 0.02 BitUSD

367
General Discussion / Re: An open letter to Tonyk
« on: September 26, 2014, 07:12:37 pm »
This thread is actually really interesting. It's creating a paradox in my mind because I find myself agreeing with each post, even though this is contradictory.

So many viewpoints, all seemingly valid.

Empathy, tolerance and understanding are needed in this world. There's every point in having differing opinions, and criticism, because it can be constructive. If people could only be reasonable, there is no need for this to lead to serious conflict and fighting.

I reckon this forum as a whole is very balanced and reasonable, and this is great.

P.S. I started typing this, then had to do something before I could post it. I came back to see tonyk's comment:

Interesting thread. I should research this dude further...
But even before that I agree with all posts in the thread. :)
 +5%


368
Muse/SoundDAC / Re: BitShares Music non-technical paper. Updated.
« on: September 26, 2014, 04:31:59 pm »
Looks good cob!

Sorry, but I'm at it again with spotting typos. In part three it says, "Every time the song is or purchased".

Edit:

cob, I'd like to ask you something. There is an established band which I love. I think they may be interested in PeerTracks. When do you think would be a good time to try to get them interested? If they are interested will there be a special channel set up whereby PeerTracks work with artists to educate, assist and bring them onboard?

369
General Discussion / Re: dat peg doe
« on: September 25, 2014, 09:03:30 pm »
Nice! Exciting times we have here!

...shame I don't know what "dat peg doe" means!

370
General Discussion / Re: Add BitNXT?
« on: September 25, 2014, 09:00:35 pm »

...If you are allin on btsx or whatever, then you don't want to divest into bitNXT.  You are exposed to btsx issues without owning NXT...


I agreed with you at first, but then I thought, "Isn't that true of any BitAsset?". I suppose there is the fact the BitShares ecosystem and NXT are in relatively close competition, so we could have one failing whilst the other succeeds. Then you'd be absolutely correct!


On the other hand, some may believe that BTSX will continue to work well (and want to support the DAC), but also fancy hedging with NXT. Some may even fancy a small bet on the possibilty of NXT outperforming BTSX!

371
KeyID / Ideas for an alternative DNS model
« on: September 25, 2014, 07:32:09 pm »
I have some ideas for an alternative DNS model. Maybe they will deter squatting, and hopefully maintain profit for the DAC. They also enable people to keep a domain name indefinitely, without the possibility of rich competitors/bad actors forcing them to pay too much. It's kind of a hybrid of other ideas which I hope, with some improvement, could be workable.
This is a coarse, poorly written overview, and all numbers are made-up!


Key Points:
  • Domain names are leased (at least initially)
  • The length of the lease is variable
  • People can keep their domain name indefinitely
  • The model can be made straightforward for the end user (even if it's more complicated behind the scenes)
  • If a lease becomes prohibitively expensive because of a changing market, there is the possibility of the lease becoming cheaper
  • There are ways to lessen the negative impact of squatters
  • These ideas are far from optimized because of my lack of time and concentration
  • If there is an inkling of value below, the community can build upon it and add to it

If you want to create and obtain a new domain name you can start an auction. You place a bid to lease the name. If others join the bidding it is possible for them to vary the length of the lease, as well as the "price per year". One purpose of the variable lease length is to deter squatters (if we can ensure they are paying enough) by allowing the DAC to take a larger lump sum up front. This lump sum could possibly be held as collateral - I'll come back to this. A bid with a higher "price per year" but a shorter lease span would have to be weighted against a bid with a lower "price per year" with a longer lease span. There is a sweet spot in there somewhere. People should be able to bid successfully on a domain for a one year lease, even if people have bid for longer leases (they will just have to pay somewhat of a premium on the "price per year"). An algorithm would be needed to assign an optimal weighting to "price per year" against "length of lease". This increased complexity needn't put end users off. For example, the GUI could present them with a couple of sliding scales with "sliders". This would automatically indicate to the user the minimum price, or maximum lease span, which they can bid relative to their chosen parameter value, in order to lead the auction.

If, when leases are paid for, some of the 'money' is held as collateral, it could enable extra features (only part of the lease value would be collateralized, and the rest would immediately go to the DAC as profit). There would be the ability to give partial refunds on cancelled leases, or maybe a rewards system if domains add significant value to the DAC in some way.

If someone is mid-lease and they don't want their domain name anymore they can put it up for auction or cancel their lease. In either case they could be given a certain fraction of any remaining collateral. The collateral could be released such that it can only be used to pay for another lease on a different domain name (so potential squatters can't cash out, and the DAC gets more profit). The percentage of collateral returned to the leaseholder can be reduced so that people aren't incentivized to pay for long leases which they don't want, or to squat. Some percentage of the total collateral could even be used to subsidize the price of the domain for new bidders - although I haven't thought this part through! There remains some incentive to release a domain name if you don't actually want it, because you can use some returned collateral to pay for a different domain name.

When someone is coming to the end of their lease they can:
  • Let it expire (or auction it) and the domain will become available for others
  • Renew the lease at the same price they have been paying
  • Attempt to renew the lease at a cheaper price

Let me explain the idea of allowing people to attempt to get the price of their lease down. The assumption is that we want to allow people to keep their domain name indefinitely (I see this as a very valuable feature). It is possible that the market could change drastically after someone has obtained a domain name. They could end up paying absurdly high rates at some point in the future if there is never a chance to lower the lease price. For example, if leases are paid using the native token (BitDNS?), the price could rocket. This problem could be somewhat overcome by offering the option to the leaseholder to convert the “price per year” to another currency/asset/token, for example BitUSD. There would probably need to be a limit on the frequency with which these conversions are allowed.

If someone wants to attempt to get their lease at a lower price, the DAC needs to charge a fee, or restrict the frequency with which people can attempt this. The leaseholder can try to get it cheaper by going through a special kind of auction. Anyone can bid, but the original leaseholder will retain the option of keeping the lease at the original price, even if the bid prices go above this level. If people aren't bidding the price up to the original level the current leaseholder will be successful in getting a reduction on the lease price (there could be limits imposed on the amount of reduction). Obviously if the leaseholder doesn't wish to pay, the domain name must go to the highest bidder. For the users, there will have to be some way to clearly distinguish between this type of auction and the standard type.



Other options to consider:
  • If conditions necessitate, a minimum "price per year" could be set, perhaps for all leases longer than one year. The purpose is to discourage squatting (or people attempting to obtain many long leases at a cheap price). While the DAC is young, and the value of BitDNS is unknown, the minimum price could perhaps be set in relation to the value of BitDNS against BitUSD, using delegate feeds. Alternatively we could assuming that the DAC will be successful, the price of BitDNS will rise significantly with time, and therefore the value of the lump sum which was bid will rise as the lease progresses. This could negate the effect of buying the cheap, long leases, which would have been undesirable as far as profitability of the DAC is concerned.
  • Any user could send an anonymous alert to the current leaseholder of an existing domain, to communicate their interest in obtaining the domain. If such an alert is sent in relation to a domain name which has a lease with between one and five years remaining, the current leaseholder could be compelled to make a choice. They can either extend their lease to five years or more, or they can auction the domain name. This measure is to act against squatters, while allowing people to trial a domain name for a year unhindered.
  • Lease lengths could be measured in months (or less), rather than years.
  • Maybe there could be certain conditions whereby people could get a domain to keep freehold (i.e. to own outright with no more leasing).
  • Secondary tokens of some kind could be introduced, based upon an incentive structure, a bit like with like LTBcoins

372
General Discussion / Re: [ANN] version 0.2 of DNS/KeyID Genesis info.
« on: September 23, 2014, 05:30:25 pm »
Woops! I gave the wrong command. I'm so sorry, I'll edit my previous post.
I believe it should be:

wallet_account_update_registration <account_name> <pay_from_account> [public_data] [delegate_pay_rate]

So that would be:

wallet_account_update_registration nihao youxi null 50

373
General Discussion / Re: [ANN] version 0.2 of DNS/KeyID Genesis info.
« on: September 23, 2014, 03:36:26 pm »
Hi gamey,
I read your first post, but my wallet is in trouble since last week, it got stuck, mostly "not connected". And even for short while it's synced (with the bottom bar turns green), I can not make any payment, it even doesn't broadcast the transaction.  The wallet WAS OK two weeks ago, but now I'm not able to register delegate for my account.

I tried many time and many ways, including using the wallet update, re-creating the DB, running the client over night, uninstall/re-install, upgrading to 0.4.16.  but it doesn't work. frustrating... I will try 0.4.17 later...

But I don't want to miss my beloved ID, so could you please take it in? Thanks!

nihao BTSX6qgrfbfhc1CTu7zetkCXRxw8ggv6VWncCZKtgXChekTgwLmtov

PS.
Anybody can tell me what's wrong?
And if I want to report the problem, shall I catch some log to do it?

I was struggling with problems which were fairly similar to yours. In the end I thought I'd wait for the wallet upgrade then register a couple of delegates in time for the KeyID/DNS genesis block. Unfortunately there was no clear deadline, and the genesis block has now been finalized. As it stands we're too late.

I'd hope that if your ID "nihao" is put in the genesis block I might get a quick PM from gamey or toast asking what my delegates were too! :P
I'm not gonna hassle them much more though, because I think the workload has been a bit of a struggle.

P.S. flydragon are you asking for help to get the wallet stable or to register a delegate? I couldn't register a delegate with the GUI, and had to do it through the console. The first command I used charged a transaction fee but didn't register me. I got it to work in the end, I think I had to put:

wallet_account_register <account_name> <pay_from_account> [public_data] [delegate_pay_rate]
wallet_account_update_registration <account_name> <pay_from_account> [public_data] [delegate_pay_rate]

so for you this may look something like:

wallet_account_register nihao nihao null 100
wallet_account_update_registration nihao nihao null 100

P.P.S. After hassling toast and gamey, I thought I should contribute something, so I've tried to think of ideas for an improved model for the DAC. I'm gonna create a new topic with some suggestions, hopefully later today if I have time.

edited: corrected silly mistake - see strikethroughs!

374
General Discussion / Re: [ANN] version 0.2 of DNS/KeyID Genesis info.
« on: September 22, 2014, 09:03:40 pm »
Hi, gamey. I just registered my accounts as delegate today, do they still have chance to be recorded into DNS/KeyID genesis block? Thanks.

Toasted created a genesis block.  I am not sure when the live chain will be finalized etc.  It seems unlikely that we will recreate the whole thing because of all the steps and time, so changes at this point would be only for obvious mistakes etc.

For me also, this is a shame. I interpreted the first couple of posts in this thread to mean we could still get in the genesis block.
From the first post in this thread I tried to follow your suggestion, "If you are not included then CREATE a delegate on BTSX".

Reading the second post, "http://pastebin.com/ik1bZGyZ ... This is close to the final one.  I'll give it version 0.3", I thought I could still get a place in the genesis block. I spent some time trying to fix problems with my wallet. Then I had problems registering as a delegate, because it wouldn't work through the UI. I managed to get registered on 21st September in the end.

I'm not saying I expect anyone to do a load of work just to get me in the genesis block. If it turned out to be a doable step to modify the genesis block to include delegates to date, however, my disappointment would turn to joy!

That is all. :-*

375


The problem with the robots is all they all look the same except for their colors... Well they look different, but not in ways that we remember as people unless you have a robot fetish.



edit: gamey has a point - bytemaster looks at a glance like bitsapphire , only with a bigger head!

Pages: 1 ... 18 19 20 21 22 23 24 [25] 26 27 28 29 30 31 32