Bitcoin Forum
May 04, 2024, 07:06:53 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: P2P asset freezing protocol for Bitcoin  (Read 724 times)
oxfeeefeee (OP)
Member
**
Offline Offline

Activity: 73
Merit: 10


View Profile
November 15, 2013, 08:08:44 AM
Last edit: November 15, 2013, 08:35:36 AM by oxfeeefeee
 #1

P2P asset freezing protocol for Bitcoin.

There are some scenarios that the first party gives bitcoins to the second party just to let then freeze the BTC, in which requires unnecessary trusts. For example on Just-Dice.com, investors send way more BTC than the house needs to get more profit share, and the operator holds a huge amount of BTC in code storage just to freeze it.

This problem can be solved by "freezing address", from which the BTC can only be "spent" back to where they are from. For example, if Alice needs to freeze some amount of BTC of Bob's. Alice creates a freezing address, which can be verified by any one that it is a freezing address. Then bob verifies the address and send the BTC to that address. At this point, both Alice's and Bob's private key are required to spend the BTC, but Alice has to option to abandon her right by send back the BTC to Bob's original address, which unfreezes the BTC.

Cryptography is not my field but my guess is, with the bitcoin script system this can be done. Is this kind of system proposed before, or is it somewhere on the roadmap?


EDIT:
In the case of Just-dice.com,  investors would have to deposit to two addresses, one for freezing and another with much smaller amount for investing. Basically you make you btc frozen by the operator in exchange for the right to invest. For example:

Old system:
Total investment: 10,000
Max profit: 10,000 * 1% = 100
Your investment: 100
Your max lose(per bet): 1
Your trust the operator with: 100

New system:
Total investment: 1,000
Max profit: 10,000 * 10% = 100
Your frozen btc: >=100 (this 10x freezing rate is just an example, it's up to the operate to decide.)
Your investment: 10
Your max lose(per bet): 1
Your trust the operator with: 10

1714806413
Hero Member
*
Offline Offline

Posts: 1714806413

View Profile Personal Message (Offline)

Ignore
1714806413
Reply with quote  #2

1714806413
Report to moderator
The network tries to produce one block per 10 minutes. It does this by automatically adjusting how difficult it is to produce blocks.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1714806413
Hero Member
*
Offline Offline

Posts: 1714806413

View Profile Personal Message (Offline)

Ignore
1714806413
Reply with quote  #2

1714806413
Report to moderator
dicenow
Member
**
Offline Offline

Activity: 94
Merit: 10

dicenow.com


View Profile WWW
November 15, 2013, 08:41:27 AM
 #2

use of leverage is indeed very useful, but i think it doesn't belong in the protocol. it is trivial for sites to allow their own built in leverage. for example a fiat exchange can allow you to buy 10x bitcoins and only require you to hold 10% funds as collateral for margin. for your gambling example, https://dicenow.com already has investor selectable leverage from 0.25% to 30% risk per bet.

it doesn't make sense to add this to the protocol, because there are too many variables unique to each use case. how much leverage to use? what are the situations in which the site can perform a margin call and force liquidate the user? these are best left to each specific application's use of bitcoin.

also, you have to trust the operator 100% regardless, because they need the power to liquidate your position at any time (exchange: due to sharp movements in in price) (gambling: whale won, you lost) and take your coins. there is no purpose in setting up some mutual trust account since alice requires complete control over bob's onsite coins. it would only accomplish to show that bob isn't using dangerous amounts of leverage on alice's site, and actually has coins in reserve. does that really matter though? if bob wants to take ridiculous risks, let him. everyone else can keep their unleveraged coins safe in a cold wallet, or some other productive use generating returns (instead of frozen)
oxfeeefeee (OP)
Member
**
Offline Offline

Activity: 73
Merit: 10


View Profile
November 15, 2013, 08:52:28 AM
 #3

use of leverage is indeed very useful, but i think it doesn't belong in the protocol. it is trivial for sites to allow their own built in leverage. for example a fiat exchange can allow you to buy 10x bitcoins and only require you to hold 10% funds as collateral for margin. for your gambling example, https://dicenow.com already has investor selectable leverage from 0.25% to 30% risk per bet.

it doesn't make sense to add this to the protocol, because there are too many variables unique to each use case. how much leverage to use? what are the situations in which the site can perform a margin call and force liquidate the user? these are best left to each specific application's use of bitcoin.

also, you have to trust the operator 100% regardless, because they need the power to liquidate your position at any time (exchange: due to sharp movements in in price) (gambling: whale won, you lost) and take your coins. there is no purpose in setting up some mutual trust account since alice requires complete control over bob's onsite coins. it would only accomplish to show that bob isn't using dangerous amounts of leverage on alice's site, and actually has coins in reserve. does that really matter though? if bob wants to take ridiculous risks, let him. everyone else can keep their unleveraged coins safe in a cold wallet, or some other productive use generating returns (instead of frozen)

I see what you mean, but in JD's case, everybody would just use the max leverage, then nothing would change. Because it doesn't necessarily raise the risk, as most people don't bet high.

Also this could be used in all kinds of cases, to name two:
1. P2P trading: the seller freezes btc before mailing stuff --> buyer gets stuff and send btc to real addr --> seller unfreezes the original btc.
2. IPO oversubscription.

One point of Bitcoin is to replace the greedy Wall Street with pure program, this is just one example.
dicenow
Member
**
Offline Offline

Activity: 94
Merit: 10

dicenow.com


View Profile WWW
November 15, 2013, 09:07:05 AM
 #4

I see what you mean, but in JD's case, everybody would just use the max leverage, then nothing would change. Because it doesn't necessarily raise the risk, as most people don't bet high.

Also this could be used in all kinds of cases, to name two:
1. P2P trading: the seller freezes btc before mailing stuff --> buyer gets stuff and send btc to real addr --> seller unfreezes the original btc.
2. IPO oversubscription.

One point of Bitcoin is to replace the greedy Wall Street with pure program, this is just one example.

not everyone will use max leverage after a few catastrophic losses by investors, since max leverage is extremely dangerous and could wipe them out if a whale won.

for p2p trading, a proper blockchain escrowed multi party transaction implementation would be amazing. not this freeze thingy

for ipos, lots of variables to deal with. let everyone send their coin to a transaction, and have the transaction hold code to determine priority and share allocations? lots of things to think about. it would be even more complicated than the use case of your freeze scenario.

i agree, crypto currency has all encompassing use cases that will upturn the whole financial industry as we know it. but i think your main beef is the fact that dooglus won't implement any features to reduce counter party risk. let's face it, as the current leader he doesn't need to. investors simply have no say in the matter since additional dilution is unwelcome. but it probably won't always be this way, competition will ensure that coin apps which mitigate counter party risk have an advantage over those that don't.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!