Topic: [ANN][XCP] Counterparty - Pioneering Peer-to-Peer Finance - Official Thread - page 238. (Read 1276936 times)
July 04, 2014, 10:04:45 AM
I think counterparty desperately needs a software/downloadable wallet that anyone can use. Having to use the webwallet is something I hate. and feels alot less secure.
July 04, 2014, 07:59:25 AM
Blockchain.info shows balance of 0.0035306 BTC in my address though counterwallet.co shows only Bal: 0.0021882
Why like this ?
Why like this ?
July 04, 2014, 02:22:46 AM
I shudder to think how much I have spend on btc transaction fees on failed sales of xcp for btc. Order cancel themselves especially mysteriously or the btc holders are logged out so the do not pay... Meh.
Yeah, I agree that this is a problem. Pissing away satoshis on mysteriously failed orders doesn't feel good. I realize that the amounts involved are small, but multiply by X and they get bigger.
They need to be more like the real exchanges in this area. (No fees for cancelled orders). Would encourage people to make more use of the CP exchange.
The problem as noted numerous times in this thread is that the BTC distributed exchanging is attempted to be conducted similar to exchanging assets (XCP <-> MPTSTOCK, etc.) which inevitably creates problems due to the nature of BTC being outside of native XCP assets.
If the developers would embrace the OPTION nature of a BTC transaction it would flow much more logically and smoothly. First transaction CREATES option to spend BTC for whatever there is. Second transaction EXECUTES the option. Obviously only the BTC holder holds the option but either party can create a possible option. so either of 3 steps for a full option creation/trade/execution:
a) asset holder creates/offers possible option (for BTC or XCP fee), BTC holder pays for/accepts/is granted option, BTC holder executes option.
b) BTC holder offers to buy asset option (escrows XCP fee), asset holder accepts fee/creates/grants option, BTC holder executes option.
Variables such as duration (before/after acceptance), fee, etc. are determined in first step. It will naturally lead to low fees for straight trading of BTC for assets.
On another note, why hasn't there been distributed gambling based on native variables such as the block difficulty? actually block difficulty is purely random since no miner will withhold blocks since they are likely to not generate another before another miner does. i.e. no feed required, no trust required for feed provider, done natively by protocol. There could be tons of variables native to the protocol such as number of transactions in a given block, total assets transferred in a block, the hash of all new xcp addresses funded in a block or some combination to have more randomness. Almost purely random provided there is sufficient liquidity and would eliminate the need for a feed operator and entice the satoshi dice style gamblers. There could be a slight weighting for the majority win % since leverage is its own reward so 99% chance winner could get 2% profit while 1% chance winner only gets 500% profit (i.e. 50 units to 1 unit bet matching ratio but the 50 units gets 99% odds of winning all 51 while 1 units gets 1% odds to take all 51).
Two areas (of many previously noted) where counterparty protocol dropped the ball. Are there any competitors that got this right?
The only reliable source of entropy is the block hash (everything else miners can easily game), but we've come up with something even better than the system that you describe.
How does the asset (xcp or other) option offeror choose if they will get paid an option fee of btc or xcp for offering the option? How do they specify the amount of the option fee they charge?
How does asset offeror receive an option fee for unexecuted options? How is the duration time to live of the unexecuted option specified?
Does your "better system" allow only 2 (or less) participants to the bet with no fees charged as I proposed? Isn't there reliance on trusted feed providers for the "better system" bets? i.e. must we trust a feed provider not to game the system to direct the win where they choose? I see the block hash is one better system of entropy, but isn't exact difficulty of a block also extremely unlikely to be frustrated? I guess the block hash is the better trustless feed source for gambling in counterparty.
To the Moon! (because I still have some left to sell)
July 03, 2014, 11:34:40 PM
I shudder to think how much I have spend on btc transaction fees on failed sales of xcp for btc. Order cancel themselves especially mysteriously or the btc holders are logged out so the do not pay... Meh.
Yeah, I agree that this is a problem. Pissing away satoshis on mysteriously failed orders doesn't feel good. I realize that the amounts involved are small, but multiply by X and they get bigger.
They need to be more like the real exchanges in this area. (No fees for cancelled orders). Would encourage people to make more use of the CP exchange.
The problem as noted numerous times in this thread is that the BTC distributed exchanging is attempted to be conducted similar to exchanging assets (XCP <-> MPTSTOCK, etc.) which inevitably creates problems due to the nature of BTC being outside of native XCP assets.
If the developers would embrace the OPTION nature of a BTC transaction it would flow much more logically and smoothly. First transaction CREATES option to spend BTC for whatever there is. Second transaction EXECUTES the option. Obviously only the BTC holder holds the option but either party can create a possible option. so either of 3 steps for a full option creation/trade/execution:
a) asset holder creates/offers possible option (for BTC or XCP fee), BTC holder pays for/accepts/is granted option, BTC holder executes option.
b) BTC holder offers to buy asset option (escrows XCP fee), asset holder accepts fee/creates/grants option, BTC holder executes option.
Variables such as duration (before/after acceptance), fee, etc. are determined in first step. It will naturally lead to low fees for straight trading of BTC for assets.
This is how the current system works, of course. It's just called the same thing.
On another note, why hasn't there been distributed gambling based on native variables such as the block difficulty? actually block difficulty is purely random since no miner will withhold blocks since they are likely to not generate another before another miner does. i.e. no feed required, no trust required for feed provider, done natively by protocol. There could be tons of variables native to the protocol such as number of transactions in a given block, total assets transferred in a block, the hash of all new xcp addresses funded in a block or some combination to have more randomness. Almost purely random provided there is sufficient liquidity and would eliminate the need for a feed operator and entice the satoshi dice style gamblers. There could be a slight weighting for the majority win % since leverage is its own reward so 99% chance winner could get 2% profit while 1% chance winner only gets 500% profit (i.e. 50 units to 1 unit bet matching ratio but the 50 units gets 99% odds of winning all 51 while 1 units gets 1% odds to take all 51).
Two areas (of many previously noted) where counterparty protocol dropped the ball. Are there any competitors that got this right?
The only reliable source of entropy is the block hash (everything else miners can easily game), but we've come up with something even better than the system that you describe.
July 03, 2014, 10:12:58 PM
Thanks for the feeback. As I understand it, the NXT asset exchange was easier to use for three reasons:
1) Buying NXT could be done by sending BTC to an address.
2) There exists a website where you can easily see a list of existing assets.
3) The trades were completed quickly.
1) and 2) are not handled by the protocol, they are just external services that no one has yet set up for Counterparty. Moreover, I know that we have people that are currently working on them right now. With regard to 3), I can say that your trades with Counterparty would have been completed very quickly, too, if you used XCP, Counterparty's native currency, instead of BTC, to make your trades. Because of 1), Counterparty users are inclined to buy assets with BTC rather than XCP, which is much slower. Of course, NXT could never support trades with BTC.
July 03, 2014, 08:03:15 PM
I shudder to think how much I have spend on btc transaction fees on failed sales of xcp for btc. Order cancel themselves especially mysteriously or the btc holders are logged out so the do not pay... Meh.
Yeah, I agree that this is a problem. Pissing away satoshis on mysteriously failed orders doesn't feel good. I realize that the amounts involved are small, but multiply by X and they get bigger.
They need to be more like the real exchanges in this area. (No fees for cancelled orders). Would encourage people to make more use of the CP exchange.
The problem as noted numerous times in this thread is that the BTC distributed exchanging is attempted to be conducted similar to exchanging assets (XCP <-> MPTSTOCK, etc.) which inevitably creates problems due to the nature of BTC being outside of native XCP assets.
If the developers would embrace the OPTION nature of a BTC transaction it would flow much more logically and smoothly. First transaction CREATES option to spend BTC for whatever there is. Second transaction EXECUTES the option. Obviously only the BTC holder holds the option but either party can create a possible option. so either of 3 steps for a full option creation/trade/execution:
a) asset holder creates/offers possible option (for BTC or XCP fee), BTC holder pays for/accepts/is granted option, BTC holder executes option.
b) BTC holder offers to buy asset option (escrows XCP fee), asset holder accepts fee/creates/grants option, BTC holder executes option.
Variables such as duration (before/after acceptance), fee, etc. are determined in first step. It will naturally lead to low fees for straight trading of BTC for assets.
On another note, why hasn't there been distributed gambling based on native variables such as the block difficulty? actually block difficulty is purely random since no miner will withhold blocks since they are likely to not generate another before another miner does. i.e. no feed required, no trust required for feed provider, done natively by protocol. There could be tons of variables native to the protocol such as number of transactions in a given block, total assets transferred in a block, the hash of all new xcp addresses funded in a block or some combination to have more randomness. Almost purely random provided there is sufficient liquidity and would eliminate the need for a feed operator and entice the satoshi dice style gamblers. There could be a slight weighting for the majority win % since leverage is its own reward so 99% chance winner could get 2% profit while 1% chance winner only gets 500% profit (i.e. 50 units to 1 unit bet matching ratio but the 50 units gets 99% odds of winning all 51 while 1 units gets 1% odds to take all 51).
Two areas (of many previously noted) where counterparty protocol dropped the ball. Are there any competitors that got this right?
July 03, 2014, 02:54:09 PM
The problem with editable odds is that they need to match exactly for a match to be made. The current implementation is logarithmic at 1/20 increments. I think maybe it would look cleaner as whole number fractions?
Yes, let me fix the redirect, thanks.
Well thought out
Indeed, it would be better with 0.10 increments (bigger round increments after 2.00 odd, like 0.20 and round number after 5)
Also, I just realized that the odds are fractional, you should add a numerical odd display (Thus even odds 1/1 are quoted in decimal odds as 2)
July 03, 2014, 02:39:42 PM
https://xcpfeeds.info/ is LIVE.
Excellent, testing right now
edit : ok when clicking on the "Create Bet" after filling all the fileds, nothing happens (chrome browser)
Sorry bout that, should be fixed.
Indeed, it's working.
You should let the odds field editable (and/or the return on win field), since the slider isn't really precise (eg. it goes from 2.86 to 3.33)
Then it creates a raw transaction that should be signed with "sign transaction" in couterwallet, right ? Your link when clicking on sign with counterwallet redirects to testnet counterwallet.
Great work !
The problem with editable odds is that they need to match exactly for a match to be made. The current implementation is logarithmic at 1/20 increments. I think maybe it would look cleaner as whole number fractions?
Yes, let me fix the redirect, thanks.
July 03, 2014, 02:31:56 PM
https://xcpfeeds.info/ is LIVE.
Excellent, testing right now
edit : ok when clicking on the "Create Bet" after filling all the fileds, nothing happens (chrome browser)
Sorry bout that, should be fixed.
Indeed, it's working.
You should let the odds field editable (and/or the return on win field), since the slider isn't really precise (eg. it goes from 2.86 to 3.33)
Then it creates a raw transaction that should be signed with "sign transaction" in couterwallet, right ? Your link when clicking on sign with counterwallet redirects to testnet counterwallet.
Great work !
July 03, 2014, 02:18:12 PM
https://xcpfeeds.info/ is LIVE.
Excellent, testing right now
edit : ok when clicking on the "Create Bet" after filling all the fileds, nothing happens (chrome browser)
Sorry bout that, should be fixed.
July 03, 2014, 01:51:28 PM
https://xcpfeeds.info/ is LIVE.
Excellent, testing right now
edit : ok when clicking on the "Create Bet" after filling all the fileds, nothing happens (chrome browser)
July 03, 2014, 01:16:49 PM
https://xcpfeeds.info/ is LIVE.
July 03, 2014, 11:13:16 AM
XCP/BTC market added on 51btc more details: https://www.51btc.com
July 03, 2014, 05:10:08 AM
I agree that a rough time estimation may be better.
July 03, 2014, 03:48:20 AM
Hi,
Looked at your video the trade time was measured by blocks !
Erm simplify > can you not use a clock / 24hrs ect
Looked at your video the trade time was measured by blocks !
Erm simplify > can you not use a clock / 24hrs ect
No. There is no bitcoin clock, only the bitcoin blockchain which has a variance that ranges from seconds between blocks to over an hour. Lacking a clock, you have to count blocks. It's not exact, but it's real and its decentralized.
Maybe something like "estimated time" may be possible, at least in days.. But I'm not even sure how accurate that would be.
July 02, 2014, 04:43:57 PM
Hi,
Looked at your video the trade time was measured by blocks !
Erm simplify > can you not use a clock / 24hrs ect
Looked at your video the trade time was measured by blocks !
Erm simplify > can you not use a clock / 24hrs ect
No. There is no bitcoin clock, only the bitcoin blockchain which has a variance that ranges from seconds between blocks to over an hour. Lacking a clock, you have to count blocks. It's not exact, but it's real and its decentralized.
July 02, 2014, 02:34:03 PM
Hi,
Looked at your video the trade time was measured by blocks !
Erm simplify > can you not use a clock / 24hrs ect
Looked at your video the trade time was measured by blocks !
Erm simplify > can you not use a clock / 24hrs ect
July 02, 2014, 10:21:37 AM
(4) Dust amounts on escrows accumulate. It would be good to view this amount under "My Account Balances" and redeem it by one click.
These specific points I want to strongly echo, 100% agree.
Yes, very good points. All of those problems now have GitHub Issues, and we'll fix them as soon as possible. Thanks!
An automatic integration of a coinsweeper-like function would be dope !
July 02, 2014, 09:54:53 AM
(2) The GUI for trading can be more intuitive. I know you are working on this, and I look forward to the update. Personally I like the GUI at bter.com. You can click on a price in the order book and it fills in the trade form automatically. Click on your balance and it fills out quantity. Buy and sell forms are side by side are on the same page. In counterwallet you could do the same, i.e. on the first page only select asset #1 and asset #2, but not specifying which ones to buy and sell.
(3) When an order matches, the user should immediately get a notice. E.g. "Order Matched. Pending Block Confirmation". Real time feedback is very important for most users.
(4) Dust amounts on escrows accumulate. It would be good to view this amount under "My Account Balances" and redeem it by one click.
(3) When an order matches, the user should immediately get a notice. E.g. "Order Matched. Pending Block Confirmation". Real time feedback is very important for most users.
(4) Dust amounts on escrows accumulate. It would be good to view this amount under "My Account Balances" and redeem it by one click.
These specific points I want to strongly echo, 100% agree.
Yes, very good points. All of those problems now have GitHub Issues, and we'll fix them as soon as possible. Thanks!
July 02, 2014, 09:45:04 AM
(2) The GUI for trading can be more intuitive. I know you are working on this, and I look forward to the update. Personally I like the GUI at bter.com. You can click on a price in the order book and it fills in the trade form automatically. Click on your balance and it fills out quantity. Buy and sell forms are side by side are on the same page. In counterwallet you could do the same, i.e. on the first page only select asset #1 and asset #2, but not specifying which ones to buy and sell.
(3) When an order matches, the user should immediately get a notice. E.g. "Order Matched. Pending Block Confirmation". Real time feedback is very important for most users.
(4) Dust amounts on escrows accumulate. It would be good to view this amount under "My Account Balances" and redeem it by one click.
(3) When an order matches, the user should immediately get a notice. E.g. "Order Matched. Pending Block Confirmation". Real time feedback is very important for most users.
(4) Dust amounts on escrows accumulate. It would be good to view this amount under "My Account Balances" and redeem it by one click.
These specific points I want to strongly echo, 100% agree.
Jump to: