iwillimust
Member
Offline
Activity: 64
Merit: 10
|
|
March 27, 2014, 05:24:24 PM |
|
So one day in the near future, maybe 2 - 5 years out, when 1% - 5% of online transactions take place in Bitcoin, and 1% - 5% of the stock market has moved to Counterparty, I think it becomes obvious that pretty quickly it will no longer be feasible to run your own node that actually keeps the entire blockchain. Anyone have any thoughts on that ?
You think I think it is very creative Why can you talk about your ideas Very interested in
|
|
|
|
CryptoFinanceUK
Newbie
Offline
Activity: 39
Merit: 0
|
|
March 27, 2014, 05:32:39 PM Last edit: March 27, 2014, 05:43:44 PM by CryptoFinanceUK |
|
Does any sort of collateralization requirement denominated in XCP limit the total amount of assets that can be traded on the exchange to the market cap of XCP? How do you work out the margin requirement? Or is the idea that any asset in one's possession can be used as collateral, but represented as an XCP equivalent?
In a world with XCP backed assets, one way I could imagine this working would be that the current market price of the asset (based on a price feed) would be locked away when the asset was created, and the issuer would place a bet to cover future variations in the price, up to a disclosed bet size, and future date. An issuer could choose the amount of margin they want to put up, and when they run out, the asset would be automatically liquidated. This would have the side effect of dumpling an asset holder back into XCP if a market got volatile, but I think it could dramatically reduce counterparty risk (and everyone would know were they stood). When issuing a $1 USD token, an issuer would lock away $1 worth of XCP to create the asset, and might choose to commit, say, another 25% to cover variation. So $1.25 worth of XCP might be locked away per USD token. They could sell the token to get $1 of XCP back, so they'd basically be net a long XCP bet. I can imagine that this kind of usage would increase the scarcity of XCP and push the price up (so in the next round a unit of XCP could back a larger dollar value of assets, and so on). Something like this could work in parallel with unbacked assets, and I could also imagine having fractionally backed assets, so users would have greater choice. EDIT: Clarity
|
|
|
|
cityglut
|
|
March 27, 2014, 05:41:38 PM |
|
Does any sort of collateralization requirement denominated in XCP limit the total amount of assets that can be traded on the exchange to the market cap of XCP? How do you work out the margin requirement? Or is the idea that any asset in one's possession can be used as collateral, but represented as an XCP equivalent?
In a world with XCP backed assets, one way I could imagine this working would be that the current market price of the asset (based on a price feed) would be locked away when the asset was created, and the issuer would place a bet to cover future variations in the price, up to a disclosed bet size, and future date. An issuer could choose the amount of margin they want to put up, and when they run out, the asset would be automatically liquidated. This would have the side effect of dumpling an asset holder back into XCP if a market got volatile, but I think it could dramatically reduce counterparty risk, and everyone would know were they stood. When issuing, an issuer would lock away $1 worth of XCP to create the asset, and might choose to commit, say, another 25% to cover variation. So $1.25 worth of XCP might be locked away per USD token. They could sell the token to get $1 of XCP back, so they'd basically be net a long XCP bet. I can imagine that this kind of usage would increase the scarcity of XCP and push the price up (so in the next round a unit of XCP could back a larger dollar value of assets, and so on). You cannot eliminate counterparty risk from an asset-backed currency peg, as there is no mechanism at the protocol level to stop the issuer (i.e. the user with the private key of the address with the XCP backing) from withdrawing funds. I still think though that is a really good use-case. A currency peg that actually requires no trust is making a CFD on the price of an asset to which you would like to peg your holdings in XCP. The effectiveness of the peg, however, depends on one's leverage, which in turn increases one's risk. For anyone who is interested in making such a peg, I have come up with a few examples which would show how you do it.
|
|
|
|
freedomfighter
|
|
March 27, 2014, 05:49:10 PM |
|
Here is a post just now by Mark F.- a BTC core developer explaining the issue as JGarzik did in previous posts here. I only bring it because even-though, again, I dont really like a paragraph such as his last one, I think that we should continue and speak to them as partners. so... his writing also requires a response in my book. Mark Friedenbach • 5 minutes ago You say that "Counterparty users pay fees to Bitcoin miners who process their transactions." However it is not miners which process their transactions, it is the set of fully-validating nodes of which large mining pools make up a mere 0.01%. To the rest of these participants in the bitcoin network, processing of transactions is a fully externalized cost - you have electricity and storage expenses for running a full node but don't see a single satoshi of transaction fees in compensation. This is a fundamental incentive problem with bitcoin today, and the parasitic use of the block chain as a publication system for Counterparty, Mastercoin, etc. is exacerbating the problem without any attempt to provide a solution. If and until the incentive problem is fixed (it's not clear it can be!) these groups should be doing their transactions on a separately validated side-chain, so only those users who opt-in to running the side chain incur the cost. Hopefully using 2-way pegging so their currency can be bitcoins, if they want to avoid the scummy currency issuance investment model. If they don't do this, they are forceably extracting a rent from those current users of the bitcoin network which did not expect to be processing these transactions without pay when they started using bitcoin. We are not hostile to this kind of innovation. In fact, I co-authored a distributed p2p exchange model using bitcoin side-chains accomplishing the same things as Counterparty and published six months before Counterpart started their development: http://freico.in/docs/freimark... What we are against is extorting other participants of the bitcoin network into processing your transactions which were not in the original social contract of bitcoin, especially when clearly explained alternatives exist. That is frankly evil, although I'll give you the benefit of the doubt and chalk it up to ignorance. This time. Mark Friedenbach Bitcoin Core developer
|
|
|
|
CryptoFinanceUK
Newbie
Offline
Activity: 39
Merit: 0
|
|
March 27, 2014, 05:54:36 PM |
|
Does any sort of collateralization requirement denominated in XCP limit the total amount of assets that can be traded on the exchange to the market cap of XCP? How do you work out the margin requirement? Or is the idea that any asset in one's possession can be used as collateral, but represented as an XCP equivalent?
In a world with XCP backed assets, one way I could imagine this working would be that the current market price of the asset (based on a price feed) would be locked away when the asset was created, and the issuer would place a bet to cover future variations in the price, up to a disclosed bet size, and future date. An issuer could choose the amount of margin they want to put up, and when they run out, the asset would be automatically liquidated. This would have the side effect of dumpling an asset holder back into XCP if a market got volatile, but I think it could dramatically reduce counterparty risk, and everyone would know were they stood. When issuing, an issuer would lock away $1 worth of XCP to create the asset, and might choose to commit, say, another 25% to cover variation. So $1.25 worth of XCP might be locked away per USD token. They could sell the token to get $1 of XCP back, so they'd basically be net a long XCP bet. I can imagine that this kind of usage would increase the scarcity of XCP and push the price up (so in the next round a unit of XCP could back a larger dollar value of assets, and so on). You cannot eliminate counterparty risk from an asset-backed currency peg, as there is no mechanism at the protocol level to stop the issuer (i.e. the user with the private key of the address with the XCP backing) from withdrawing funds. I still think though that is a really good use-case. A currency peg that actually requires no trust is making a CFD on the price of an asset to which you would like to peg your holdings in XCP. The effectiveness of the peg, however, depends on one's leverage, which in turn increases one's risk. For anyone who is interested in making such a peg, I have come up with a few examples which would show how you do it. Thanks cityglut, pity, something like this would have been very cool
|
|
|
|
cityglut
|
|
March 27, 2014, 06:04:52 PM |
|
Does any sort of collateralization requirement denominated in XCP limit the total amount of assets that can be traded on the exchange to the market cap of XCP? How do you work out the margin requirement? Or is the idea that any asset in one's possession can be used as collateral, but represented as an XCP equivalent?
In a world with XCP backed assets, one way I could imagine this working would be that the current market price of the asset (based on a price feed) would be locked away when the asset was created, and the issuer would place a bet to cover future variations in the price, up to a disclosed bet size, and future date. An issuer could choose the amount of margin they want to put up, and when they run out, the asset would be automatically liquidated. This would have the side effect of dumpling an asset holder back into XCP if a market got volatile, but I think it could dramatically reduce counterparty risk, and everyone would know were they stood. When issuing, an issuer would lock away $1 worth of XCP to create the asset, and might choose to commit, say, another 25% to cover variation. So $1.25 worth of XCP might be locked away per USD token. They could sell the token to get $1 of XCP back, so they'd basically be net a long XCP bet. I can imagine that this kind of usage would increase the scarcity of XCP and push the price up (so in the next round a unit of XCP could back a larger dollar value of assets, and so on). You cannot eliminate counterparty risk from an asset-backed currency peg, as there is no mechanism at the protocol level to stop the issuer (i.e. the user with the private key of the address with the XCP backing) from withdrawing funds. I still think though that is a really good use-case. A currency peg that actually requires no trust is making a CFD on the price of an asset to which you would like to peg your holdings in XCP. The effectiveness of the peg, however, depends on one's leverage, which in turn increases one's risk. For anyone who is interested in making such a peg, I have come up with a few examples which would show how you do it. Thanks cityglut, pity, something like this would have been very cool It's still a good service! And indeed I think that if a trusted exchange (or even a trusted community member) were to implement something like this on Counterparty, it would gain adoption.
|
|
|
|
CryptoFinanceUK
Newbie
Offline
Activity: 39
Merit: 0
|
|
March 27, 2014, 06:13:26 PM |
|
For anyone who is interested in making such a peg, I have come up with a few examples which would show how you do it.
It's still a good service! And indeed I think that if a trusted exchange (or even a trusted community member) were to implement something like this on Counterparty, it would gain adoption.
Great, maybe you could drop us a link / point us to your examples?
|
|
|
|
Matt Y
|
|
March 27, 2014, 06:27:30 PM |
|
Newbie here. So is proof-of-burn still how people are buying these? Or should I buy through Poloniex? I was a rookie Hope to get help from others Someone to help us? Proof of burn is over. The easiest way to buy is on Poloniex or Bter.
|
|
|
|
baddw
|
|
March 27, 2014, 07:22:19 PM |
|
Here is a post just now by Mark F.- a BTC core developer explaining the issue as JGarzik did in previous posts here. I only bring it because even-though, again, I dont really like a paragraph such as his last one, I think that we should continue and speak to them as partners. so... his writing also requires a response in my book.
Mark Friedenbach • 5 minutes ago You say that "Counterparty users pay fees to Bitcoin miners who process their transactions." However it is not miners which process their transactions, it is the set of fully-validating nodes of which large mining pools make up a mere 0.01%. To the rest of these participants in the bitcoin network, processing of transactions is a fully externalized cost - you have electricity and storage expenses for running a full node but don't see a single satoshi of transaction fees in compensation. (snip)
My reply on the letstalkbitcoin comment thread: "Yes, and any and all of those nodes are free to stop running at any time and to delete the blockchain from their hard drives. They run bitcoind/Bitcoin-QT and store the blockchain because they have some incentive to do so. The fact that this incentive is not explicit (i.e., direct compensation) does not mean that it does not exist. The cost of running a node is miniscule compared to the cost of mining. And there are plenty of minimal wallet programs out there that do not store the entire blockchain."
|
BTC/XCP 11596GYYq5WzVHoHTmYZg4RufxxzAGEGBX DRK XvFhRFQwvBAmFkaii6Kafmu6oXrH4dSkVF Eligius Payouts/CPPSRB Explained I am not associated with Eligius in any way. I just think that it is a good pool with a cool payment system
|
|
|
BldSwtTrs
Legendary
Offline
Activity: 861
Merit: 1010
|
|
March 27, 2014, 07:43:42 PM |
|
What sucks is that while the term Decentralized exchange let imagine the possibility of the elimination of third party risk, actually there is a lot more counterparty risk by using it. (I prefer trust Bitstamp or Cryptsy than a random asset issuer on top of counterparty, and it's not even close).
|
|
|
|
halfcab123
Full Member
Offline
Activity: 224
Merit: 100
CabTrader v2 | crypto-folio.com
|
|
March 27, 2014, 07:52:32 PM |
|
Highest volume on BTER goes to? XCP.
|
DayTrade with less exposure to risk, by setting buy and sell spreads with CabTrader v2, buy now @ crypto-folio.com
|
|
|
xnova
Sr. Member
Offline
Activity: 390
Merit: 254
Counterparty Developer
|
|
March 27, 2014, 07:56:26 PM |
|
Here is a post just now by Mark F.- a BTC core developer explaining the issue as JGarzik did in previous posts here. I only bring it because even-though, again, I dont really like a paragraph such as his last one, I think that we should continue and speak to them as partners. so... his writing also requires a response in my book. Mark Friedenbach • 5 minutes ago You say that "Counterparty users pay fees to Bitcoin miners who process their transactions." However it is not miners which process their transactions, it is the set of fully-validating nodes of which large mining pools make up a mere 0.01%. To the rest of these participants in the bitcoin network, processing of transactions is a fully externalized cost - you have electricity and storage expenses for running a full node but don't see a single satoshi of transaction fees in compensation. This is a fundamental incentive problem with bitcoin today, and the parasitic use of the block chain as a publication system for Counterparty, Mastercoin, etc. is exacerbating the problem without any attempt to provide a solution. If and until the incentive problem is fixed (it's not clear it can be!) these groups should be doing their transactions on a separately validated side-chain, so only those users who opt-in to running the side chain incur the cost. Hopefully using 2-way pegging so their currency can be bitcoins, if they want to avoid the scummy currency issuance investment model. If they don't do this, they are forceably extracting a rent from those current users of the bitcoin network which did not expect to be processing these transactions without pay when they started using bitcoin. We are not hostile to this kind of innovation. In fact, I co-authored a distributed p2p exchange model using bitcoin side-chains accomplishing the same things as Counterparty and published six months before Counterpart started their development: http://freico.in/docs/freimark... What we are against is extorting other participants of the bitcoin network into processing your transactions which were not in the original social contract of bitcoin, especially when clearly explained alternatives exist. That is frankly evil, although I'll give you the benefit of the doubt and chalk it up to ignorance. This time. Mark Friedenbach Bitcoin Core developer Matt Y from our team spoke to Mark recently at Coinsummit. Mark is a very bright individual and has echoed some valid concerns. We are in the process of reaching out to Mark and hope to get a call going between him and I, so that we can begin to build a dialogue together on this topic and work towards a resolution that is acceptable for all parties.
|
|
|
|
baddw
|
|
March 27, 2014, 07:57:02 PM |
|
What sucks is that while the term Decentralized exchange let imagine the possibility of the elimination of third party risk, actually there is a lot more counterparty risk by using it. (I prefer trust Bitstamp or Cryptsy than a random asset issuer on top of counterparty, and it's not even close).
The thing is, a centralized exchanged like Bitstamp or Cryptsy is really complicated, and you can't read the source. There are potential vulnerabilities throughout their entire systems. An asset issuer on Counterparty needs only do one thing correctly: hold the asset. They don't need to make sure their wallet software is updated, they don't need to match orders correctly, they don't need to keep orders on the books. They only have to do one thing, and that one thing can be provable (such as providing bank statements, photos of physical assets, etc.). The rest is on the Counterparty implementation, which is open-source. Do you trust that Cryptsy owns the correct amount of coins for the 50+ coins that they trade? And that a vulnerability in one of the wallets in one of those coins won't lead people to make fake deposits, trade those fake coins for BTC, cash out the BTC and leave Cryptsy with nothing but a bunch of fake coins? (Like supposedly happened with CryptoRush and BlackCoin?) I'm not trying to pick on Cryptsy here, I use them myself and trust them more than I trust other centralized exchanges. But for them to prove to me that they have all the required coin balances for 50 different coins would be quite complicated. And then they would have to prove to me that their exchange code can't be cheated.
|
BTC/XCP 11596GYYq5WzVHoHTmYZg4RufxxzAGEGBX DRK XvFhRFQwvBAmFkaii6Kafmu6oXrH4dSkVF Eligius Payouts/CPPSRB Explained I am not associated with Eligius in any way. I just think that it is a good pool with a cool payment system
|
|
|
BitcoinTangibleTrust
Member
Offline
Activity: 111
Merit: 10
Digitizing Valuable Hard Assets with Crypto
|
|
March 27, 2014, 07:59:50 PM |
|
What sucks is that while the term Decentralized exchange let imagine the possibility of the elimination of third party risk, actually there is a lot more counterparty risk by using it. (I prefer trust Bitstamp or Cryptsy than a random asset issuer on top of counterparty, and it's not even close).
The thing is, a centralized exchanged like Bitstamp or Cryptsy is really complicated, and you can't read the source. There are potential vulnerabilities throughout their entire systems. An asset issuer on Counterparty needs only do one thing correctly: hold the asset. They don't need to make sure their wallet software is updated, they don't need to match orders correctly, they don't need to keep orders on the books. They only have to do one thing, and that one thing can be provable (such as providing bank statements, photos of physical assets, etc.). The rest is on the Counterparty implementation, which is open-source. +1 Indeed.
|
|
|
|
freedomfighter
|
|
March 27, 2014, 08:10:00 PM |
|
Here is a post just now by Mark F.- a BTC core developer explaining the issue as JGarzik did in previous posts here. I only bring it because even-though, again, I dont really like a paragraph such as his last one, I think that we should continue and speak to them as partners. so... his writing also requires a response in my book. Mark Friedenbach • 5 minutes ago You say that "Counterparty users pay fees to Bitcoin miners who process their transactions." However it is not miners which process their transactions, it is the set of fully-validating nodes of which large mining pools make up a mere 0.01%. To the rest of these participants in the bitcoin network, processing of transactions is a fully externalized cost - you have electricity and storage expenses for running a full node but don't see a single satoshi of transaction fees in compensation. This is a fundamental incentive problem with bitcoin today, and the parasitic use of the block chain as a publication system for Counterparty, Mastercoin, etc. is exacerbating the problem without any attempt to provide a solution. If and until the incentive problem is fixed (it's not clear it can be!) these groups should be doing their transactions on a separately validated side-chain, so only those users who opt-in to running the side chain incur the cost. Hopefully using 2-way pegging so their currency can be bitcoins, if they want to avoid the scummy currency issuance investment model. If they don't do this, they are forceably extracting a rent from those current users of the bitcoin network which did not expect to be processing these transactions without pay when they started using bitcoin. We are not hostile to this kind of innovation. In fact, I co-authored a distributed p2p exchange model using bitcoin side-chains accomplishing the same things as Counterparty and published six months before Counterpart started their development: http://freico.in/docs/freimark... What we are against is extorting other participants of the bitcoin network into processing your transactions which were not in the original social contract of bitcoin, especially when clearly explained alternatives exist. That is frankly evil, although I'll give you the benefit of the doubt and chalk it up to ignorance. This time. Mark Friedenbach Bitcoin Core developer Matt Y from our team spoke to Mark recently at Coinsummit. Mark is a very bright individual and has echoed some valid concerns. We are in the process of reaching out to Mark and hope to get a call going between him and I, so that we can begin to build a dialogue together on this topic and work towards a resolution that is acceptable for all parties. This is excellent and highly professional. Thanks for the update. There are also some good responses to his post from various individuals.
|
|
|
|
porqupine
|
|
March 27, 2014, 08:13:47 PM |
|
How is this a comment from a bright individual you can reach out to? It's just another Luke Jr. What we are against is extorting other participants of the bitcoin network into processing your transactions which were not in the original social contract of bitcoin, especially when clearly explained alternatives exist. That is frankly evil, although I'll give you the benefit of the doubt and chalk it up to ignorance. This time.
|
|
|
|
l4p7
Member
Offline
Activity: 70
Merit: 10
|
|
March 27, 2014, 08:25:13 PM |
|
What sucks is that while the term Decentralized exchange let imagine the possibility of the elimination of third party risk, actually there is a lot more counterparty risk by using it. (I prefer trust Bitstamp or Cryptsy than a random asset issuer on top of counterparty, and it's not even close).
The thing is, a centralized exchanged like Bitstamp or Cryptsy is really complicated, and you can't read the source. There are potential vulnerabilities throughout their entire systems. An asset issuer on Counterparty needs only do one thing correctly: hold the asset. They don't need to make sure their wallet software is updated, they don't need to match orders correctly, they don't need to keep orders on the books. They only have to do one thing, and that one thing can be provable (such as providing bank statements, photos of physical assets, etc.). The rest is on the Counterparty implementation, which is open-source. Do you trust that Cryptsy owns the correct amount of coins for the 50+ coins that they trade? And that a vulnerability in one of the wallets in one of those coins won't lead people to make fake deposits, trade those fake coins for BTC, cash out the BTC and leave Cryptsy with nothing but a bunch of fake coins? (Like supposedly happened with CryptoRush and BlackCoin?) I'm not trying to pick on Cryptsy here, I use them myself and trust them more than I trust other centralized exchanges. But for them to prove to me that they have all the required coin balances for 50 different coins would be quite complicated. And then they would have to prove to me that their exchange code can't be cheated. What advantage does an issuer have when issuing for example XLTC on Counterparty?
|
|
|
|
cityglut
|
|
March 27, 2014, 08:26:44 PM |
|
For anyone who is interested in making such a peg, I have come up with a few examples which would show how you do it.
It's still a good service! And indeed I think that if a trusted exchange (or even a trusted community member) were to implement something like this on Counterparty, it would gain adoption.
Great, maybe you could drop us a link / point us to your examples? I've PMed you.
|
|
|
|
Matt Y
|
|
March 27, 2014, 08:27:20 PM |
|
There is a lot of emotion over the data storage topic right now on both sides and that's understandable. There is also a lot of bad information being circulated.
I am not going to judge Mark on a statement or two that I don't agree with. Mark proved to be very reasonable in our discussion at CoinSummit. He had some interesting ideas and is willing to have discussions with the Counterparty developers that will allow us to work towards a solution together. It was obvious that mark cares deeply about Bitcoin as well as the ethics and motivations of other projects in the digital currency space.
|
|
|
|
l4p7
Member
Offline
Activity: 70
Merit: 10
|
|
March 27, 2014, 08:30:06 PM |
|
Does any sort of collateralization requirement denominated in XCP limit the total amount of assets that can be traded on the exchange to the market cap of XCP? How do you work out the margin requirement? Or is the idea that any asset in one's possession can be used as collateral, but represented as an XCP equivalent?
In a world with XCP backed assets, one way I could imagine this working would be that the current market price of the asset (based on a price feed) would be locked away when the asset was created, and the issuer would place a bet to cover future variations in the price, up to a disclosed bet size, and future date. An issuer could choose the amount of margin they want to put up, and when they run out, the asset would be automatically liquidated. This would have the side effect of dumpling an asset holder back into XCP if a market got volatile, but I think it could dramatically reduce counterparty risk, and everyone would know were they stood. When issuing, an issuer would lock away $1 worth of XCP to create the asset, and might choose to commit, say, another 25% to cover variation. So $1.25 worth of XCP might be locked away per USD token. They could sell the token to get $1 of XCP back, so they'd basically be net a long XCP bet. I can imagine that this kind of usage would increase the scarcity of XCP and push the price up (so in the next round a unit of XCP could back a larger dollar value of assets, and so on). You cannot eliminate counterparty risk from an asset-backed currency peg, as there is no mechanism at the protocol level to stop the issuer (i.e. the user with the private key of the address with the XCP backing) from withdrawing funds. I still think though that is a really good use-case. A currency peg that actually requires no trust is making a CFD on the price of an asset to which you would like to peg your holdings in XCP. The effectiveness of the peg, however, depends on one's leverage, which in turn increases one's risk. For anyone who is interested in making such a peg, I have come up with a few examples which would show how you do it. as there is no mechanism at the protocol level to stop the issuer (i.e. the user with the private key of the address with the XCP backing) from withdrawing funds But would it be possibility to implement such a mechanism: The issuer of XLTC sends the funds to a LTC wallet within the Counterparty system....
|
|
|
|
|