xnova
Sr. Member
Offline
Activity: 390
Merit: 254
Counterparty Developer
|
|
October 18, 2015, 07:35:36 PM |
|
An alternative implementation we investigated would have the bitcoin escrowed by the Counterwallet system (or an associated 3rd party system), which would remove the need for users to stay logged into the wallet. However, in our case, this could entail us becoming an "exchange" from a legal perspective, or minimally taking on the risk to store users' BTC, both of which we could not do.
Symbiont would technically take custodianship of the BTC in such an arrangement? None of that has anything to do with Symbiont (and all of this transpired before Symbiont even existed). In this case, when I say "us", I was talking about "us" as the Counterparty co-founders.
|
|
|
|
bitcoinrocks
Legendary
Offline
Activity: 1372
Merit: 1000
|
|
October 18, 2015, 07:39:10 PM |
|
An alternative implementation we investigated would have the bitcoin escrowed by the Counterwallet system (or an associated 3rd party system), which would remove the need for users to stay logged into the wallet. However, in our case, this could entail us becoming an "exchange" from a legal perspective, or minimally taking on the risk to store users' BTC, both of which we could not do.
Symbiont would technically take custodianship of the BTC in such an arrangement? None of that has anything to do with Symbiont (and all of this transpired before Symbiont even existed). In this case, when I say "us", I was talking about "us" as the Counterparty co-founders. This is really interesting. So according to your research or the advice you received, simply programming an autonomous and decentralized mechanism such as this makes the programmer a custodian of the funds or at least liable for what happens to them?
|
|
|
|
xnova
Sr. Member
Offline
Activity: 390
Merit: 254
Counterparty Developer
|
|
October 18, 2015, 07:53:53 PM |
|
An alternative implementation we investigated would have the bitcoin escrowed by the Counterwallet system (or an associated 3rd party system), which would remove the need for users to stay logged into the wallet. However, in our case, this could entail us becoming an "exchange" from a legal perspective, or minimally taking on the risk to store users' BTC, both of which we could not do.
Symbiont would technically take custodianship of the BTC in such an arrangement? None of that has anything to do with Symbiont (and all of this transpired before Symbiont even existed). In this case, when I say "us", I was talking about "us" as the Counterparty co-founders. This is really interesting. So according to your research or the advice you received, simply programming an autonomous and decentralized mechanism such as this makes the programmer a custodian of the funds or at least liable for what happens to them? That's the thing: such a system is not really "decentralized". The bitcoin would have been essentially held with a 3rd party until the trade completed. Multisig, etc. might be able to be employed, but if you want to remove the need for the user on the BTC side of the trade to "be there" to complete it, then someone else would have to do it for them. This service would just sit on top of the decentralized exchange protocol built into Counterparty, and take the BTC side of the trade for the user offering BTC, removing the responsibility of them having to sticking around to complete the trade. In practice, services like Shapeshift can do simple XCP-BTC exchange today, and Shapeshift supports XCP. Shapeshift just doesn't use the Counterparty decentralized exchange functionality, though.
|
|
|
|
deliciousowl
|
|
October 18, 2015, 08:32:17 PM |
|
BTC-XCP trading on the decentralized exchange is still supported both in the protocol itself and in the command-line client. The functionality was removed from Counterwallet simply because, based on user feedback, it proved to be rather unwieldy. I.e. it required users to stay logged in to complete the trades, which many users didn't/couldn't do, causing liquidity issues and frustrating users on the XCP side of the trade.
I feel the need to emphasize this further, as it is getting mentioned in rumors rather frequently: BTC-XCP trading still works if you use the command-line client and counterparty-lib: https://github.com/CounterpartyXCP/counterparty-cli
|
|
|
|
bitcoinrocks
Legendary
Offline
Activity: 1372
Merit: 1000
|
|
October 18, 2015, 08:43:08 PM |
|
An alternative implementation we investigated would have the bitcoin escrowed by the Counterwallet system (or an associated 3rd party system), which would remove the need for users to stay logged into the wallet. However, in our case, this could entail us becoming an "exchange" from a legal perspective, or minimally taking on the risk to store users' BTC, both of which we could not do.
Symbiont would technically take custodianship of the BTC in such an arrangement? None of that has anything to do with Symbiont (and all of this transpired before Symbiont even existed). In this case, when I say "us", I was talking about "us" as the Counterparty co-founders. This is really interesting. So according to your research or the advice you received, simply programming an autonomous and decentralized mechanism such as this makes the programmer a custodian of the funds or at least liable for what happens to them? That's the thing: such a system is not really "decentralized". The bitcoin would have been essentially held with a 3rd party until the trade completed. Multisig, etc. might be able to be employed, but if you want to remove the need for the user on the BTC side of the trade to "be there" to complete it, then someone else would have to do it for them. This service would just sit on top of the decentralized exchange protocol built into Counterparty, and take the BTC side of the trade for the user offering BTC, removing the responsibility of them having to sticking around to complete the trade. Which 3rd party would have held the BTC? Counterparty can not be made to escrow the funds autonomously?
|
|
|
|
xnova
Sr. Member
Offline
Activity: 390
Merit: 254
Counterparty Developer
|
|
October 18, 2015, 09:07:57 PM |
|
An alternative implementation we investigated would have the bitcoin escrowed by the Counterwallet system (or an associated 3rd party system), which would remove the need for users to stay logged into the wallet. However, in our case, this could entail us becoming an "exchange" from a legal perspective, or minimally taking on the risk to store users' BTC, both of which we could not do.
Symbiont would technically take custodianship of the BTC in such an arrangement? None of that has anything to do with Symbiont (and all of this transpired before Symbiont even existed). In this case, when I say "us", I was talking about "us" as the Counterparty co-founders. This is really interesting. So according to your research or the advice you received, simply programming an autonomous and decentralized mechanism such as this makes the programmer a custodian of the funds or at least liable for what happens to them? That's the thing: such a system is not really "decentralized". The bitcoin would have been essentially held with a 3rd party until the trade completed. Multisig, etc. might be able to be employed, but if you want to remove the need for the user on the BTC side of the trade to "be there" to complete it, then someone else would have to do it for them. This service would just sit on top of the decentralized exchange protocol built into Counterparty, and take the BTC side of the trade for the user offering BTC, removing the responsibility of them having to sticking around to complete the trade. Which 3rd party would have held the BTC? Counterparty can not be made to escrow the funds autonomously? _Someone_ would need to handle the BTC, _only_ in this specific case. Note that this is _only_ the case with BTC, and _only_ if you don't want to place _any_ burden on the user that has the BTC to stick around after they place the order. Basically, Counterparty doesn't have the same degree over escrowing BTC that it does with native assets, for purely technical reasons which have been explained elsewhere.
|
|
|
|
prophetx
Legendary
Offline
Activity: 1666
Merit: 1010
he who has the gold makes the rules
|
|
October 18, 2015, 11:29:58 PM |
|
An alternative implementation we investigated would have the bitcoin escrowed by the Counterwallet system (or an associated 3rd party system), which would remove the need for users to stay logged into the wallet. However, in our case, this could entail us becoming an "exchange" from a legal perspective, or minimally taking on the risk to store users' BTC, both of which we could not do.
Symbiont would technically take custodianship of the BTC in such an arrangement? None of that has anything to do with Symbiont (and all of this transpired before Symbiont even existed). In this case, when I say "us", I was talking about "us" as the Counterparty co-founders. This is really interesting. So according to your research or the advice you received, simply programming an autonomous and decentralized mechanism such as this makes the programmer a custodian of the funds or at least liable for what happens to them? That's the thing: such a system is not really "decentralized". The bitcoin would have been essentially held with a 3rd party until the trade completed. Multisig, etc. might be able to be employed, but if you want to remove the need for the user on the BTC side of the trade to "be there" to complete it, then someone else would have to do it for them. This service would just sit on top of the decentralized exchange protocol built into Counterparty, and take the BTC side of the trade for the user offering BTC, removing the responsibility of them having to sticking around to complete the trade. Which 3rd party would have held the BTC? Counterparty can not be made to escrow the funds autonomously? _Someone_ would need to handle the BTC, _only_ in this specific case. Note that this is _only_ the case with BTC, and _only_ if you don't want to place _any_ burden on the user that has the BTC to stick around after they place the order. Basically, Counterparty doesn't have the same degree over escrowing BTC that it does with native assets, for purely technical reasons which have been explained elsewhere. Have you guys mentioned this to Erik V at Shapeshift?
|
|
|
|
xnova
Sr. Member
Offline
Activity: 390
Merit: 254
Counterparty Developer
|
|
October 19, 2015, 03:58:32 PM |
|
An alternative implementation we investigated would have the bitcoin escrowed by the Counterwallet system (or an associated 3rd party system), which would remove the need for users to stay logged into the wallet. However, in our case, this could entail us becoming an "exchange" from a legal perspective, or minimally taking on the risk to store users' BTC, both of which we could not do.
Symbiont would technically take custodianship of the BTC in such an arrangement? None of that has anything to do with Symbiont (and all of this transpired before Symbiont even existed). In this case, when I say "us", I was talking about "us" as the Counterparty co-founders. This is really interesting. So according to your research or the advice you received, simply programming an autonomous and decentralized mechanism such as this makes the programmer a custodian of the funds or at least liable for what happens to them? That's the thing: such a system is not really "decentralized". The bitcoin would have been essentially held with a 3rd party until the trade completed. Multisig, etc. might be able to be employed, but if you want to remove the need for the user on the BTC side of the trade to "be there" to complete it, then someone else would have to do it for them. This service would just sit on top of the decentralized exchange protocol built into Counterparty, and take the BTC side of the trade for the user offering BTC, removing the responsibility of them having to sticking around to complete the trade. Which 3rd party would have held the BTC? Counterparty can not be made to escrow the funds autonomously? _Someone_ would need to handle the BTC, _only_ in this specific case. Note that this is _only_ the case with BTC, and _only_ if you don't want to place _any_ burden on the user that has the BTC to stick around after they place the order. Basically, Counterparty doesn't have the same degree over escrowing BTC that it does with native assets, for purely technical reasons which have been explained elsewhere. Have you guys mentioned this to Erik V at Shapeshift? Not that I recall. You're welcome to, though.
|
|
|
|
|
prophetx
Legendary
Offline
Activity: 1666
Merit: 1010
he who has the gold makes the rules
|
|
October 21, 2015, 09:24:37 PM |
|
An alternative implementation we investigated would have the bitcoin escrowed by the Counterwallet system (or an associated 3rd party system), which would remove the need for users to stay logged into the wallet. However, in our case, this could entail us becoming an "exchange" from a legal perspective, or minimally taking on the risk to store users' BTC, both of which we could not do.
Symbiont would technically take custodianship of the BTC in such an arrangement? None of that has anything to do with Symbiont (and all of this transpired before Symbiont even existed). In this case, when I say "us", I was talking about "us" as the Counterparty co-founders. This is really interesting. So according to your research or the advice you received, simply programming an autonomous and decentralized mechanism such as this makes the programmer a custodian of the funds or at least liable for what happens to them? That's the thing: such a system is not really "decentralized". The bitcoin would have been essentially held with a 3rd party until the trade completed. Multisig, etc. might be able to be employed, but if you want to remove the need for the user on the BTC side of the trade to "be there" to complete it, then someone else would have to do it for them. This service would just sit on top of the decentralized exchange protocol built into Counterparty, and take the BTC side of the trade for the user offering BTC, removing the responsibility of them having to sticking around to complete the trade. Which 3rd party would have held the BTC? Counterparty can not be made to escrow the funds autonomously? _Someone_ would need to handle the BTC, _only_ in this specific case. Note that this is _only_ the case with BTC, and _only_ if you don't want to place _any_ burden on the user that has the BTC to stick around after they place the order. Basically, Counterparty doesn't have the same degree over escrowing BTC that it does with native assets, for purely technical reasons which have been explained elsewhere. Have you guys mentioned this to Erik V at Shapeshift? Not that I recall. You're welcome to, though. I sent him a msg in skype. btw who owns that counterwallet website?
|
|
|
|
Praxis
Legendary
Offline
Activity: 1118
Merit: 1004
|
|
October 22, 2015, 02:20:17 PM |
|
Interestingly, price keeps falling even after this news / exposure I guess price of XCP is not a good measurement of CP popularity
|
|
|
|
mmortal03
Legendary
Offline
Activity: 1762
Merit: 1011
|
|
October 22, 2015, 04:20:52 PM |
|
Interestingly, price keeps falling even after this news / exposure I guess price of XCP is not a good measurement of CP popularity This is how crypto works. When good news comes out, the price goes lower. But, seriously, everything is going down relative to this current Bitcoin pop.
|
|
|
|
Kalkuuuta
Member
Offline
Activity: 64
Merit: 10
|
|
October 27, 2015, 02:09:42 AM Last edit: October 27, 2015, 02:22:26 AM by Kalkuuuta |
|
(Found 9999 unique addresses with a total balance of 2634744.87612734 XCP) Over 0.00000001 XCP are in #4516 address. +602 address Over 1.0 XCP are in #3297 +336 Over 10.0 XCP are in #2331 +94 Over 100.0 XCP are in #1490 -38 Over 500.0 XCP are in #1064 -49 Over 1000.0 XCP are in #892 -68 Over 1500.0 XCP are in #149 -11 Over 2500.0 XCP are in #98 -3 Over 5000.0 XCP are in #67 +4 Total XCP balance have go down 6079.94 XCP. 6 month changes in addresses balances. Looks like peoples aren't really interested buying and holding XCP. Now it is under $80 what need to become over 100 XCP holder and in last 6 month more >100 XCP holders have sold than come in. Four new over 5000 XCP holders maybe have come when transfer burned coins to other address... 6 month ago 101 address have over 50% of coins and now 82 address have >50%. If someone sell $3000 worth of XCP price drop to under $0.30 per XCP. It is 2% of richest address balance I think we will see new very low price before anything happen what take price go up. Blockscan can't show over 9999 address for total address where have been before coins?
|
|
|
|
Kalkuuuta
Member
Offline
Activity: 64
Merit: 10
|
|
October 27, 2015, 06:46:47 AM |
|
Also ~842000 XCP are still in burning address. Maybe count few thousand wrong but about 840k. Because this not have sold or even moved so far we can wait that all own someone/s from 84. biggest owners. When total balance is 2634744 XCP this means 84 richest+burn address coins is 1317372 XCP+842033 XCP = 2159405 XCP. 2159405/2634744*100= 81.95% of coins own someone from top 84 address... Maybe even more, I am not surprised if over 90% of coins owns someone of this 84 address... What this mean for markets and price in future are interesting IF something big happen...
|
|
|
|
BitThink
Legendary
Offline
Activity: 882
Merit: 1000
|
|
October 27, 2015, 11:02:04 AM |
|
Also ~842000 XCP are still in burning address. Maybe count few thousand wrong but about 840k. Because this not have sold or even moved so far we can wait that all own someone/s from 84. biggest owners. When total balance is 2634744 XCP this means 84 richest+burn address coins is 1317372 XCP+842033 XCP = 2159405 XCP. 2159405/2634744*100= 81.95% of coins own someone from top 84 address... Maybe even more, I am not surprised if over 90% of coins owns someone of this 84 address... What this mean for markets and price in future are interesting IF something big happen... The whole bid side on poloniex, which is the main exchange of XCP, is less than 15 BTC, and the daily volume is at single digit. That's the reason why no big player is intested to move coins and sell them, cause they cannot liquidate their holdings without push price to almost 0.
|
|
|
|
|
BitThink
Legendary
Offline
Activity: 882
Merit: 1000
|
|
October 27, 2015, 11:18:26 PM |
|
|
|
|
|
Kalkuuuta
Member
Offline
Activity: 64
Merit: 10
|
|
October 28, 2015, 12:20:12 AM |
|
Also ~842000 XCP are still in burning address. Maybe count few thousand wrong but about 840k. Because this not have sold or even moved so far we can wait that all own someone/s from 84. biggest owners. When total balance is 2634744 XCP this means 84 richest+burn address coins is 1317372 XCP+842033 XCP = 2159405 XCP. 2159405/2634744*100= 81.95% of coins own someone from top 84 address... Maybe even more, I am not surprised if over 90% of coins owns someone of this 84 address... What this mean for markets and price in future are interesting IF something big happen... The whole bid side on poloniex, which is the main exchange of XCP, is less than 15 BTC, and the daily volume is at single digit. That's the reason why no big player is intested to move coins and sell them, cause they cannot liquidate their holdings without push price to almost 0. My main point was that there are not many small players, only big holders and long time believers Hope this make Counterparty better
|
|
|
|
|
ShapeShift.io
|
|
October 28, 2015, 10:22:11 PM |
|
ShapeShift.io has released our instant exchange app for Android devices! Buy or sell Counterparty with bitcoin and 45+ cryptos instantly on any Android device. Exchange anytime, anywhere: https://shapeshift.io/site/tools/shapeshift-mobile
|
Follow us on our new profile: ShapeShift.com
Sign up for our closed beta waitlist: beta.shapeshift.com
|
|
|
|