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] 2 3 4 5 6 7 8 ... 94
1
General Discussion / Re: suggest to disable forcesettlement for bitCNY
« on: November 07, 2018, 12:55:23 pm »
From all the previous discussion around BSIP-42, my understanding was that this situation indicates an oversupply of bitCNY.

Shorters can now buy bitCNY on the market and reduce their own debt positions, which should reduce supply, drive the market price down and improve their collateral ratio, thereby reducing the likelyhood that they will be settled.

No need to change the rules yet again IMO.

2
Quote
a. ElasticSearch Plugin
https://github.com/bitshares/bitshares-core/wiki/ElasticSearch-Plugin
ES has been a good plugin. It has provided a very comprehensive unstructured storage and an indexing of historical transactions and objects on BTS. By the way, ES gives us a lot of inspiration.
But there are some shortages,

1) Cumbersome. ES requires extremely high performance for the server;
2) The synchronization time is too long, lacking of a fast-built solution. Currently, as far as we know,  the usage of ES Plugin for data query or data analysis is limited.
3) Some content (such as related information of the transaction) is not structured. Indeed, ES stores them directly, which cannot satisfy some customized queries.

What makes you think that Postgresql will be better in that regard?
* ES scales easily and was designed for cluster installations, postgres wasn't.
* Synchronization time for Postgresql will most likely be even longer than for ES.
* Operation details will be structured in ES plugin in upcoming release.

3
Thanks for your answers!


Quote
All "write access" to chain state happens exclusively through normal operations, correct?
Correct. The call_contract is also a normal operation, which also has write access to chain state happens.

Quote
How is authentication / authorization handled there?
Just simple like in other operations. Here op.sender is an impacted account (operation signer); the sender must sign the transaction containing this operation.

Please clarify. If the smart contract wants to create or issue an asset, or transfer tokens to an account, does it have to sign the corresponding transaction? That would mean the script needs to know the private keys, which sounds like a bad idea.

Quote
Do these contract-generated operations end up in the blocks?
Yes, as in the Ethereum, all internal transactions and events log can be visible.

Quote
That would open up the possibility that the VM is implemented as a plugin that is mandatory only for witnesses.
No. It cannot be done. Read-only nodes must also run a virtual machine to check the correctness of the chain.

If the operations generated by the EVM scripts become part of the blockchain they can be executed by themselves, without running the VM. This would open up the possibllity that nodes run without an active VM. It would also greatly speed up replay.

Note that normal nodes also don't validate transaction signatures. They rely on the witnesses to do that. Witnesses would have to run with active VM of course. They need to keep an eye on each other.

Quote
IMO committee-defined fees / GAS price is not capable of reacting quickly enough. An alternative might be to let the committee define a minimum GAS price and a maximum amount of GAS per block, and "auction off" the available GAS per block to the pending call_contract operations.
IMHO, this is not an actual task for DPoS: the transaction speed is fast enough; by default, all transactions are queued. If you allow users to offer their gas price, then you also need to manage the transactions in the queue so that those who pay a higher price - go first. Now we consider it does not appropriate to alter the logic of adding transactions to the block.

Executing many scripts will take much longer than applying normal transactions. It is inevitable that there will be times when more call_contract operations are queued than can be executed within a single block. Hence my question about a total GAS limit per block. The logic of adding transactions will therefore have to be altered anyway (as well as the handling of pending_transactions).

When the limit is reached, witnesses will have to select which contracts to execute and which not to. It seems natural (and from the POV of a DAC also profitable) to select the most-paying contracts. Note that these situations can appear and evaporate within only a few blocks, much too quickly for the committee to manually adapt the GAS price.

4
I'd opt for no.
Saying yes even once opens a big can of worms and means we'd have to evaluate every such request. Committee could be DDoS'd :D

If there is no real reason why "allow issuer to override transfers" has been left on (@abit?) i'd be in favour of disabling it.

+1

5
General Discussion / Re: New mechanism to handle bad debt (black swan)
« on: October 23, 2018, 11:48:30 am »
Punishment doesn't work on the blockchain, because we only have accounts not identifiable individuals. With your punishment suggestion, everybody would just use sockpuppet accounts for shorting (and these sockpuppets don't even require LTM).
There is also no point in flagging defaulters in any way, because traders trade against the book, not against individual accounts. You typically don't know with whom you're trading (nor do you care).

In fact I think @abit 's suggestion is worse for shorters - in a BTS downtrend, most of them (except one) are effectively bailed out by the current black swan rules.

6
General Discussion / Re: Economic Abstraction and Network Fees
« on: October 17, 2018, 09:05:23 pm »
You can pay the network fee for any operation using any (unrelated) asset if it has BTS in its fee pool and a "core exchange rate" defined.

For example, Alice can transfer bitBTC to Bob and pay the fee in bitUSD. What happens then is that the blockchain takes the bitUSD from Alice's account, exchanges them for BTS (using the bitUSD fee pool), and pays the network fee in these BTS. That's what xeroc meant with "implicit exchange".

7
General Discussion / Re: New mechanism to handle bad debt (black swan)
« on: October 17, 2018, 06:33:07 pm »
BSIP-18 doesn't guarantee recovery either. If BTS continues to go down, neither solution will help.

@abit 's suggestion is better than BSIP-18 because it limits the damage to only the undercollateralized positions, while leaving the rest of the market intact.

8
General Discussion / Re: New mechanism to handle bad debt (black swan)
« on: October 17, 2018, 04:57:17 pm »
Wait this doesn't make sense. If a debt position is < 100% CR, lets say 80% CR, then this new account will take the 80% CR BTS and buy the bitasset and burn it? But the problem is that an extra 20% of the bitassets was issued by the blockchain. Effectively, the blockchain is "printing bitassets" out of thin air?

No, the new account will try to buy the 100% debt for the available 80% CR. This is probably to far away from the market price, so the order will stay on the book. As soon as the price recovers, the order will be filled and the full debt will be repaid.

(In reality, with MSSR > 0, the account will try to buy 100% debt for 110% CR. For large positions this will result in the same premium that we have had with the old margin call rule, at least temporarily until the feed price adjusts.)

9
Thanks, Yury! An interesting proposal.

Is it correct that script execution is exclusively triggered by call_contract operation? I. e. it is not possible to have scripts triggered by e. g. incoming payment, order execution, market price changes, block time, etc.? That would make things much more controllable wrt time spent on contract execution per block, but would also severely limit the usefulness.

All "write access" to chain state happens exclusively through normal operations, correct? How is authentication / authorization handled there? Do you support bundling operations into all-or-nothing transactions?

Do these contract-generated operations end up in the blocks? That would open up the possibility that the VM is implemented as a plugin that is mandatory only for witnesses.

What happens when a call_contract operation is rolled back, e. g. if it was part of a transaction with a subsequent operation that failed? Is the GAS fee also paid in that case?

Since BitShares is operating with very tight timing constraints, is it possible to limit the total amount of GAS spent per block? IMO committee-defined fees / GAS price is not capable of reacting quickly enough. An alternative might be to let the committee define a minimum GAS price and a maximum amount of GAS per block, and "auction off" the available GAS per block to the pending call_contract operations.

10
General Discussion / Re: Critical Review of bitUSD by an academic at LSE
« on: October 13, 2018, 08:26:35 am »
> Anyone with BitUSD can settle their position within an hour at the feed price.

I was assuming seconds at most. Is an hour at all competitive with other currencies?  I know that at most times there will be market-makers buying and selling much faster, but in volatile markets the prospect of being locked up for an hour should really scare traders, particularly shorts.

Forced settlement is meant to be the last means to get something out of your long position. Trading should normally happen on the market, not via forced settlement. The delay exists to prevent abuse.

The way this will all collapse is though a fall in crypto collateral values.  As this starts to happen some shorts will want to cover their BitUSD positions so they can sell the collateral and cut their losses, so BitUSD may even spike up, but the collateral sales will further depress prices.  Soon some short position will fall below $1 collateral triggering forced settlement on all contracts within an hour.  I assume collateral would fall further during that hour because this is how crises always work, so the end settlement price may be quite a lot lower than $1.  In theory this should be good for shorts but in practice they have lost too much on their collateral that they won't really notice, so nobody winds up happy."

True, has already happened for some bitassets. Like all other financial systems, our has its limits too.

If this economist has time I'd like to hear his opinion on the discussion in the BSIP-42 thread. :-)

11
General Discussion / Re: Announcement on BSIP42 relevant actions
« on: October 12, 2018, 06:00:49 am »
1) Do you support an experimental MSSR of 0 as an incentive to keep shorts in the game and not penalize future bts collateral holders?

Yes. The current price feed modification is interfering with the MSSR in a bad way that renders the intended penalty moot and leads to a price feed that is further away from the real price than necessary.

We cannot aim for a tight peg *and* force margin calls to buy above the market price, at least not without a hard fork.

12
General Discussion / Re: Announcement on BSIP42 relevant actions
« on: October 11, 2018, 12:28:04 pm »
3. To receive the cut of the MPA market fees, the user has to place market sell order on MPA:Collateral asset (e.g. bitUSD:BTS) market.

There are several problems here.

First, this does not prevent yield harvesting. A shorter can sell the asset to himself (i. e. to his sock puppet account) through the market, thus avoiding all risk associated with being either long or short.

Second, this is unfair on users who not only trade in the asset but who also want to use it as a fiat replacement. If they short without selling, or (presumably) buy the asset without repaying their debt, they are punished by being excluded from the market fee share.

13
General Discussion / Re: Announcement on BSIP42 relevant actions
« on: October 09, 2018, 12:03:56 pm »
* settlement price (price feed) - This is the price that is used for margin calls as well as force settlements.
* MSSR - the max premium a shorter needs to pay (from market) in case of margin call
* MCR - The minimum collateral necessary for call positions, if lower -> margin call

You missed the settlement offset.

14
General Discussion / Re: Announcement on BSIP42 relevant actions
« on: October 08, 2018, 12:20:02 pm »
1. I don't think debt positions are "hurt" by forced settlement, because settlement happens at the fair price. (But that's an old argument.)

2. It should be possible to keep a balance using smartcoin parameters. E. g. with the settlement offset the debt position receives a reward for being settled.

15
Technical Support / Re: Can my coin pay dividend in form of BTS?
« on: October 05, 2018, 04:27:21 pm »
There is no built-in functionaliy for this, but it can be done client-side.

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