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.

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.

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.

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.

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.

* 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.

There is no built-in functionaliy for this, but it can be done client-side.

Your logic is sound except for one point:

That said, if we want a fixed exchange rate, we need to "break" the promises somehow, or to limit capital movement somehow. This sounds unacceptable for some people, but unfortunately it's the fact.

You don't need to break promises. You don't need to continue making the same promises while you're actively breaking them.

The original design of our SmartCoins favours free capital movement and independent policy over fixed exchange rate.

You prefer fixed exchange rate over independent policy. Fine. You can have that without breaking any promises: create a new type of SmartCoins.

We can remember we were feeding around +15% offset on bitCNY price when the premium was around 3%.

So margin calls were settled at 15% offset? With 10% MSSR you have rewareded shorters with 5% for not providing sufficient collateral. Good job. BitShares was always about right?