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

Pages: 1 [2] 3 4 5 6 7 8 9 ... 51
16
Quote
The funds were originally assigned for BlockTrades to perform work it considered of sufficient importance based on my judgement. As such, I consider the funds mainly should still be allocated for such usage, unless I think there's a case where I decide someone can do something of high importance cheaper/easier.

What i concern is the fouds if it still belong to BTS community?

If the BTS community have the power to take back it? as the mechanism of the worker pay will need to redesign.
The funds remain under control of BlockTrades and are still being retained for emergency use only. I have not sold them and will not sell them except I think it is required for the purpose these funds were originally allocated for. So, for now they are effectively "dead coins" unless there is a Bitshares emergency that requires them to be spent. They are certainly having no impact on the price of BTS.

The BTS community has the power to take it back in the same way it can take back any funds: it can fork the chain. But it would be a stupid reason to fork the chain, IMO.

I have no idea what you mean by "the mechanism of the work pay will need to redesign". What do you want to be redesigned? Do you mean that you want to be able to take back vested funds from a worker without a fork? And if so, why? Because you are unhappy that I sold my company's BTS? This has nothing to do with the funds for the worker. I would never sell off these funds except for the purpose I originally committed them to. This can easily be seen when you consider that I've held these funds even when bts was worth 0.40 USD and also that I still haven't sold them, despite selling all my company's BTS.


17
One more thing I should say, with regard to statement that "blocktrades is only bridge", by which I think you mean that when someone sells a coin to us, you expect us to then sell the coin soon after. It's important to note that this isn't how we actually operate.

We don't have any automated selling that takes place when someone sells us a coin. Many times in the past, when someone sells us a lot of coin, I just hold it. If you don't believe it, you can just watch our accounts, you will see that there is no such automated selling.

To some extent, BlockTrades functions as a "contrarian investor": when other people are selling a coin we will often just accumulate what they sell to us because people often "panic sell", and vice-versa, when they are buying we often will let our inventory of that coin decrease (except we have to keep enough to continue selling it) on the theory that people will often buy a lot when their is a lot of FOMO and the price can rise too high because of the excitement, so we wait until excitement dies down before buying back into the coin.

But in the case of BTS, once I decided that things were going badly, I made it a policy to avoid holding too much, so whenever anyone sold us a lot, I would generally sell it over the next couple of days, to prevent losses as the coin continues to drop in price. Until I see some change in the way BTS is being handled, it's the only safe thing to do I think.

It's not the first time I've made such a decision, of course. There were some other coins where I didn't like the way the coin was behaving, so lowered our inventories of such coins to avoid losses (nushares comes to mind). Sometimes this is just temporary decision: when SBD was much more than $1, I thought it wasn't reasonable for it to be so high, so I kept our inventory low until the price came back to around $1.

18
As a side note, CN community didn't say any bad words to BEOS all along, some supporter of BEOS come from CN community.
Yes, I know, there were other people that spoke badly about BEOS, but they were not Chinese. It wasn't even a lot of people, I think, but the ones who spoke were very loud and persistent in their complaints. Mainly funket/fav, and also a few guys who had disagreements with Stan in the past, so that I think they were biased against any project involving Stan.

But in the world of marketing, it is generally the people who speak loudly and often who have the most impact, unfortunately. This is especially true when new people come to look at BTS because of BEOS, then see these complaints, I think they often may decide to leave both coins alone and invest elsewhere. Fighting between coin supporters looks bad.




19
As a side note, another long term BTS supportor (not a BEOS guy) asked me privately today why I had sold my holdings, and when I told them, they not only agreed, but told me they had sold for similar reasons.

20
It's incredibly stupid to blame the price drop of BTS on any of my selling. I sold off all my holdings  a while ago (about 35M BTS). But it wasn't my selling that drove down the price: in fact, during the week when I sold off my holdings, the price barely moved (I sold slowly to avoid driving the price down). I sold off most of my holdings for around 0.03 USD.

IMO, The reasons BTS has continued to go down is exactly the reasons I sold out:

1) Infighting between the various groups of "bts supportors".
* I hoped that BEOS would help the price, but when I saw the negative reception that BEOS got from various loud individuals in the community, I decided that their yelling would dilute any positive effect from BEOS.
* Inability for devs and large voting blocks such as cnvote to get along. The terrible uncertainty about the future development of BTS that this has created is incredibly damaging to the coin's price.
* Above are two of the most egregious examples, but I've seen several other conflicts as well. This continual fighting looks very bad for anyone looking to see the attitude of current BTS supporters.

2) The infighting was making me question continuing to hold my BTS, but the final straw that caused me to sell was the pricefeed fixing. This was an incredibly bad idea and obviously cheating the system. The problem is that BTS shorters were allowed to vote with their collateralized BTS that should have been "at risk" and hence not available for voting, because this led to misaligned incentives: normally BTS holders should value BTS price and not try to cheat because it devalues the coin, but in the case of shorters they risked losing all their BTS if they didn't falsify the price, so it made sense for them to cheat despite the damage it does to the coin price (something is better than nothing).

When it was clear the pricefeed fixing was going to happen, I immediately began quietly selling off my holdings. This is the only defense a minority holder of the coin has against a majority vote that decides to cheat the rules.

In retrospect, with the price around .015 USD now, I'm very happy with my decision. I was severely disappointed to see BTS turn out this way, but ultimately it was a simple design flaw that took it down. There's always the possibility at some point that the design flaw will be fixed. If so, I'll consider buying back into the coin.

21
General Discussion / Re: Prospectus for BlockTrades public offering
« on: December 02, 2019, 06:10:38 pm »
We're doing well, busy on a lot of projects. As I've made more money, I've grown increasingly altruistic, however, and I think we've made enough to plan the project I'm truly passionate about nowadays (a web of trust based system), so I'm less sure about doing an IPO for BlockTrades nowadays, unless it turns out that development costs for the project are more than expected.

22
I've cast my vote for this worker. Since the major investment has already been made, it seems like a bad business decision to drop it at this point.

23
BEOS / Re: Update on jurisdictional agility code progress
« on: August 15, 2019, 02:57:46 pm »
Is there a judgement that establishes the principle that a transaction is bound to the jurisdiction where it is *first* included in a block?
I always wondered about that argument - also, in an actual case, I supposed the witness will have to provide evidence that the machine that produced a block was in deed located
in that particular country, right?
As you probably know there's little established law around blockchains per se. Mostly it's an application of existing rules. There are existing rules that cover when/where a transaction is considered to have taken place in an internet-based transaction, and for a blockchain, I think the most reasonable assumption is that it is when a transaction gets included into a block. I'm sure someone could also try to make an argument for the block when the transaction becomes irreversible, but for many blockchains irreversibility doesn't even really exist as a concept, so I think the block where it gets included is a much more logical choice.

Quote
Last but not least, I also think that the block producers should be able to whitelist/blacklist contracts that they want to (are allowed) to execute. Just imagine a block producer supporting
the sale of securities or a smart contract for assassination, drugs, or other weird stuff. If I was running a block producer on a jurisdictional agile blockchain, I would expect to have means
to protect my block producer against liabilities that come from a smart contract, right? Are there any plans to add that feature?
I don't see that there's any real risk that a block producer will be liable for including a valid transaction into a block. In the normal course of block production, a block producer isn't going to have any special knowledge about the legality of the transactions he is including in a block, and trying to change this would be too burdensome on block producers.

Now, if it was some "special purpose" blockchain, where it was clear the purpose of the blockchain or some operation on the blockchain was specifically designed to handle payments for assassinations, or something similar, then it could be a different story. But I doubt anyone is going to be eager to develop such a blockchain or operate as one of it's block producers.

24
BEOS / Update on jurisdictional agility code progress
« on: August 13, 2019, 04:59:41 pm »
BlockTrades is about 1-2 weeks away from completing the code to upgrade the BEOS blockchain to support jurisdictional agility. Here's a steem post with full details:

https://steemit.com/beos/@blocktrades/jurisdictional-agility-in-beos

25
::) interesting.. what about your gateway?

We only operate a bridge on BitShares (i.e Bitshares accounts can trade coins directly with our automated trading platform).

We disabled our gateway many years ago. We only setup the gateway initially as a real-world testing system to develop our gateway technology (which we license to other companies) and didn't really promote it, so it was never a significant revenue source for us. At the time, OpenLedger was providing a reliable gateway (and we were maintaining it for them at that time), so it also didn't make sense for us to compete with our own customer.

26

Back to the topic, 7 million BTS seems a bit too huge in comparison to such small bounties. Now we already have a core dev worker to cover the maintenance job which was intention of this worker. Since we haven't yet decided how to use this fund, given the fact that most workers on chain now are being paid via escrows, I propose that we move the remaining funds of this worker to be controlled by an escrow service (for example BBF) or merge it with the core dev worker, if we still want to use it to fund core development / maintenance. We do want experienced project manager and developers to help and contribute, not only funds. On the other hand, if we're going to use it to fund other things, which would be out of this worker's scope, IMHO it's best to re-vote.

It's not my intent to use it for small bounties. I only mentioned that particular issue as I considered it of enough significance that I would be willing to fund it as I don't yet have time to assign someone to work on it.

The funds were originally assigned for BlockTrades to perform work it considered of sufficient importance based on my judgement. As such, I consider the funds mainly should still be allocated for such usage, unless I think there's a case where I decide someone can do something of high importance cheaper/easier.

I will not abuse the trust the original voters placed in my judgement by mis-using the funds. But IMO the funds should not be placed in someone else's control unless I make that decision without external pressure. And I would generally feel uncomfortable doing even that, because if I made the wrong decision, the funds could be abused and I would no longer be able to prevent it, so it would have to be someone I trusted at a level that I trust only a few people in this world. I hope you can understand my position on this.

If you feel that more funds need to be allocated to development at the current time, I suggest you create additional worker proposals and seek approval for the same. The great thing about BitShares is we do have an awesome system for polling the will of the holders, even if it has some flaws.

27
Another issue is should proxy in DPOS work for 1 level or multiple levels? Please feel free to give your comment.
https://github.com/bitshares/bsips/issues/79
I left my comments on the issue.

28
Please be aware that there are still 7,072,500 BTS unclaimed in this worker. I guess it's unused? So perhaps make some good use with it, or return it to the reserve pool?
I'm aware of the unclaimed funds: I don't tend to forget such sums of money, especially when they've appreciated like BTS has since they were allocated. My intent for the usage of the funds remains unchanged from my previous statements about it: I'll draw upon them for work I think especially important to the future of the chain.

So far, I haven't had time to do much BitShares development work personally for a while due to commitments to other contracts, but that is changing soon. As a first step, recently I've begun reviewing the "state" of the project to determine areas where I think some work could be beneficially focused and also doing a small amount of contract work to customers interested in BitShares (the contract work was totally paid for by the customers and didn't involve changes to BitShares itself, so there was no reason to charge the maintenance funds for it). I won't be able to devote a large amount of my own time until my current commitments are completed (somewhere in next 2 to 6 months I hope), but I plan to involve some of our engineers in development work prior to that time (I introduced the guys to the concepts of UIAs, for example, yesterday).

One thing I would like to see now and would be willing to fund for a reasonable price from the allocated funds: an onchain or offchain solution to the bug where the vote counts aren't available for committee members that aren't presently elected. To me this seems like a distinct weakness in the governance system.

29
BlockTrades has signed a number of NDAs as part of its normal business, but none are, in my opinion, against the interests of BitShares blockchain/community.

If we're going to check about such things, we might also want to get people to post a periodic statement that they have not been served with any gag order by a government body.

BlockTrades has not currently been served with any gag order.

30
IMO, the current implementation is flawed and should be changed to match the best offers first, like normal exchanges do. A rational person wouldn't buy at a worse price, and it's possible to construct an automated system that avoids such irrational buying under the current blockchain rules. So the current behavior just functions as a penalty  on inexperienced users (and experienced users who don't want to trouble themselves to figure out something that an automated system could do automatically).

One proposal was to just modify the wallet clients to perform such automated buying, but I'm strongly of the opinion that the correct change is to change the current order matching implementation at the blockchain level. It's a relatively simple change I think, other than it will require a hardfork and some decent testing.

Pages: 1 [2] 3 4 5 6 7 8 9 ... 51