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 - tonyk

Pages: 1 2 3 4 [5] 6 7 8 9 10 11 12 ... 221
61
I have no idea who "for-gary" was voting for, but it's quite obvious that "garylarimer" wasn't voting for anyone, since it just claimed its funds 6 hours ago...
http://cryptofresh.com/u/garylarimer

well, I did not ask for it, but if they wish to explain the justification behind the 35 mil BTS sale from the  trust account ...I am listening!

or how a non voting account managed to bring the total votes down by 6 mil

or any other Good explanation you have.... you seem to have one for any case. I am just curious.

62
I will greatly appreciate the history voting api calls that you can provide me with... where you saw they were not!

Just take a look at the links I included.

Your wording indicated they were voting with BM as proxy before but now they are not.

The blockchain though says they were never proxied to BM/angel etc. There is no record at all in them even setting a vote. It's just going to the default nobody.

I know the name... but I never assumed they all vote with BM as proxy.

Unless there is something I missed in reviewing their accounts that someone else can show me, I think you might have misread or not looked closely enough at their transactions.

You seem to be right.... the I3's accounting department needed to absolutely update their vote from "nobody" to the more important and up to date  "nobody"....I am sure it makes sense ....

the total of  bm + angel 's votes falling by similar amount does not though.....

63


http://cryptofresh.com/u/for-gary

http://cryptofresh.com/u/garylarimer

There is nothing in their history to indicate they were ever proxied to begin with.

Where do you see this?

To be accureate I will quote it for you cause you "decided" not to do so....
>>>>"voting/ having BM/angel as a proxy."

let see http://cryptofresh.com/u/garylarimer
Multisig Auth hyperetas

If the name does not speaks volumes to you...I get it.... you think you are old, but you are a baby....

This is the payroll account of I3 (for all those unaware.... not just you bunker )

PS
There is nothing in their history to indicate they were ever proxied to begin with.
Where do you see this?
I will greatly appreciate the history voting api calls that you can provide me with... where you saw they were not!

64
General Discussion / Larimer...please explain this voting move for me
« on: March 29, 2016, 02:43:10 am »
Just when the first refund worker get within 400K bts from the last work - worker , those 2 accounts (http://cryptofresh.com/u/for-gary and garylarimer ) decided to do the most weird thing of all...
stopped voting/ having BM/angel as a proxy.

I really do not get the move... is it a pathetic way to 'show' that.... "those diluters do hurt development".


If not what the f**k is this move all about????

65
The anti-dilution movement is fueled by this 'without reason' thinking.... we can try and apply all the weak reasoning ideas we can come up with.. but at the end of the day it all amounts to nothing but wishful thinking in the hopes that those perpetrating it are doing it out of some semblance of rational/reasonable/good intentions which is directly contradictory to their own words and actions.

I agree with svk...
From what I see the ANTI anti-dilution  movement declares all arguments for responsible spending  'stupid' or completely ignore them and continue claiming no such were made
The other tactic is claiming 'anti-dilutioner' somehow try to destroy BTS while the reality is ALL workers are well and voted in.
I know it will be too much to ask, having in mind the above behavior, but how about accepting for a second "dilution is generally not good right now, we have to try to prove or at least argue why this particular spending will be beneficial!" Every worker explaining in detail how his work will increase the market cap despite the dilution it will cost.
What I mean is addressing concerns upfront, instead of putting labels on groups and claiming they mean bad before their actions have prevented a single worker getting paid .

Wow, did you just suggest they're voting like this because of some far-fetched conspiracy involving Ethereum? A far more plausible answer would be that they're sick of Bitshares hard-forks and emergency hotfixes every couple of weeks and would like things to stabilize a little.

I don't think you're interpreting alt's post the right way, but as his English isn't the best it's certainly up for interpretation. In my opinion he's just saying he'll not vote for dilution workers no matter what at this point in time. Claiming that everyone anti-dilution are fueled by mindless stupidity is just ignorant, but you don't seem to want to listen to any arguments to the contrary. Everyone seems to want to frame this in terms of war terminology, "it's an attack on Bitshares" etc, perhaps that's just a product of our times, but doing so gets us nowhere.

You're putting words in alt's mouth saying he doesn't want more development for years to come and that he wants Bitshares to die, but nothing supports that theory. He simply has a different perspective on what is good for Bitshares in its current state, and since there's no direct correlation between development and market cap who knows, he might just be right. Like I said Fox's efforts had nothing to do with BTS development or worker proposals so it in no way supports your argument, in fact it supports alt's position.


66
General Discussion / Re: Bitshares price discussion
« on: March 27, 2016, 04:47:11 pm »
support at 1500sats is growing, but still touchy

How do you mean? There is a total of 220 BTC support all the way down to 308 sat.
Just for comparison in the last 30 min 314 BTC worth of BTS changed hands.

It is for sure very dangerous situation

67
General Discussion / Re: Let's try to get @bitshares on twitter
« on: March 27, 2016, 04:39:11 am »
If the worker doesn't get voted in I'll keep it and monetise it myself but it's obvious to most it would be better controlled by the comittee or cryptonomex.

I don't think that committee members should be required to take any part in marketing. Their job is to set blockchain parameters and that's enough for a nonpaid work.

Also Cryptonomex seems to be uninterested in marketing so accounts might be left underused if they are given to them.

Right now the best option might be that you'll gather a group of people who are interested and can post relevant stuff every now and then. I use Facebook quite regularly so I can be admin there if needed.

Maybe you could first ask donations to cover you expenses before you make the worker proposal? All donations you collect makes the worker less expensive so it gets voted in more easily.

I agree xeroc or crytonomex wouldn't be good at or have the time for marketing.
I'm saying it should be owned by cryptonomex or the committee, but key people who are good at marketing can post from the account so the news is fresh and varied. Yet if one person gets too spam happy the committee will be able to stop it.

message me your facebook details and I'll add you so you can post. Also anyone else who would like to.

Hello @JonnyBitcoin . This seems like perfect timing. We would love the New Money project to have access to the Bitshares accounts. Our project right now is gaining a lot of traction and it would be stellar for those accounts to be promoting a powered by Bitshares project thats actually working currently as we speak. Let me know what we have to do to make that happen. Thanks.

For god sakes.... NO!
You are  really pushed me hard to post a (possibly last post of mine  on this forum)  in your thread.

68
General Discussion / Re: About workers: 1.14.35/36Fund to pay dividend
« on: March 25, 2016, 05:28:46 am »
After being taken the ability to actively vote against ideas like this... I find myself pretty much agreeing with the approach...

Let distribute all available fund to stake holders and then finance any development we find appropriate on a case by case bases.


what?
This will be "voting 'for' only" brought to its purest form...


69
General Discussion / Re: refund worker only has 32M voter , oh oh ,
« on: March 24, 2016, 06:20:52 pm »
It's not the case. With or without the feature, it's almost same difficulty for BM to vote in workers (when most of other voters/stake holders are rational). But with the new feature, it's harder for attackers to vote in their worker(s), so more secure.

Some people may ask what's an attack? Create one or more worker(s) which will take effect (get funds) immediately and vote in it without any explanation why it should be voted in.
^^ this!

^^ that!  +5%

I was aware of this BUT removing the negative vote makes it much easier for an exchanges to vote  workers in, if they so wish.
 Before we collectively could vote against it and remove such workers...not anymore.
So 'more secure' in this regard is true, but it is not more secure in general.
No.. it's not easier or harder for an exchange to do so, before the hard fork, although we can vote against an exchange's worker, the exchange can vote against all other workers, and/or create a new worker.

At this moment, exchanges has too much power, we can just hope them don't act bad. One stake votes for one committee member could be an option to limit exchanges' power. With this, the committee can at least disable worker pay.
It is easier. Before you can tell everyone "hey there is this real real bad player come and vote against it ". What can you say now "hey there is this real real bad player come and vote for someone else you do not quite like just so you can get rid of this bad guy" ?

//edit
and as I was writing that... this happens https://bitsharestalk.org/index.php/topic,22051.msg287078.html#msg287078

What I am expected to do now? Start voting for workers I do not like? Just wait for BM to vote for a refund worker (just to cut this non sense of an 'offer')?

70
General Discussion / Re: refund worker only has 32M voter , oh oh ,
« on: March 24, 2016, 05:24:01 pm »
It's not the case. With or without the feature, it's almost same difficulty for BM to vote in workers (when most of other voters/stake holders are rational). But with the new feature, it's harder for attackers to vote in their worker(s), so more secure.

Some people may ask what's an attack? Create one or more worker(s) which will take effect (get funds) immediately and vote in it without any explanation why it should be voted in.
^^ this!

^^ that!  +5%

I was aware of this BUT removing the negative vote makes it much easier for an exchanges to vote  workers in, if they so wish.
 Before we collectively could vote against it and remove such workers...not anymore.
So 'more secure' in this regard is true, but it is not more secure in general.

71
General Discussion / Re: refund worker only has 32M voter , oh oh ,
« on: March 24, 2016, 08:23:54 am »
Thanks! for the numbers.

The margin between actual and refund workers are small. So it seems, it will all depend on the vote of guys like mindplux and how they change their voting style. Right now he/they have not seen an actual worker they do not like, while also voting for refund/burn workers...
Depends more on BM..

//Update: added the very original "refund400k" worker

Yup...my original statement
BM: "It will be easier to vote workers in" and your observation in the last post seem to be the case.
And you are right...it was done for security reasons... what is more secure than BM voting in anyone he likes, anyway???????????

72
General Discussion / Re: Several workers voted out, please support
« on: March 24, 2016, 08:08:30 am »
To clarify:

The reason for this "voting out" is not because those workers have lost support, but because the approval voting for workers no longer uses *down*-voting.
You can read about it here: https://github.com/bitshares/bsips/blob/master/bsip-0015.md

Anyway, thanks for checking your votes

Yes , I can confirm. BM is able to vote all workers in with 35 mil less  BTS!
Hurray! ...Hurray!  Hurray!

Let's see if we can keep it with even less BTS? Who will volunteer to dump another 35 mil?

73
General Discussion / Re: A case for Demurrage bitUSD (dUSD)
« on: March 24, 2016, 07:55:37 am »
I would prefer a way to favour shorts/covering shorts at the point of sale, but as I can't think of one, even though I don't like demurrage, I think you make a good a case for dUSD.

well I think you bother too much with stuff that makes sense.... initiatives for shorts; interest for longs...all in an attempt to make smart coins work.

We should just buy  1/Google of the "solar and nonsense" token and live our lives, pretending it makes any sense.

74
General Discussion / Re: Subsidizing Market Liquidity
« on: March 24, 2016, 03:37:52 am »
tonyk Your proposed changes make sense, but continuous monitoring is much more complex than sampling*. What does it capture that sampling can't? And what if samples were e.g. 15 mins apart?

@roadscape
OK, how about a middle ground - taking the snapshot every 10 (20, 30 whatever) minutes BUT also reading the filled orders in that period and using them for the calculation[effectively adding them to the orderbook like they were not filled]?
We can do 2 diff things - either credit them for the whole time period or really check when they were placed and  filled and credit them with the correct real time they were on the book.

####
thisTimeIntervalStart = now() - 10 min
For each filled order in time [now, thisTimeIntervalStart]
      T = OrderFillTime - max(OrderPlacementTime,  thisTimeIntervalStart)
       order_total = size of the Filled Order
####

My question is, what scenario are you trying to avoid (or create) by doing this?

If your order is on the books for 120 mins, and is *completely* filled at minute 125, you would not get credit for those last 5 minutes (assuming 10-minute snapshot interval). To me this doesn't seem like a problem.

If you expect orders to be on the books for less than 10 minutes at a time, I could see why we would need to be tracking this more detailed order activity.

My original line of thinking was a simple "sharedrop" of points onto order book participants at a regular interval.

My assumptions for MM subsidies:
1) The actual market activity doesn't matter nearly as much as creating a nicely-shaped order book.
2) 'Sampling' the order book every ~10 minutes is at least 95% as accurate as analyzing continuous data.
Obviously (I thought), I am trying to avoid orders being on the order book for 30% -99% of the time between sample taking, and such orders getting no credit at all. To say nothing about such orders being filled first, means they had the best prices of all orders!!!
The less the time between sample taking the less an issue this becomes, but your original proposal was every 1 h. (way too long in my view). The smaller the time between each sample taking the less an issue it is. (so if you cut it to 3-5-7 min, this is a one way to do it)
Yet, again the proposed solution will yield ' near perfect'* results even if you sample far less frequently... and the computations involved seem to take not too much recourses.

* It is not perfect, cause if you sample once every hour, you should also credit the "placed and subsequently cancelled" orders, meeting all other criteria, in that time frame.

75
Oh, federated peg. What a wonderful word. Really trustless? @tonyk
and others...

I am talking about this:
"Once Bitcoin adds special opcodes or extensibility to validate SPV proofs as a hard-fork,
and once the new system is proved secure and trust-free, the Federation role as STTPs will
no longer be necessary, and the RSK team will implement the changes to adapt RSK to the
trust-free system."
It talks about sidechains blockstream style... If all the rest of the promises of RootStock are met (super fast, VMs blabla) and it is indeed this great new thing, all BTC has to do is add this operation to their script(arguable not even a hard fork but a soft one) and has trustless sidechain.
They will not do it for us today (even if BTS was ready and willing to use it) but they will do it for their own better BTC (aka RootStock). And then BTS will have to stay with Federated/Witnessed trust system; or be the second (yet another) sidechain using the trustless mode.

Pages: 1 2 3 4 [5] 6 7 8 9 10 11 12 ... 221