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

Pages: 1 ... 64 65 66 67 68 69 70 [71] 72 73 74 75 76 77 78 ... 102
1051
General Discussion / Re: BitAsset 2.0 Requirements & Implied Design
« on: May 05, 2015, 11:16:28 am »
My assumption was you could short to yourself.  It seems to me the way to balance the market.. You either buy BitUSD directly or buy BTS and create BitUSD if it's the cheaper option and you have  collateral.  Self-shorting is an important option but if we combine it with forced settlement I can imagine a manipulator accumulate $2 mil in BTS over time.. Exchange $1.5 mil BTS for BitUSD or short to self over time...then use 500k BTS to wait for low volume and sell BTS heavily at once and force liquidation on depressed BTS feed prices...is this a possibility?
AFAIK that's what the 24h notice is good for .. so that the price feed can recover ..
Also note that anything you do in the DEX is public! .. so you should be able to identify market manipulation .. in contrast to centralized exchanges..
The 24h notice doesn't help against the attack. The attacker only has to delay his BTS dumping until just before the settlement.

Also, detecting market manipulation doesn't help if the attack is executed quickly and anonymously.

1052
Stakeholder Proposals / Re: Developer delegate: dev-pc.bitcube
« on: May 05, 2015, 06:36:17 am »
Thanks a lot!

1053
Stakeholder Proposals / Re: Paid Workers Proposal for Review
« on: May 04, 2015, 06:36:04 pm »
Personally, I would like to see the Core DEVs get additional 30 paid delegates rather than changing the allocation rule again.
+1 (and to be clear here: those 30 or whatever should go to the *core* team in blacksburg)

1054
Stakeholder Proposals / Re: Developer delegate: dev-pc.bitcube
« on: May 04, 2015, 04:50:02 pm »
Work / accounting report for April: http://bts.quisquis.de/delegate/report.html

1055
Stakeholder Proposals / Re: Paid Workers Proposal for Review
« on: May 04, 2015, 04:28:37 pm »
Who will decide, for example, on graphic related tasks, if an design is finished in view of requirements, graphic style, sustainability?
On technical side requirements are much more clearer to communicate ... but for esthetic etc. purposes ... who will decide if a job task is solved?
(used the designer example ... you know why^^)

Couldn't delegates decide on this?

I think nobody wants to have certain delegates (like me) make decisions concerning graphic style. ;-)

1056
Stakeholder Proposals / Re: Paid Workers Proposal for Review
« on: May 04, 2015, 08:28:15 am »
How about a bounty exchange platform with an Ask/Bid?

This is essentially a bounty auction and exchange platform. It is completely algorithmic in approach and completely automated. It determines the true market price of any kind of labor by reaching the equilibrium point between the supply and demand through the bid/ask.

It would be centralized at first but could be made decentralized, it's also a way to determine who would be selected for the bounty in a completely automated fashion.

It may even allow workers to trade jobs on the exchange provided they do so before the expiration date. This way if a worker bit off more than he could chew he could exchange his bounty with someone else and they'd get paid in his place if they complete it.

Instructions
As the employer first you'd put up your bidding price which is the highest you're willing to pay, then a bunch of potential bid fillers put up their asking price and according to the algorithm it would meet in the middle according to supply and demand at an equilibrium point. This would give the market the true price of the labor.
Input: Employers enter a job description and bidding price to be displayed as the maximum bounty reward.
Input: Employees/Job hunters enter their asking prices, mapped to their Keyhotee IDs.
DAC: An algorithm selects the employee willing to work for the lowest asking price (lowest bounty reward)
DAC: A bot sends an encrypted message to the public key of the Keyhotee ID address and sends a bounty token to their wallet.
DAC: The transaction and exchange exist entirely in a blockchain so that if necessary anyone with that bounty token can exchange their bounty token for anyone else's.
Output1: The job is completed by the expiration date on the bounty token, and the bounty token is redeemed at the true price of labor in the market.
Output2: The job is not completed by the expiration date and the bounty token is never redeemed, therefore it is invalid and expired.
Social Contract: 50% Protoshares, 45% Angelshares, 5% Promotion, Discount and Giveaway shares

What could go wrong? Someone could lose their bounty token and then the bounty would expire wasting valuable time. On the other hand it would save time if someone can trade their received bounty with another person or split their bounty with another person all in automated fashion by using the divisibility of the bounty token. So if I did 90% of the labor and I could not do that final 10% then I could break off 10% of the bounty token and give it to anyone willing to work for it.

Let me know if this idea could work?


^^^^

The gist of the idea is to create a job auction exchange. Jobs are auctioned on the blockchain. A UIA could represent a job and when the job is done all who have the asset can redeem for BitUSD.

Of course it would have to be simplified due to the limitations of the blockchain but ultimately the market should determine things. Let anyone bid for positions. Let the community for up or down the positions from which could be bid for and let the community set the amount it is willing to pay in some algorithmic fashion so that the jobs are auctioned to the lowest bidder.

http://www.jobauctions.com/

IMO an automated DAC is unsuitable for matching workers and jobs, because for an employer the price is only one of many criteria for selecting an employee. An employer may want to hand over a job to a more skilled/experienced worker even if he has to pay a higher price.

You proposal is missing a crucial component: who gets to decide when/if a job has been completed? You're going to need arbitrators in case of a dispute.

Also, managing such a platform creates a massive overhead for the employers and may be unsuitable for small tasks.

1057
Stakeholder Proposals / Re: Paid Workers Proposal for Review
« on: May 03, 2015, 02:55:10 pm »
Step 3:   Pay out projects in order of total approval once per day until all 432,000 BTS has been consumed.

This all-or-nothing approach is an even bigger problem. Suppose I propose development of some specific feature that will take me 6 months to complete. I get voted in and start working. After 3 months, someone bigger is voted in above me, leaving me with no payment and an unfinished product. That's a lose-lose situation.

(If you expect voters to act rationally and not vote me out after 3 months I suggest a reality check. :-) )

1058
Stakeholder Proposals / Re: Paid Workers Proposal for Review
« on: May 03, 2015, 02:49:42 pm »
IMO the general payment scheme sucks, because it inevitably leads to centralisation of any kind of development. As bm's specific proposal shows, it is much easier to present a large proposal for funding some kind of company than expecting individual contributors to come up with their own proposals and work on having them voted in. The current scheme is much more flexible wrt the many smaller contributors that we currently have.

The specific proposal for more adequate funding for today's core devs makes absolute sense.


1059
General Discussion / Re: BitShares 0.9.0 Feedback
« on: May 02, 2015, 07:41:54 pm »
I had several wallets with unregistered (TITAN) accounts interconnected with wallet_add_contact_account. After upgrading to 0.9.0, the contact_accounts are gone, and wallet_account_transaction_history shows public keys instead of account names for related transactions.
wallet_list_contacts show the corresponding public keys, but the label is equal to the key.

After setting a label with wallet_add_contact <key> <label> I can transfer to the labelled account, but the tx history on the sending side shows ANONYMOUS as recipient, and on the recieving side it shows UNKNOWN as sender (where at least in one case the sender is actually a registered account). Also, the receiving side does not show the memo anymore.

1061
BitShares PTS / Re: what do i do with my pts @ cryptsy
« on: April 29, 2015, 07:03:47 pm »
For the PTS-DPOS transition the snapshot date was back in December  '14. If you had PTS in your account at cryptsy at that time, cryptsy can claim PTS-DPOS for your old PTS and forward them to you. So you have to ask them.

1062
Technical Support / Re: purpose of LC_ALL="en_US.UTF-8"
« on: April 29, 2015, 05:00:08 pm »
It is required for building because the compiler (and other tools) must know how the source files are encoded.
I'd assume that most systems today have UTF-8 encoding configured per default, but it's better to be explicit there.

1063
My impression of the various BitAssets n.0 proposals is that we're in trial-and-error mode regarding the economic side of our product. I'm not an expert on economics, yet I wonder if we're approaching our problems in the right way. Specifically, I think our flagship product, market-pegged bitassets, has shown remarkable stability *despite* a serious drop in the valuation of the underlying BTS collateral *and* a few nasty bugs in the market engine. If the current bitassets are not the problem, then why propose to change them? (That's only a rhetorical question.)

My questions are these:

* I'm somewhat familiar with the theories around market-pegged assets, and I understand that a consequence of a demand for bitassets will be more demand for BTS and in turn a higher price for BTS. Obviously, this theory does not match our current reality. Have you researched/discussed where the bug in the theory is? Is the theory based on wrong assumptions, or does it draw wrong conclusions anywhere?

* Are you aware of or have you researched methods to simulate the BitShares economic system in a way that could test the underlying theories and maybe explain why the theories are wrong? Is something like that feasible at all? Would it make sense to test new market theories (like bitassets n.0) before implementing them?

* Have you researched/discussed the possibility that the price drop of BTS could be a direct consequence of the mechanisms surrounding the market-peg (as opposed to a more or less independent side effect like shareholders losing trust)?

1064
Technical Support / Re: Spammed by "automatic market cancel" messages
« on: April 29, 2015, 07:32:04 am »
I've been bitten by a similar bug before. There's a github issue for it, but I can't find it right now. I thought it had been fixed. Edit: https://github.com/BitShares/bitshares/issues/923

There's a short on the SILVER:BTS market where the remaining collateral is not sufficient to cover .0001 SILVER. Such a short should be cancelled automatically by the market engine, but apparently that's not working.

In the console, enter
Code: [Select]
wallet_account_order_list
This will list your open market orders. Find the short in question, note its transaction id (that's the long hex number at the beginning of each entry), and cancel that order with

Code: [Select]
wallet_market_cancel_order TX_ID

(replacing TX_ID with the transaction id).

1065
General Discussion / Re: Potential Gridcoin to BTS sharedrop enquirey
« on: April 27, 2015, 10:34:24 am »
It's only implemented in PTS 2.0, it lets you import a wallet by using a signed message.

Thank you SVK.  How hard would it be to port it to the other chains?

You'd have to reimplement it from scratch if you want it in a BTC clone. BTC handles transactions in a completely different way than BTS.

But the basic idea is portable of course, and it would be my recommended way of handling this.

Pages: 1 ... 64 65 66 67 68 69 70 [71] 72 73 74 75 76 77 78 ... 102