BANK RUN! - P2P Fiat-Bitcoin Exchange

[waxwing]

If it could be enforced that the payout from the multisig was either (1.1,0.1) to Alice and Bob, or (0,0) (they don't agree) then the system would seem relatively sound (i.e. it works with rational and error-free behaviour assumed). But encumbering a utxo to only spend to pre-defined outputs is not possible in Bitcoin.

Accentuation in the quote done by me.

Thanks waxwing for bringing that up again!
It is not possilbe to do this in btc directly, but with an oracle!
That would solve all the blackmail problems.

Make the deposit to an 3 of 3 multisig address. The 3. signer is an oracle proving that the spending tx is like it was defined initially. That can be verified with the hash of the outputs (need to investeigated in details how to do it but that shoud be not a problem).
When the 2 traders want to spend the deposit they need the signature of the oracle and that is another peer (or replicated server) verifying that the output match with the initial ones. If the output has changed the oracle does not sign. That is a fully automated process without any human involvement. The Oracle receive the tx, verify the outputs and publish it if it is valid.
That way any changed output due a blackmail is impossible to get published.

This is good thinking. At first glance it looks like the right approach. This is how oracles were intended to be - just verification of something objective.
The oracle being in possession of a signing key raises the security stakes of course, but that's handle-able I think.

The remaining question is how to implement the oracle. dansmith came up with an extremely clever scheme to make an effective oracle using an Amazon EC2 instance (you can read about it on the ssl logging thread) and implemented it in November. You can see detailed discussion kicking off from around this post: https://bitcointalk.org/index.php?topic=173220.msg3429555#msg3429555

We tried out the technology a few times and it seems to work well. However, it is a complex architecture and bases the trust in the oracle on a bootstrap of the trust in Amazon certificates, ultimately. I don't think this is a practical problem at all, in terms of validity and trust, to be honest, but building systems that way has its architectural limitations of course.
The problem is the lack of Zero Knowledge Proof working technologies - that's what's needed (look into SCIP for example) to make pure oracles.
In the absence of that, dansmith's style of oracle is a practical approach. It's just technically somewhat fragile so requires a lot of care and attention.

[1714064898]

1714064898

[calligrapher]

this is a great system as far as i understand.

please make it happen. i think the developers should focus on some projects like this. The funds or costs not important because pretty sure that there will be huge donations for a legit stable project.

[networthsigns]

I appreciate your idea. However, my humble request is correct spell and grammatical errors please. If I am able to spend time, I will lend a hand to you.

Good luck.

[syph3r]

The reason that the attack exists is that the power over the spending out from the multisig address is divided equally between the two parties, with no independent parties (arbiter, oracle etc.) having a say. To enforce a specific payout ratio requires something external - an arbiter, or some reputation cost at the very least.

After thinking about this some more, I agree with this.

If it could be enforced that the payout from the multisig was either (1.1,0.1) to Alice and Bob, or (0,0) (they don't agree) then the system would seem relatively sound (i.e. it works with rational and error-free behaviour assumed). But encumbering a utxo to only spend to pre-defined outputs is not possible in Bitcoin.

I think this is an interesting observation, but this may still be vulnerable to attack. Bob can still hold the transaction hostage, promising only to release it if Alice transfers some amount of BTC to Bob in another, unrelated transaction. Again, Alice is probably motivated to comply to minimize her loss.

[waxwing]

The reason that the attack exists is that the power over the spending out from the multisig address is divided equally between the two parties, with no independent parties (arbiter, oracle etc.) having a say. To enforce a specific payout ratio requires something external - an arbiter, or some reputation cost at the very least.

After thinking about this some more, I agree with this.

If it could be enforced that the payout from the multisig was either (1.1,0.1) to Alice and Bob, or (0,0) (they don't agree) then the system would seem relatively sound (i.e. it works with rational and error-free behaviour assumed). But encumbering a utxo to only spend to pre-defined outputs is not possible in Bitcoin.

I think this is an interesting observation, but this may still be vulnerable to attack. Bob can still hold the transaction hostage, promising only to release it if Alice transfers some amount of BTC to Bob in another, unrelated transaction. Again, Alice is probably motivated to comply to minimize her loss.

That is certainly a good observation, but as Manfred pointed out early in the discussion, this kind of "two-phase" blackmail is not a credible threat. Satoshi addressed it as follows (I paraphrase, I don't have the quote to hand) - if a counterparty blackmails you and requires upfront payment, they have already shown no trust, so why should you trust them that they will do what they say after you make that payment?

You see the critical difference? In that attack you and I described, there is one, atomic transaction. If blackmail involves more than one step, it is not going to work - the only rational option for the victim is just to default.

[syph3r]

Well I agree that in the "two-phase" blackmail scenario, the argument for Alice to comply is less clear since there's nothing forcing Bob to release the initial transaction once he receives payment from Alice. I would just point out, however, that this type of "two-phase" blackmail is attempted in real life, and the blackmailed party often complies, even if they have no guarantee the blackmailer won't follow through with their threat, or that no future blackmail will occur. In other words, in the face of large potential losses, actors do not necessarily behave rationally. If you concede that this is the case, it may be worth it for Bob to at least attempt a large number of blackmail attacks, hoping he'll find a target that complies with his request. This could result in a loss for all of Bob's targets, including the ones that don't comply. Whether this attack makes sense depends on how costly it is for Bob to initiate an attack, the potential reward of a successful attack, and the distribution of compliant victims.

[waxwing]

Well I agree that in the "two-phase" blackmail scenario, the argument for Alice to comply is less clear since there's nothing forcing Bob to release the initial transaction once he receives payment from Alice. I would just point out, however, that this type of "two-phase" blackmail is attempted in real life, and the blackmailed party often complies, even if they have no guarantee the blackmailer won't follow through with their threat, or that no future blackmail will occur. In other words, in the face of large potential losses, actors do not necessarily behave rationally. If you concede that this is the case, it may be worth it for Bob to at least attempt a large number of blackmail attacks, hoping he'll find a target that complies with his request. This could result in a loss for all of Bob's targets, including the ones that don't comply. Whether this attack makes sense depends on how costly it is for Bob to initiate an attack, the potential reward of a successful attack, and the distribution of compliant victims.

Yes, I have been thinking about this since I made the post and find myself having similar thoughts.

Take the case of cryptolocker. The reason that victims pay out is, at least partially, that the cryptolocker "team" has shown evidence of following up on their commitments. To be fair, the power asymmetry is absolute here - cryptolocker loses nothing in the default case. So it's not the same.

I came to the conclusion that the only defence is in the cost of identity creation. Even if you have a well defined reputation system, it can be somewhat subverted like this - the attackers can continually create a variety of identities and then in PM tell the victim their *real* identity (Hackers Inc), using a PGP key or something less technical but enough to convince the average user, and their "off channel" reputation as reliable in completing the transaction once ransom is paid will then come into effect.
To avoid that, the cost of identity creation has to be at least around the size of a large transaction, otherwise it might well be economically effect to carry out these "two phase" attacks. And in a purely P2P solution, how is the cost of an identity enforced anyway? Someone or something (an oracle?) has to be the arbiter of whether a particular identity has violated protocol rules.
The other alternative - a fidelity bond/sacrifice cost - each new identity destroys $1000 before starting to use the system - is hardly palatable.

[Cryddit]

I'm pretty sure that there's a good solution. 

I want to think about it for a while and work out the details, but right off the bat, we need to remember some of the tools that are available.

1)  A transaction to spend bitcoins from a given utxo can exist and be witnessed (possibly even signed) by both Alice and Bob before the utxo itself is created.  Either one may be "holding" this transaction and ready to release it when the utxo appears on the blockchain.

2)  A script can hash any secret and compare the result to a blob, releasing the coins to spend if the hash matches.  So if Alice creates the secret she can create a transaction that includes the hash of the secret, while never giving the secret away.  But if she uses the secret to spend the coins, then Bob can learn the secret from the blockchain - and that could enable him to spend a different utxo, possibly from a different transaction. 

3)  A script can release coins on any of several conditions.  For example, a 2-of-2 multisig *OR* a secret whose hash matches. 

4)  A transaction, even one signed by all parties involved, can be invalid until a given lock time - thus even if it is released on the network it will not take effect until someone has had a chance to execute a different transaction.   So in the event that someone is being obnoxious and refusing to cooperate, "refund" transactions could take place (or become available for the other party to exercise) after some delay if the obnoxious person refuses to go through with the original transaction as mutually intended.

I just can't believe that with all these tools available we can't manage to lock down the ratio of the final payouts before the money is sent to  the txout where it gets paid out from.

[k99]

The second case when Bob blackmail Alice I dont see that dangerous as Alice know his identity (bank tx). So she could use that to protect herself (lawyer) and Bob will be more cautious as he does not know if Alice could become mad and would threaten him. 

If you believe this then your protocol has no purpose. Alice can simply transfer some amount of money to Bob's bank account, and then Bob can transmit an equivalent amount of BTC to Alice, without the need for all this multisig business.

There is a fine difference. Bad intention or just failure without proof of bad intention.
Assume a navie protocal where Alice pays first then Bob. If Bob never pays and Alice appears with a laywer at his house, he always can say, sorry i had an accident, or was ill or forgot... nobody could proof he was a scammer.
In our protocol a blackmail is clear an attempt to scam. If Alice appears with a laywer at his house, he has pretty bad cards.
Knowing that Alice know his real ID from the bank details, he should fear some real troubles if he tries to scam Alice. He has no idea if Alice is a innocent girl or the sister of a mafia boss.

[k99]

I appreciate your idea. However, my humble request is correct spell and grammatical errors please. If I am able to spend time, I will lend a hand to you.

Good luck.

Sorry I am not native english speaker and my english is not real good I know.
If you have time to help out here it would be great. I send you a PM then I can give you write access.

[k99]

Well I agree that in the "two-phase" blackmail scenario, the argument for Alice to comply is less clear since there's nothing forcing Bob to release the initial transaction once he receives payment from Alice. I would just point out, however, that this type of "two-phase" blackmail is attempted in real life, and the blackmailed party often complies, even if they have no guarantee the blackmailer won't follow through with their threat, or that no future blackmail will occur. In other words, in the face of large potential losses, actors do not necessarily behave rationally. If you concede that this is the case, it may be worth it for Bob to at least attempt a large number of blackmail attacks, hoping he'll find a target that complies with his request. This could result in a loss for all of Bob's targets, including the ones that don't comply. Whether this attack makes sense depends on how costly it is for Bob to initiate an attack, the potential reward of a successful attack, and the distribution of compliant victims.

Yes, I have been thinking about this since I made the post and find myself having similar thoughts.
Take the case of cryptolocker. The reason that victims pay out is, at least partially, that the cryptolocker "team" has shown evidence of following up on their commitments. To be fair, the power asymmetry is absolute here - cryptolocker loses nothing in the default case. So it's not the same.
I came to the conclusion that the only defence is in the cost of identity creation. Even if you have a well defined reputation system, it can be somewhat subverted like this - the attackers can continually create a variety of identities and then in PM tell the victim their *real* identity (Hackers Inc), using a PGP key or something less technical but enough to convince the average user, and their "off channel" reputation as reliable in completing the transaction once ransom is paid will then come into effect.
To avoid that, the cost of identity creation has to be at least around the size of a large transaction, otherwise it might well be economically effect to carry out these "two phase" attacks. And in a purely P2P solution, how is the cost of an identity enforced anyway? Someone or something (an oracle?) has to be the arbiter of whether a particular identity has violated protocol rules.
The other alternative - a fidelity bond/sacrifice cost - each new identity destroys $1000 before starting to use the system - is hardly palatable.

I think the cryptolocker blackmail situation is very different:
1. As you pointed out asymmetry. He has no costs. Alice has cost of her collateral if Bob does not accept the blackmail. If the collateral is higher than in my example, say 50% or 100% then this are considerable costs.
2. Cryptolocker use one "identity" and people can predict his strategy, means that he holds his promise to unlock after payment.
Alice and Bob are changing random strangers. If Bob has the experience once that Alice has kept her promise, that experience does not mean anyhing that another Alice will act the same.

I think that blackmail scenario (2 phase) will not work when assuming a pure rational behaviour.
A rational actor would not accept because he has zero guarantee that the blackmailer will keep his promise. In fact the blackmailer has proven that he does not deserve trust, so to trust him again for paying and hoping he hold his word, is irrational IMO.

That does not mean that it cannot happen. The assumption of rational traders is a weak point as well.
A blackmail creates an irrational behaviour for the other party which could lead to the opposite behaviour of what the blackmailer was intending.
For me, I am pretty sure I would not accept it for pure principle reasons. I would hate that person and not pay him a cent. Even in the 1 phase scenario (then I would act irrational because of my anger, I would prefer to lose 1 BTC rather then to pay 0,5 to that asshole).
So it is very hard to predict how people will react when getting irrational. It is a risk for the attacker as well. Some could run amok and beat up the blackmailer (depending on the attack situation the ID is known to the other).

Another point is that due the bank transfer we are not dealing with a real global exchange. A bank tx from Russia to Chile will be very expensive, so they will not offer those trades. There are different risk levels in different countries and the people in those countries are more cautious as the are used to the situation. That could help as well to lower the real risk.

But it is still the question if we need additional protection (reputation system, escrow,...) to solve those problems.
Unfortunately all those solutions introduce new problems and are imperfect on their own (sybil,...) as well adding complexity which creates problem on its own (usability, security, bugs, new attack vectors,...).

For me it seems a better approach to keep it as simple as possible, limit the trade volume to a less hurting value, set the collateral flexible to the appearance of scams (if a lot of scams put it 100% or more, if low scam rate you can use a lower collateral) and maybe use a simple flexible mutual identification process (exchange facebook/twitter/G+ accounts,...).

A flexible combination could meet different needs as well.
If a user prefers to put in a high collateral and not use the mutual identification process it is ok as well. If the collateral is very low he will not find offer taker if he does not accept mutual identification.
It could be a flexible setup of a few simple adjustments which will never prevent scam to 100% but make it less likly and harder and more expensive for the attacker.

We also need to consider that there is no perfect save solution.
If fact many of our existing solution in the financial area are terribly insecure:
Credit cards would never have passed a security audit in the btc community. NEVER! It is a terrible concept.
Paypal the same.
But both are super mainstream.
Because they took into account a scam rate and covered the costs with a hefty fee. The credit card fees can be seen as an insurance fee.

What I want to say with that is we have to be also pragmatic. Many imperfect solutions work pretty well in reality.
That does not mean we should ignore weaknesses!
In contrary I am very thanksful for the good analysis posted here!
Thats the power of open source, 1000 eyes see more then 2 eyes.

We will keep on to investigate alternative protection mechanisms for the remaining open risks. Some are described in the paper (updated recently), others need more investigations.

For the more serious blackmail problem with the 1 phase blackmail attacker, I think we found a solution. I will post that in a new post extra... already way too long post....

[waxwing]

I just can't believe that with all these tools available we can't manage to lock down the ratio of the final payouts before the money is sent to  the txout where it gets paid out from.

I specifically asked on #bitcoin-dev whether it's possible in any way to encumber a utxo so as to fix its output in anyway. sipa told me it isn't possible and said I could take a look at the "coincovenant" idea for exotic ways to try to make it work (involves SCIP and so forth).

To be fair, it does kind of make sense that utxos should not be encumber-able, since that breaks the fungibility of coins. So, signatures enact control over utxos and can be all kinds of exotic things, but control of that utxo is binary - either you can demonstrate control with the appropriate signature(s), or you can't. No inbetween state - your signature entitles you to pay out to Charlie, but not to Dave. Maybe a coin or altcoin could work like that - I haven't thought about it much - but it seems bitcoin doesn't.

[waxwing]

2. Cryptolocker use one "identity" and people can predict his strategy, means that he holds his promise to unlock after payment.
Alice and Bob are changing random strangers. If Bob has the experience once that Alice has kept her promise, that experience does not mean anyhing that another Alice will act the same.

Ah, but please read my message again about how you can subvert a reputation system by simply revealing your *true* identity after establishing contact as "Bob" --> (Hackers Inc).

To repeat, I believe this highlights the need to enforce significant costs for identity creation, which itself brings up the point of how those costs are managed in a decentralised way.

[k99]

Here is a possible solution for the blackmail attack of changing the payout tx, sign it and send it to the other peer.
That is dangerous because it would be an atomic operation. The victim does not need to trust the blackmailer that he keeps his promise as he has already signed. The victim has the payment tx in his hand and if he sign and publish he gets a part of the money back. That would be a rational behaviour, so the Nash equilibrium is not met anymore.

dansmith_btc has brought up a great idea. Destroy the private key after signing, then nobody could blackmail you to change the payout tx, as you simply cannot do it without the private key.
Lets describe roughly the protocol how it could work (needs a bit more investigation and test with RPC calls to confirm if all is correct).

Bob creates a 3 of 3 Multisig address with 2 pub keys of him and 1 from Alice. Lets call Bobs keypairs Key1, Key2.
Key 1 is used for signing the payout tx after he has received the Fiat from Alice. Key 2 is used to make the output defined in the initial agreed payout tx un-changeable. He will destroy that key after signing, so Alice cannot negotiate later in a blackmail attack to change the outputs to her favor.

Bob creates the deposit tx.
Bob creates the payout tx, signs with Key2 and destroys then Key 2.
Bob signs the deposit tx and sends it together with the payout tx to Alice.
Alice signs the deposit tx and publishes it.

At that moment Alice was with the old protocol in the attack scenario where she could blackmail Bob as Bob has more funds locked.
Now she know that Bob has deleted the key (the software works like that) and Bob has no chance to change the payout tx. The one and only payout tx which can be ever used to release the funds is singed by Bobs Key2 which is already deleted. So no way to create a different one with other outputs.

She has to continue in the protocol to not lose her collateral.
She pays in the Fiat to Bobs bank account.
She signs the payout tx and sends it to Bob. That tx has now 2 signatures: Alice and Key2 from Bob. Key1 from Bob is missing.
After Bob has received the Fiat in his bank account he signs the tx with Key1 and publishes the tx.

But there is still a second attack scenario.
Bob could have secretly kept Key2 (he used some tool to create the payout tx and not destroy Key2) and now try to blackmail Alice. He can create a new tx to his favor and sign with Key1 and Key2 and send it to Alice. Then if Alice would be rational she would take that, sign it and publish it to get at least a part of the payout.

To prevent that we can simply build in the key deletion in the step when Alice signs the payout tx.
If the software deletes the key, Bob knows Alice has no chance to sign a new tx with changed payout.
The one and only valid payout tx is the initial one.

Thanks dansmith_btc. We have a new nice tool in the limited btc toolbox.  

[k99]

To be fair, it does kind of make sense that utxos should not be encumber-able, since that breaks the fungibility of coins. So, signatures enact control over utxos and can be all kinds of exotic things, but control of that utxo is binary - either you can demonstrate control with the appropriate signature(s), or you can't. No inbetween state - your signature entitles you to pay out to Charlie, but not to Dave. Maybe a coin or altcoin could work like that - I haven't thought about it much - but it seems bitcoin doesn't.

Yes probably Satoshi has had good reasons to not allow that.

[k99]

Ah, but please read my message again about how you can subvert a reputation system by simply revealing your *true* identity after establishing contact as "Bob" --> (Hackers Inc).
To repeat, I believe this highlights the need to enforce significant costs for identity creation, which itself brings up the point of how those costs are managed in a decentralised way.

Yes you are right. But still point one stays valid, he has costs. The relation of costs and acceptance rate will be the key.
If 33% of people would accept a blackmail and the collateral is 50% he would lose for sure.
1 btc trace, 0,5 btc collateral. blackmail deal: both get the half.
deposit tx has 0,5+1,5=2
if he win he gets 1 so a net win of 0,5.
if he loses he loses 0,5.
if 2 times lost: -1
one time win: +0,5
sum -0,5
He will not do that often...

Of course if the accept rate is high and the collateral low he will hit the "break even".
The attack is more dangerous in the 1. scenario (Alice is blackmailer) as in the 2. with the bank tx Alice has the id of Bob.
So Bob has additional risk if trying to blackmail (maybe an  irrational dangerous Alice).

To protect agains scenario 1 we could also introduce asymmetric collaterals so both have the same to lose.
If Alice has to put in 1,1 as collateral and Bob 0,1 collateral + 1 for payment = 1,1 then Alice has no reason to blackmail anymore.
Bob knows she would lose the same, so he would be very irrational to accept if Alice want e.g. 2 btc and would give Bob 0,2 btc.

We have a few diffent weapons to fight all those blackmail risks:
1. Collateral height -> costs for blackmail
2. Low trade volume -> low gain when blackmail, less reason for accepting a blackmail
3. Alice provide identification to Bob: Facebook/Twitter/G+, web page, blog, forums, present in web cam documents which Bob request,... If Bob is not 100% convinced he can cancel.
4. Asymmetric collateral. Alice pays in the same as Bob. Increases the blackmail risk in scenario 2.
5. Use feedback from statistical analysis of the trades tx in the blockchain and/or sentiment of scam rate from postings in forums
to adjust the recommended collateral height.
 
We can let the traders mix those elements in a way like they prefer.
So Alice could make an offer with 50% coll. and accept asym. coll. as well as identification check from Bob, so it will be easy to find a trading partner as it seems she is very trustful, and therefor she will get a better price as well. If Alice is on the other extreme, then the peer should be carefully and better not trade with her.

[k99]

I'm pretty sure that there's a good solution. 

I want to think about it for a while and work out the details, but right off the bat, we need to remember some of the tools that are available.

1)  A transaction to spend bitcoins from a given utxo can exist and be witnessed (possibly even signed) by both Alice and Bob before the utxo itself is created.  Either one may be "holding" this transaction and ready to release it when the utxo appears on the blockchain.

2)  A script can hash any secret and compare the result to a blob, releasing the coins to spend if the hash matches.  So if Alice creates the secret she can create a transaction that includes the hash of the secret, while never giving the secret away.  But if she uses the secret to spend the coins, then Bob can learn the secret from the blockchain - and that could enable him to spend a different utxo, possibly from a different transaction. 

3)  A script can release coins on any of several conditions.  For example, a 2-of-2 multisig *OR* a secret whose hash matches. 

4)  A transaction, even one signed by all parties involved, can be invalid until a given lock time - thus even if it is released on the network it will not take effect until someone has had a chance to execute a different transaction.   So in the event that someone is being obnoxious and refusing to cooperate, "refund" transactions could take place (or become available for the other party to exercise) after some delay if the obnoxious person refuses to go through with the original transaction as mutually intended.

I just can't believe that with all these tools available we can't manage to lock down the ratio of the final payouts before the money is sent to  the txout where it gets paid out from.

Re 1:
Are you sure with that? I think that in the 2. tx you need the tx id from the first, so if tx1 has not been created you cannot sign or even create the 2. tx. If you meant that tx1 is not published then I agree. Or maybe I misunderstood...

Re 2: yes that could be powerful, but I have not found a way how it makes sense in our protocol.

Re 4: I was looking for a way to use locktime to make a refund. But I think there is no way in our protocol as Bob would lie that he recieved the fiat and would wait for the timeout to get back his funds.

[Duane Vick]

I see a few things that has to happen to absolutely remove the threat of blackmail. First, the BTC seller has to already have the funds in a state of transfer before cash is sent. Second, the parties to the transaction can't have a say in the final disposition of BTC.

For the first thing to happen, a temporary address has to be created and the coins have to go there so that the seller can't avoid following through with his obligation in the transaction. On settlement, the buyer can simply receive the private key to this address.

For the second thing to happen, there has to be an escrow agent(s) to determine the proper disposition of the held coin. Agents would also need a way to verify the fiat transfer and the presence of the correct amount of BTC in the temporary address according to the contract terms.

I discussed a way to make this possible earlier in this thread and also started my own thread to discuss it. https://bitcointalk.org/index.php?topic=475874.0

Perhaps there is a way to incorporate it into this project.

[dansmith]

@Duane Vick
Your first an second points are valid and they both have been solved for Bankrun.
First, the seller's BTC are locked in a multisig address (a.k.a escrow address) before the buyer sends fiat.
Second, all possibilities of blackmail are removed by having both parties sign a transaction disposing of escrow address coins in only one agreed-upon manner. After that both parties' signing key are deleted by the software.

[Spekulatius]

Maybe the following scenario has already been discussed in this thread, but I missed it:

Bob wants to sell his BTC to Alice so he sends his BTC and colleteral to the multisig address.
Alice agrees to the trade and sends her colleteral to the multisig adress to lock the funds.
Meanwhile the price rallies which is not uncommon for BTC so Alice has second thoughts about her commitment to Bob.
She decides to keep the funds locked up until prices have come down, after all only her colleteral is locked in the tx and she spend the fiat on something else.
...
Bob gets angry with this fancy new program and decides to hit the pub.


What I have described here is a common problem for low latency trades such as localbitcoin or similar. In times of heavy price movement many trades get aborted.
I think the issue could easily be fixed by higher colleterals according to volatility.