|
led_lcd
|
 |
February 04, 2014, 05:30:15 AM |
|
If the transactions are not parsed in a very well-defined order, then address balances quickly become totally unreliable.
[...]
This. 1) The Counterparty protocol is clear and unambiguous. 2) The fact that the reference implementation could be completed and released in timeframes (apparently) much shorter than the competing solutions speaks volumes about the developers' ability and knowledge of the Bitcoin protocol. Let's take a little bit of poetic license and use an extended interpretation of Occam's Razor http://math.ucr.edu/home/baez/physics/General/occam.html. "If you have two equally likely solutions to a problem, choose the simplest." Let's say competing protocols get out the door and at some stage and there will some sort of core feature set parity. Now have a look that the code for competing protocols. Compare that to what exists _today_ for Counterparty. My bet is on the protocol which is the simplest to a) understand, b) debug problems, c) therefore be simplier and faster to integrate with existing systems. |
|
|
|
|
|
|
annable
Newbie
 Offline
Activity: 30
Merit: 0
|
|
February 04, 2014, 06:09:02 AM |
|
I have no BTC to burned  |
|
|
|
|
|
kdrop22
|
|
February 04, 2014, 06:17:35 AM |
|
Something like this could be really big for the future of not just counterparty but crypto currencies in general. |
|
|
|
|
|
cityglut
|
|
February 04, 2014, 06:17:59 AM |
|
If the transactions are not parsed in a very well-defined order, then address balances quickly become totally unreliable.
Oh right, I forgot about that.. Yes, every Mastercoin transaction sends about six US cents to JR, who holds the private key to the Exodus address, completely unnecessarily.
Whoa! I thought it was just some minor performance thing. It sounds like "address balances quickly become totally unreliable" is a pretty serious problem! So to summarize, XCP escrow is 100% reliable and we can also count on the account balances to be 100% reliable. The 6 cents per transaction is the icing on the cake. Mastercoin is basically asking people to pay 6 cents more per transaction, but there are some risks that the transaction might get messed up and even if it doesn't the account balance might not be reliable. Ok, I now have idea for silver bullet that will gut mastercoin, without any direct attack on them. How hard will it be to come up with a set of hard to deal with transactions that XCP can deal with totally reliably that mastercoin would just choke on? I don't have the expertise to even begin designing such a stress test, but as soon as it becomes clear that XCP can survive a bruteforce test, people will demand that mastercoin also does. What serious investor wouldnt? Volunteers please! I still dont know if mastercoin network is actually running with real money yet James Mastercoin is running with real money (i.e. with real MSC on mainnet), that's why address balances are a real problem, as opposed to just an issue that needs to be ironed out on testnet before going live on mainnet. |
|
|
|
|
|
IveBeenBit
|
|
February 04, 2014, 06:26:49 AM |
|
Can someone point me to the details on the Superbowl bet?
How did the bet work out? Did two people send BTC or XCP to an address, and the Counterparty protocol settled the bet and did the payout automatically?
If that's what happened, where did the protocol get the result of the game from?
I'm curious if this was really a "trustless" superbowl bet, or if there is a trusted party somewhere in there.
Thanks!
|
|
|
|
|
|
|
|
led_lcd
|
|
February 04, 2014, 06:30:18 AM |
|
How hard will it be to come up with a set of hard to deal with transactions that XCP can deal with totally reliably that mastercoin would just choke on? I don't have the expertise to even begin designing such a stress test, but as soon as it becomes clear that XCP can survive a bruteforce test, people will demand that mastercoin also does. What serious investor wouldnt?
This is only currently possible by comparing whitepapers as I haven't heard that any Mastercoin source has been released. Rather than try and disassemble and disqualify MSC, how about the community use the first-mover advantage and don't lose it. If you believe in the way in which Bitcoin and therefore Counterparty is being developed, then let's support the community and it will show itself as superior in the end than a centralised development team. |
|
|
|
|
|
jimhsu
|
|
February 04, 2014, 06:44:12 AM |
|
Can someone point me to the details on the Superbowl bet?
How did the bet work out? Did two people send BTC or XCP to an address, and the Counterparty protocol settled the bet and did the payout automatically?
If that's what happened, where did the protocol get the result of the game from?
I'm curious if this was really a "trustless" superbowl bet, or if there is a trusted party somewhere in there.
Thanks!
The two parties in that bet were BiggestFish and me. Every part of the bet, except for the feed, was completely trustless. I explained that in this particular case, we didn't place any stringent rules on the feed operator. In a professional setting, a feed operator wouldn't be participating in the actual betting to avoid conflict of interest, and could vet himself by a) being a trusted member of the forum, and b) signing messages related to the bet with his key. There had been discussions to turn even the feed into something trustless; however that is complicated, both theoretically and practically (someone could, for example, launch a man in the middle attack against cryptsy's API if using that for a bet). Ultimately a trusted party has to provide the data somewhere (do you trust CNN? ESPN? NIST?). The important innovation is that there is no escrow requirement -- given the inherent nature of XCP, you don't need someone to hold the pot. And any deviation (from the part of the feed operator reporting an incorrect score, for instance) is instantly detectable. BiggestFish could have reported, for instance, that Broncos won, but that deviation is instantly detectable to all parties of the bet (who would therefore not use his services in the future). But there is no theoretical possibility for him to run off with the pot. |
Dans les champs de l'observation le hasard ne favorise que les esprits préparé
|
|
|
|
IveBeenBit
|
|
February 04, 2014, 07:04:13 AM |
|
Can someone point me to the details on the Superbowl bet?
How did the bet work out? Did two people send BTC or XCP to an address, and the Counterparty protocol settled the bet and did the payout automatically?
If that's what happened, where did the protocol get the result of the game from?
I'm curious if this was really a "trustless" superbowl bet, or if there is a trusted party somewhere in there.
Thanks!
The two parties in that bet were BiggestFish and me. Every part of the bet, except for the feed, was completely trustless. I explained that in this particular case, we didn't place any stringent rules on the feed operator. In a professional setting, a feed operator wouldn't be participating in the actual betting to avoid conflict of interest, and could vet himself by a) being a trusted member of the forum, and b) signing messages related to the bet with his key. There had been discussions to turn even the feed into something trustless; however that is complicated, both theoretically and practically (someone could, for example, launch a man in the middle attack against cryptsy's API if using that for a bet). Ultimately a trusted party has to provide the data somewhere (do you trust CNN? ESPN? NIST?). The important innovation is that there is no escrow requirement -- given the inherent nature of XCP, you don't need someone to hold the pot. And any deviation (from the part of the feed operator reporting an incorrect score, for instance) is instantly detectable. BiggestFish could have reported, for instance, that Broncos won, but that deviation is instantly detectable to all parties of the bet (who would therefore not use his services in the future). But there is no theoretical possibility for him to run off with the pot. This sort of functionality has been getting talked about for months, and Counterparty just appears out of no where and gets it done. My hat is off to you guys. Thanks for explaining it so I didn't have to read this whole thread. Does the feed provider just settle a bet yes / no (binary)? Or can you enter a point spread and have the protocol evaluate different bets based on data provided from the feed operator? Meaning: You could have different bets paying different odds maybe one bet is Broncos Win. Another bet is Broncos -2.5 pts, or Broncos -7.5 pts etc.. Then the feed operator provides the final score and the protocol decides who won? |
|
|
|
|
|
cityglut
|
|
February 04, 2014, 07:07:53 AM |
|
In a professional setting, a feed operator wouldn't be participating in the actual betting
It's important to note that this is not a verifiable fact. The feed operator could simply bet using a different address. I proposed a solution to the feed trust issue way earlier in the thread and would like to raise it again. My idea was to allow bettors to choose an "aggregated feed" to bet on. The aggregated feed would be comprised of, say, 5 feeds operated by trusted parties. They would share fees. For something simple like the Super Bowl Bet the value of the feed at any given time could be the simple majority value of the feeds. There are some issues with streaming, time-sensitive data such as a Bitcoin price feed that would need to be worked out though. Aside from the technical hurdles behind this proposal, for the same reason that it cannot be verified that feed-operator is not making a bet on his own feed, there is no proof that a feed-operator did not just create multiple addresses and issue the same broadast. Moreover, since XCP are divislbe to 8 decimal-places, someone who is making a bet should always be able to divide bet across as many feeds as he likes. Admittedly, the more bets you make the less likely it is to find someone to take the other side of that bet, but if this sort of hedging mechanism became a standard, that wouldn't be a problem. This would, in any case, serve the same purpose as aggregating broadcasts. EDIT: typo. |
|
|
|
|
|
lonsharim
|
|
February 04, 2014, 07:17:40 AM |
|
PhantomPhreak mentioned a couple of things a few pages back in the thread. Scanning through a 10 minute block quickly is not a problem and that this needs to be done only once per transaction. Subsequently this is available to the counterparty in its own db. |
|
|
|
|
|
|
|
cityglut
|
|
February 04, 2014, 07:26:54 AM |
|
there is no proof that a feed-operator did not just create multiple addresses and issue the same broadast.
This is why the operator of each of the feeds is verified to be a separate entity through some other means. There must be some existing way to verify that a specific person owns a specific address right? This doesn't stop collusion though. If there really were a means of verifying that each of the feed-operators is unique, couldn't just apply this means to proving that the feed-operator and the two betting-parties are unique, as well? Moreover, since XCP are divislbe to 8 decimal-places, someone who is making a bet should always be able to divide bet across as many feeds as he likes. Admittedly, the more bets you make the less likely it is to find someone to take the other side of that bet, but if this sort of hedging mechanism became a standard, that wouldn't be a problem. This would, in any case, serve the same purpose as aggregating broadcasts.
In this case if 1 out of the 5 feeds goes bad you lose 20% of your coins. In my aggregated feed example you would need 50% of the feed operators to be bad to lose any coins. [/quote] I was mistaken, the two cases do not amount to the same thing. With that said, they are just different risk management situations: in this case the difference is between possibly losing 60% of your bet, or possibly losing all of it. |
|
|
|
|
|
cityglut
|
|
February 04, 2014, 07:38:20 AM |
|
Here is another interesting way to use XCP Assets: Distributed Kickstarter
Say Notch wants to make Minecraft 2 and fund it through Counterparty.
Notch makes a post or video somewhere describing his intentions and starts issuing MINECRAFT2 assets from an address verified to be his. He can then sell them using XCP Orders.
The tricky part is how to claim your Minecraft 2 when the game comes out. Is there some way to use public key / private key encryption to send messages through XCP? That way Notch could send encrypted game keys to holders of MINECRAFT2 assets automatically.
First, I think 'distirbuted kickstarter' is a great use-case, which you can bet I will be stealing for the wiki . I also would like to mention the new "Asset Description" feature: - Assets are now accompanied by up to 42 characters of Unicode text which may serve as a short description of the asset (esp. a link to a website with more information and proof it does what it says).
It is important not to form too strict of an analogy between Counterparty's on-chain functionality and a real market. In our opinion, the best use of this 'description space' is to provide a link to a website. It would make sense, if, on such a website, there was a list of the addresses one was using to sell assets (and the assets associated with each address), that way the link could be verified. Of course, such verification is not perfect. I want to emphasize, as well, that this feature does not eliminate trust or the importance of 'reputation', nor is it meant to. On the contrary, we believe that trust has to be a factor in asset sales, and the description space is only meant to help provide as robust a reputation system as possible. |
|
|
|
|
|
|
jl777
Legendary
Offline
Activity: 1176
Merit: 1134
|
|
February 04, 2014, 07:56:33 AM |
|
In mathematics, a counterexample can be used to prove a statement is false. counterparty uses bitcoin as an underlying base protocol and it works just fine! |
|
|
|
|
hoolio
|
|
February 04, 2014, 08:17:59 AM |
|
How can I make an asset? Do I have to make it from a wallet with XCP on it or from any address?
|
|
|
|
|
BitThink
Legendary
Offline
Activity: 882
Merit: 1000
|
|
February 04, 2014, 08:39:49 AM |
|
One of the main reasons: Simplified Payment Verification (see the bitcoin whitepaper Section 8 ) becomes not usable. Since the miner will not verify whether a XCP transaction is valid like they do in bitcoin transactions, to check the validity of a XCP transaction, we have to track up to the very beginning (the address sent to burn address). This requires each client to download and keep the whole blockchain. In Ethereum, they seems to find a way to solve this problem. Detail can be found in their whitepaper: http://www.ethereum.org/ethereum.htmlPersonally, I don't think this is something will make Mastercoin/XCP not usable. It just increases the downloading and parsing time. |
|
|
|
|
jl777
Legendary
Offline
Activity: 1176
Merit: 1134
|
|
February 04, 2014, 08:46:34 AM |
|
One of the main reasons: Simplified Payment Verification (see the bitcoin whitepaper Section 8 ) becomes not usable. Since the miner will not verify whether a XCP transaction is valid like they do in bitcoin transactions, to check the validity of a XCP transaction, we have to track up to the very beginning (the address sent to burn address). This requires each client to download and keep the whole blockchain. In Ethereum, they seems to find a way to solve this problem. Detail can be found in their whitepaper: http://www.ethereum.org/ethereum.htmlPersonally, I don't think this is something will make Mastercoin/XCP not usable. It just increases the downloading and parsing time. Would it be possible to have a checkpoint file that is signed by the XCP devs that clients could load instead of the entire blockchain? For ease of use, this is almost a requirement as few normal people will wait for hours and hours for the initial sync up |
|
|
|
|
