|
Title: Contract Providing a Deposit Problem? Post by: Staizita on April 19, 2019, 12:12:16 PM According to the example of the Providing a deposit in the bitcoin wiki, https://en.bitcoin.it/wiki/Contract#Example_1:_Providing_a_deposit (https://en.bitcoin.it/wiki/Contract#Example_1:_Providing_a_deposit)
I found that even if the user is malicious, the malicious user can't be punished (no loss of money). Code: Obviously, if the user turns out to be abusive (i.e., a spammer), the website will not allow an early close of the contract. Are there contract methods that can punish the malicious user? Title: Re: Contract Providing a Deposit Problem? Post by: ABCbits on April 19, 2019, 05:04:41 PM It's impossible on permission-less/decentralized system such as Bitcoin unless the malicious act happens on Bitcoin network and can be verified by Bitcoin full-node client.
For example, on LN if a dishonest-party attempt to broadcast older transaction commitment, another party can activate/broadcast "punishment" transaction which takes all dishonest-party coins. Title: Re: Contract Providing a Deposit Problem? Post by: d5000 on April 19, 2019, 05:42:07 PM ETFBitcoin is right, a total "loss" (as punishment) for the abuser is only possible if the abuse can be verified by the Bitcoin client.
The only way I see is to set nLockTime so late in the future that de facto it will become a loss (e.g. several years) and the "normal" way would be to close the contract earlier. You could slightly improve (but not completely solve) the incentive problem: Imagine an agreement between user and service owner where you initially agree to a very high nLocktime value, but with every week or so you use the service without abusing it, the service owner signs a transaction with a nLocktime value that expires earlier. However, this depends on the good-will of the service owner. Making the abuse "verifiable" like in LN, however, in most cases is not practical. Imagine an e-mail service that is set up in a way that a public message, verifiable by every Bitcoin client, is broadcasted with every e-mail the user sends (you could even set up that in a way that the user must sign this message with every mail he sends, so the service owner couldn't cheat). If the user exceeds a certain "quota" he then could lose his Bitcoins. But in this particular case the service owner could simply configure his service in a way that prohibits exceeding the mail quota. It's hard to imagine a case where preventing "overuse" with a simple configuration is not possible. (This anti-spam solution (https://bitcointalk.org/index.php?topic=5037458.msg46146669#msg46146669) I posted last year is very similar to the example in the Wiki, with the difference that no multisig is required.) |