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.
Regarding the first "same thing"
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)
