Author

Topic: [ANN][XCP] Counterparty - Pioneering Peer-to-Peer Finance - Official Thread - page 555. (Read 1276933 times)

full member
Activity: 196
Merit: 100
Last couple pages of the Asicminer thread have had an interesting discussion about switching Asicminer shares over to Counterparty:

https://bitcointalksearch.org/topic/m.4907871

I had a similiar discussion a few days back on the Counterparty Asset thread

https://bitcointalksearch.org/topic/m.4839262
full member
Activity: 196
Merit: 100
http://bitcoinmagazine.com/9671/ethereum-next-generation-cryptocurrency-decentralized-application-platform/

How do the counterparty people respond to Vitalik's criticism about mastercoin/counterparty/coloredcoins?
In many ways, this concept of bolting on data on top of bitcoin just has an awkward feeling to it.

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.
full member
Activity: 216
Merit: 100

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.
sr. member
Activity: 449
Merit: 250
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.

Wow!

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?
sr. member
Activity: 364
Merit: 264
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.
sr. member
Activity: 262
Merit: 250
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.
newbie
Activity: 14
Merit: 0
http://bitcoinmagazine.com/9671/ethereum-next-generation-cryptocurrency-decentralized-application-platform/

How do the counterparty people respond to Vitalik's criticism about mastercoin/counterparty/coloredcoins?
In many ways, this concept of bolting on data on top of bitcoin just has an awkward feeling to it.
sr. member
Activity: 449
Merit: 250
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!
full member
Activity: 216
Merit: 100

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.
full member
Activity: 238
Merit: 100
Last couple pages of the Asicminer thread have had an interesting discussion about switching Asicminer shares over to Counterparty:

https://bitcointalksearch.org/topic/m.4907871

Something like this could be really big for the future of not just counterparty but crypto currencies in general.
newbie
Activity: 30
Merit: 0
I have no BTC to burned Smiley
newbie
Activity: 126
Merit: 0
Last couple pages of the Asicminer thread have had an interesting discussion about switching Asicminer shares over to Counterparty:

https://bitcointalksearch.org/topic/m.4907871
sr. member
Activity: 262
Merit: 250

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.
legendary
Activity: 1176
Merit: 1134
Contract Settled: NotEqual won the pot of 2.0 XCP; 0.0 XCP credited to the feed
address (c1cfe0315493ac2c...3fbd9e4e76bff67d)

Woot, first real XCP bet completed. (This could go into the press release, also).
Broncos lost, but oh well. Congrats Seahawks.


I feel proud to be part of this historic event. This could be XCP's "bitcoin pizza". Can't think of a more fitting first XCP transaction than a decentralized bet on the Super Bowl.

Obviously a friendly bet of course. I'd imagine for truly professional-style betting:

1. Trusted member of community / verified ID / DD
2. Announces betting by signing post with BTC/XCP address
3. Collects the bets (with fees)
4. Announces result of bet, signed again
5. Broadcast result of feed
6. (the best part) winnings are distributed automatically, and are completely trustless

The only "trust" in this system is the feed operator, no one else (no middlemen).


It would be great application, if we can make bets on the future price of Bitcoin.

For Example:
1. Price Feed for BTC
2. A betting system that can be used to sell future options/contract in BTC.
e.g., If BTC price is less than XXX, you win so much.

This way you can hedge your position in BTC. If BTC price goes up, you make money from your holdings. If it goes down you can offset some of it using the winning of the bet.
We would need liquidity providers willing to sell the options. People who want to create income from their BTC holdings could sell call options, but it seems only speculators would be willing to sell put options.

Maybe it is just a matter of creating such a market and the put sellers will appear?

Couldn't we create an open source bot who gets the orderbooks from all the usual places and creates a broadcast feed of some simple to calculate average price, eg. one hour moving average. That way, people can't rig the outcome by posting orders on one orderbook at the exact right time, but would have to do it on all orderbooks for an hour.

Any market manipulation that big would effectively be the marketprice, so don't make 100000 BTC bets on the price of BTC Smiley

Is there a way to guarantee that the quotebot will always run and not be modified? If we can solve the issue of needing to trust the feed and created community screened feeds that can be trusted, well, you can see the possibilities. Truly trustless decentralized trading for any data feed that we can make reliable.

James
full member
Activity: 238
Merit: 100
Contract Settled: NotEqual won the pot of 2.0 XCP; 0.0 XCP credited to the feed
address (c1cfe0315493ac2c...3fbd9e4e76bff67d)

Woot, first real XCP bet completed. (This could go into the press release, also).
Broncos lost, but oh well. Congrats Seahawks.


I feel proud to be part of this historic event. This could be XCP's "bitcoin pizza". Can't think of a more fitting first XCP transaction than a decentralized bet on the Super Bowl.

Obviously a friendly bet of course. I'd imagine for truly professional-style betting:

1. Trusted member of community / verified ID / DD
2. Announces betting by signing post with BTC/XCP address
3. Collects the bets (with fees)
4. Announces result of bet, signed again
5. Broadcast result of feed
6. (the best part) winnings are distributed automatically, and are completely trustless

The only "trust" in this system is the feed operator, no one else (no middlemen).


It would be great application, if we can make bets on the future price of Bitcoin.

For Example:
1. Price Feed for BTC
2. A betting system that can be used to sell future options/contract in BTC.
e.g., If BTC price is less than XXX, you win so much.

This way you can hedge your position in BTC. If BTC price goes up, you make money from your holdings. If it goes down you can offset some of it using the winning of the bet.
sr. member
Activity: 364
Merit: 264
Contract Settled: NotEqual won the pot of 2.0 XCP; 0.0 XCP credited to the feed
address (c1cfe0315493ac2c...3fbd9e4e76bff67d)

Woot, first real XCP bet completed. (This could go into the press release, also).
Broncos lost, but oh well. Congrats Seahawks.


I feel proud to be part of this historic event. This could be XCP's "bitcoin pizza". Can't think of a more fitting first XCP transaction than a decentralized bet on the Super Bowl.

Obviously a friendly bet of course. I'd imagine for truly professional-style betting:

1. Trusted member of community / verified ID / DD
2. Announces betting by signing post with BTC/XCP address
3. Collects the bets (with fees)
4. Announces result of bet, signed again
5. Broadcast result of feed
6. (the best part) winnings are distributed automatically, and are completely trustless

The only "trust" in this system is the feed operator, no one else (no middlemen).
sr. member
Activity: 364
Merit: 264
Let's be clear: Counterparty is not yet anywhere near 100% reliable. The basic protocol, however, is, yes, unambiguous, if for no other reason than that it has a reference implementation.
However, it will get there much sooner than mastercoin. The stress test program can be helpful in finding all the bugs.
Any estimate on when counterparty is ready for massive stress testing? I think this will be a critical piece to get in place and then publicize (as soon as XCP passes)

When it comes to money, reliability is really the most important thing. Cost savings is probably in second. By passing stress test, intrinsically from not having fees and with automatic scripts that optimize trade outcomes, we can prove that XCP is not only the most reliable platform, but it makes you the most profit.

James

The thing is that XCP has already been pretty seriously stress tested (in fact, I alone probably broke the network 3-4 times already), and even in alpha state, does work (without anyone's XCP going into a black hole so far). This is undoubtedly due to the massive amount of feedback in this thread.

And about the whale; If I burned 50 grand, I'd at least want something back to recoup my costs (which looks to be what's happening here) no matter how I feel about the project. And 7-8 times over the burn price isn't exactly crashing. In reality, I probably burned less BTC than most people in this thread (simply because I don't have much to begin with). A lot of my cold storage went into this project.
I think the XCP devs are being super cautious about any reliability claims, for obvious reasons. Also, I think you are severely underestimating the level of stress testing I am thinking of. it needs to be so intense that any competitive system would go back home crying to mommy.

Massive amounts of simultaneous transactions, everything, from multiple servers, overflowing blocks, the works.

If we want the rest of the world to use XCP for big money transactions, we must make it 100% reliable. Since the XCP protocol is simple and sane, it might take some time, but it is something that will be achievable. Blackbox testing, clearbox testing, graybox testing, flaw analysis, independent source code reviews, everything.

Raise the bar so high that any competitor would have to spend months and months and months going in circles trying to fix all their bugs. From what I have heard, it sounds like it is quite possible that mastercoin has too much complexity and when you combine too much complexity with large scale real world volumes and complexity, well, it breaks.

James

Well obviously more testing will be needed (and is being done every day). But I can't help but notice that even in alpha state, XCP has more complete, working features than many others coins months post-release (I'm not naming names). Decentralized, cheap (~a quarter in fees), attack-proof sports betting powered by the Bitcoin blockchain...
legendary
Activity: 1176
Merit: 1134
Let's be clear: Counterparty is not yet anywhere near 100% reliable. The basic protocol, however, is, yes, unambiguous, if for no other reason than that it has a reference implementation.
However, it will get there much sooner than mastercoin. The stress test program can be helpful in finding all the bugs.
Any estimate on when counterparty is ready for massive stress testing? I think this will be a critical piece to get in place and then publicize (as soon as XCP passes)

When it comes to money, reliability is really the most important thing. Cost savings is probably in second. By passing stress test, intrinsically from not having fees and with automatic scripts that optimize trade outcomes, we can prove that XCP is not only the most reliable platform, but it makes you the most profit.

James

The thing is that XCP has already been pretty seriously stress tested (in fact, I alone probably broke the network 3-4 times already), and even in alpha state, does work (without anyone's XCP going into a black hole so far). This is undoubtedly due to the massive amount of feedback in this thread.

And about the whale; If I burned 50 grand, I'd at least want something back to recoup my costs (which looks to be what's happening here) no matter how I feel about the project. And 7-8 times over the burn price isn't exactly crashing. In reality, I probably burned less BTC than most people in this thread (simply because I don't have much to begin with). A lot of my cold storage went into this project.
I think the XCP devs are being super cautious about any reliability claims, for obvious reasons. Also, I think you are severely underestimating the level of stress testing I am thinking of. it needs to be so intense that any competitive system would go back home crying to mommy.

Massive amounts of simultaneous transactions, everything, from multiple servers, overflowing blocks, the works.

If we want the rest of the world to use XCP for big money transactions, we must make it 100% reliable. Since the XCP protocol is simple and sane, it might take some time, but it is something that will be achievable. Blackbox testing, clearbox testing, graybox testing, flaw analysis, independent source code reviews, everything.

Raise the bar so high that any competitor would have to spend months and months and months going in circles trying to fix all their bugs. From what I have heard, it sounds like it is quite possible that mastercoin has too much complexity and when you combine too much complexity with large scale real world volumes and complexity, well, it breaks.

James
sr. member
Activity: 364
Merit: 264
Contract Settled: NotEqual won the pot of 2.0 XCP; 0.0 XCP credited to the feed
address (c1cfe0315493ac2c...3fbd9e4e76bff67d)

Woot, first real XCP bet completed. (This could go into the press release, also).
Broncos lost, but oh well. Congrats Seahawks.
newbie
Activity: 36
Merit: 0
Quote
Tx    Source    Buy    Sell    Price    Expiration    Remarks
3148   1NP89QwRSZsyyzHbZ56DdULwjdDiuG6ZZk   8.5 BTC   1000.18181818 XCP   0.00849845482641065 BTC/XCP   1000   1000.18181818 XCP remain
3147   1FYRPCTwwdk7TbujfxpJYBPBxoDtAVgpxm   8.3 BTC   1000.18181818 XCP   0.00829849118343628 BTC/XCP   1000   1000.18181818 XCP remain
3146   1BLZKAsooFKSgfViZy5Nd4SkF9fkFtJ9gB   8.4 BTC   1000.18181818 XCP   0.00839847300492346 BTC/XCP   1000   1000.18181818 XCP remain
3145   1KBNEiTW6frJeQyEtqSwoz8XbbS5zXBF5m   8.2 BTC   1000.18181818 XCP   0.0081985093619491 BTC/XCP   1000   1000.18181818 XCP remain
3144   1GMFpxe4LBH566j5aQnbGSQ2xr6ox6C6TC   7.8 BTC   1000.18181818 XCP   0.00779858207600036 BTC/XCP   1000   1000.18181818 XCP remain
3143   1FKRJhRsS9ZEvYiyhPwKQqDA6U4w1AkDzf   7.7 BTC   1000.18181818 XCP   0.00769860025451318 BTC/XCP   1000   1000.18181818 XCP remain
3142   1HE7cVDjBiL2waUiPRm6puCskjSJT51Dsf   8.1 BTC   1000.18181818 XCP   0.00809852754046191 BTC/XCP   1000   1000.18181818 XCP remain
3141   1G63zk53YuwsYdu6x149iE7sLDndmgQLCG   7.6 BTC   1000.18181818 XCP   0.00759861843302599 BTC/XCP   1000   1000.18181818 XCP remain
3140   1NEwLeKqXbDpcMRzqDKoXkmm9r7HgzmoWc   8 BTC   1000.18181818 XCP   0.00799854571897473 BTC/XCP   1000   1000.18181818 XCP remain
3139   16H3V83hNeA1HoTBqqnyYHR9vpmZ6a5Yxh   7.9 BTC   1000.18181818 XCP   0.00789856389748754 BTC/XCP   1000   1000.18181818 XCP remain
3137   1KDiHRwFsAEVEmmqQP7jR9GaBp8Wu7uLoa   7.5 BTC   1000.18181818 XCP   0.00749863661153881 BTC/XCP   1000   1000.18181818 XCP remain

What is the purpose of this, other than to try and crash the value 24 hours after burn closes? A rational actor would put transactions up a few BTC at a time.

That's the whale who burned 60 BTC right at the end of the burn period. Guess he's not sticking around  Cheesy
The weird thing is I looked up the address on blockscan and it says those addresses have 0 XCP, but it says 1000 remaining on the text above.
Jump to: