|
qtgwith
|
 |
March 27, 2014, 03:27:40 PM |
|
|
|
|
|
|
|
|
|
"If you don't want people to know you're a scumbag then don't be a scumbag." -- margaritahuyan
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
|
|
|
CryptoFinanceUK
Newbie
 Offline
Activity: 39
Merit: 0
|
|
March 27, 2014, 03:33:25 PM |
|
There is nothing to stop people from issuing LTC (or whatever) trading derivatives, similar to how XBTC has been created on Counterparty as essentially a proxy for BTC. We encourage folks in the community to come up with and enact these kinds of use-cases (in a thoughtful, responsible manner, not unlike how XBTC was created and is operated).
XBTC is cool, but it still leaves us with Counterparty risk. If there were additional ways to help mitigate that risk, either with XCP backed assets, or say, with OT style voting pools, I think it'd make the Counterparty ecosystem even more attractive. |
|
|
|
|
l4p7
Member
Offline
Activity: 70
Merit: 10
|
|
March 27, 2014, 03:33:29 PM |
|
What about requiring the issuer to put collateral (xcp) into the system. For example: I issue LTC within Counterparty and have to put up xcp worth the amount of LTC that is bought from me. This would make the system more safe/reliable and boost the demand for xcp.
Funnily enough, I just posted a similar idea in the main Counterparty forums. +1  @xnova, thanks for your post above. Any comment form developers on the collateral idea? Ad- and disadvantages? Posibility of implementation? I like this idea a lot. It's almost like a margin call, where the issuer needs to keep putting up collateral as the value changes. Maybe the details about max funding amount, duration, etc. could be specified in new asset fields? If the issuer didn’t want to be long XCP vs. the other asset they could also raise money on the DEX, buy LTC (or whatever) with the XCP they raise and keep that as side collateral so that they are never better or worse off as the asset changes in value. There is nothing to stop people from issuing LTC (or whatever) trading derivatives, similar to how XBTC has been created on Counterparty as essentially a proxy for BTC. We encourage folks in the community to come up with and enact these kinds of use-cases (in a thoughtful, responsible manner, not unlike how XBTC was created and is operated). What I meant was to (medium/long term option) hardcode the need for collateral (xcp as collateral)... |
|
|
|
|
Bellebite2014
Newbie
Offline
Activity: 56
Merit: 0
|
|
March 27, 2014, 03:33:47 PM |
|
Can anyone tell me what happened in the last three days here? Any reason for the recent little price drop? What about something like this http://www.nxtcoins.nl/50-2/ for Counterparty? And another, more general question regarding the DEX: Can I atm only trade BTC to XCP on there or more? Let's say n the future there will be more con (LTC for example) can I then, after I bought LTC with BTC on the DEX, withdraw those LTC into my LTC wallet? You have at least one working eye, an internet connection, and you can hopefully click on the pages on top. People are so lazy nowadays, incredible. It's just difficult to monitor NXT, Counterparty and all the other projects closely at the same time... If this is too difficult for you, just sell everything, and get back playing with your Barbie dolls... People are incredible, you must be French to complain that much. |
|
|
|
|
l4p7
Member
Offline
Activity: 70
Merit: 10
|
|
March 27, 2014, 03:35:24 PM |
|
Can anyone tell me what happened in the last three days here? Any reason for the recent little price drop? What about something like this http://www.nxtcoins.nl/50-2/ for Counterparty? And another, more general question regarding the DEX: Can I atm only trade BTC to XCP on there or more? Let's say n the future there will be more con (LTC for example) can I then, after I bought LTC with BTC on the DEX, withdraw those LTC into my LTC wallet? You have at least one working eye, an internet connection, and you can hopefully click on the pages on top. People are so lazy nowadays, incredible. It's just difficult to monitor NXT, Counterparty and all the other projects closely at the same time... If this is too difficult for you, just sell everything, and get back playing with your Barbie dolls... People are incredible, you must be French to complain that much. haha. calm down man. Never complained. Just asked/suggested. |
|
|
|
|
PhantomPhreak (OP)
Sr. Member
Offline
Activity: 476
Merit: 300
Counterparty Chief Scientist and Co-Founder
|
|
March 27, 2014, 03:46:20 PM
Last edit: March 27, 2014, 04:03:35 PM by PhantomPhreak |
|
|
|
|
|
|
CryptoFinanceUK
Newbie
Offline
Activity: 39
Merit: 0
|
|
March 27, 2014, 03:49:32 PM |
|
Great stuff - upvoted.
|
|
|
|
|
l4p7
Member
Offline
Activity: 70
Merit: 10
|
|
March 27, 2014, 04:00:32 PM |
|
|
|
|
|
|
dexX7
Legendary
Offline
Activity: 1106
Merit: 1024
|
|
March 27, 2014, 04:03:31 PM |
|
Actually quite sad to see this, and wish it will be never used. I understand why Devs implemented it, but this method introduces a lot of unspendable outputs and can never be pruned from the blockchain. Kinds of like ' if you don't let me to do this, I have no choice but to do the worse thing.'
Don't think this method cannot be filtered by bitcoin core dev. This is an open source project, any miner can parse counterparty protocol and filter it as easy as us.
BTW, even if we really want to use it, it's slightly better to use PayToPubKey instead. One pub key has 32 bytes, larger than 20 bytes (the size of key hash).
FYI: you could also use uncompressed pubKeys. 0400...0 is not a valid ECDSA point in the first place, thus it might be possible to drop the prefix, too. https://blockchain.info/tx/2de38a49f0079d0aaa8a0b9cfec71b1af935752b609eee0dc1eae56b2162a7e2 |
|
|
|
LightedLamp
Newbie
Offline
Activity: 28
Merit: 0
|
|
March 27, 2014, 04:46:51 PM |
|
|
|
|
|
|
|
freedomfighter
|
|
March 27, 2014, 04:55:49 PM |
|
A recent comment on the LTB article (good one by the way except that it is abit too emotional in its 2nd part in my view): "Firstly... Just ignore Luke-JR, everyone should do this and we will all be better for it. Secondly... Mike Hearn seemed to have a good compromise solution where OP_Return was used to store a pointer to the data that is stored elsewhere...
So you get the benefits of being on the blockchain, and lessen the load on the network. Win win?Dear DEVS: is this being discussed? is there an internal dialogue/discussion beyond the REDDIT and the articles? |
|
|
|
|
GLaDOS
Newbie
Offline
Activity: 24
Merit: 0
|
|
March 27, 2014, 04:56:49 PM |
|
Actually quite sad to see this, and wish it will be never used. I understand why Devs implemented it, but this method introduces a lot of unspendable outputs and can never be pruned from the blockchain. Kinds of like ' if you don't let me to do this, I have no choice but to do the worse thing.'
Don't think this method cannot be filtered by bitcoin core dev. This is an open source project, any miner can parse counterparty protocol and filter it as easy as us.
BTW, even if we really want to use it, it's slightly better to use PayToPubKey instead. One pub key has 32 bytes, larger than 20 bytes (the size of key hash).
FYI: you could also use uncompressed pubKeys. 0400...0 is not a valid ECDSA point in the first place, thus it might be possible to drop the prefix, too. https://blockchain.info/tx/2de38a49f0079d0aaa8a0b9cfec71b1af935752b609eee0dc1eae56b2162a7e2 , dexX7 must have dozens of nefarious tricks up his sleeves already if it ever gets to the cat and mouse game as someone puts it earlier. What else does it take for the devs to realize that OP_RETURN is the OP_SCRIPT_SUPER_EXTENSION for transactions at the upper layers? Instead the simple OP_RETURN is still being painted as just storing data when there are countless ways to do that already. |
|
|
|
|
|
cityglut
|
|
March 27, 2014, 05:01:44 PM |
|
A recent comment on the LTB article (good one by the way except that it is abit too emotional in its 2nd part in my view): "Firstly... Just ignore Luke-JR, everyone should do this and we will all be better for it. Secondly... Mike Hearn seemed to have a good compromise solution where OP_Return was used to store a pointer to the data that is stored elsewhere...
So you get the benefits of being on the blockchain, and lessen the load on the network. Win win?Dear DEVS: is this being discussed? is there an internal dialogue/discussion beyond the REDDIT and the articles? Peter Todd has already explained why this is not a good idea: https://bitcointalk.org/index.php?topic=395761.msg5824434#msg5824434 |
|
|
|
|
halfcab123
Full Member
Offline
Activity: 224
Merit: 100
CabTrader v2 | crypto-folio.com
|
|
March 27, 2014, 05:03:49 PM |
|
No rush just curious if we're on target for first week of April with the web wallet on mainnet? And is there anything I can do to help ?
|
DayTrade with less exposure to risk, by setting buy and sell spreads with CabTrader v2, buy now @ crypto-folio.com
|
|
|
|
sparta_cuss
|
|
March 27, 2014, 05:04:41 PM |
|
What about requiring the issuer to put collateral (xcp) into the system. For example: I issue LTC within Counterparty and have to put up xcp worth the amount of LTC that is bought from me. This would make the system more safe/reliable and boost the demand for xcp.
Funnily enough, I just posted a similar idea in the main Counterparty forums. +1 @xnova, thanks for your post above. Any comment form developers on the collateral idea? Ad- and disadvantages? Posibility of implementation? I like this idea a lot. It's almost like a margin call, where the issuer needs to keep putting up collateral as the value changes. Maybe the details about max funding amount, duration, etc. could be specified in new asset fields? If the issuer didn’t want to be long XCP vs. the other asset they could also raise money on the DEX, buy LTC (or whatever) with the XCP they raise and keep that as side collateral so that they are never better or worse off as the asset changes in value. There is nothing to stop people from issuing LTC (or whatever) trading derivatives, similar to how XBTC has been created on Counterparty as essentially a proxy for BTC. We encourage folks in the community to come up with and enact these kinds of use-cases (in a thoughtful, responsible manner, not unlike how XBTC was created and is operated). What I meant was to (medium/long term option) hardcode the need for collateral (xcp as collateral)... 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? |
"We must be willing to let go of the life we have planned, so as to have the life that is waiting for us." - E.M. Forster
NXT: NXT-Z24T-YU6D-688W-EARDT
BTC: 19ULeXarogu2rT4dhJN9vhztaorqDC3U7s
|
|
|
GLaDOS
Newbie
Offline
Activity: 24
Merit: 0
|
|
March 27, 2014, 05:06:35 PM |
|
Secondly... Mike Hearn seemed to have a good compromise solution where OP_Return was used to store a pointer to the data that is stored elsewhere...
So you get the benefits of being on the blockchain, and lessen the load on the network. Win win?
Dear DEVS: is this being discussed? is there an internal dialogue/discussion beyond the REDDIT and the articles?
If I am not mistaken, most of the simple operations should take less than 40 bytes already for both MSC and XCP. It just makes it unnecessarily complicated for feeds, asset issuances, etc..when a few more bytes could keep things simple. e.g. for some operations like asset issuance we could make two or more OP_RETURN40 operations. But it's even more bloat. |
|
|
|
|
|
freedomfighter
|
|
March 27, 2014, 05:10:31 PM |
|
A recent comment on the LTB article (good one by the way except that it is abit too emotional in its 2nd part in my view): "Firstly... Just ignore Luke-JR, everyone should do this and we will all be better for it. Secondly... Mike Hearn seemed to have a good compromise solution where OP_Return was used to store a pointer to the data that is stored elsewhere...
So you get the benefits of being on the blockchain, and lessen the load on the network. Win win?Dear DEVS: is this being discussed? is there an internal dialogue/discussion beyond the REDDIT and the articles? Peter Todd has already explained why this is not a good idea: https://bitcointalk.org/index.php?topic=395761.msg5824434#msg5824434Fine. I have to admit that the technical details are above my head. I trust that the you guys with the other devs will determine what is possible even if not ideal to all. What i keep trying to find out is whether there is a dialouge going on or is this a stalemate or will it develop to a cat and mouse game. As I expressed in several places throughout the past 25 pages: the best solution is to find the common path and create a win win. CP has a great interest to stay on top of BTC and not have to look elsewhere. While we all know that CP is great for bitcoin. This is why we need to reach consensus with the BTC team |
|
|
|
|
zbx
Member
Offline
Activity: 64
Merit: 10
|
|
March 27, 2014, 05:11:11 PM |
|
|
|
|
|
|
|
cityglut
|
|
March 27, 2014, 05:20:32 PM |
|
A recent comment on the LTB article (good one by the way except that it is abit too emotional in its 2nd part in my view): "Firstly... Just ignore Luke-JR, everyone should do this and we will all be better for it. Secondly... Mike Hearn seemed to have a good compromise solution where OP_Return was used to store a pointer to the data that is stored elsewhere...
So you get the benefits of being on the blockchain, and lessen the load on the network. Win win?Dear DEVS: is this being discussed? is there an internal dialogue/discussion beyond the REDDIT and the articles? Peter Todd has already explained why this is not a good idea: https://bitcointalk.org/index.php?topic=395761.msg5824434#msg5824434Fine. I have to admit that the technical details are above my head. I trust that the you guys with the other devs will determine what is possible even if not ideal to all. What i keep trying to find out is whether there is a dialouge going on or is this a stalemate or will it develop to a cat and mouse game. As I expressed in several places throughout the past 25 pages: the best solution is to find the common path and create a win win. CP has a great interest to stay on top of BTC and not have to look elsewhere. While we all know that CP is great for bitcoin. This is why we need to reach consensus with the BTC team Counterparty is in no danger of being kicked off the Bitcoin blockchain. We have contacted some of the Bitcoin core developers, though there is nothing in particular to report. We will let the community know if something comes up. |
|
|
|
|
|
|
|
