So thing is this, you're using proof of burn and/or some derivative of proof of stake or whatever.
Thing is what proof of * you use don't matter. You're not in control of the chain, and anybody can just spam the bitcoin blockchain with fraudulent transactions (double spends, etc.)
And the only way for anybody want to accept any of those assets, would be to calculate the probability of having a real asset in hand from the entire blockchain history that this amount derives off of.
So, very sorry to say that, but, this'll crash&burn. That's just how it is if you forgoe the iron guarantees of proof of work.
Could you give an example of a double spend attack on XCP?
From what I understand, XCP transactions guarantee atomicity and funds are swept from addresses to fund any bets/orders immediately. The risk of double-spending XCP is the same as the risk of double-spending BTC as XCP relies on bitcoin's proof of work.
XCP would rely on the blockchain, and therefore it's atomic transactions are executed. However, the ones putting the transactions in the chain, are not XCP miners. They're bitcoin miners, they don't care what extra information you attach. And by extension, they don't care if they violate some rule in your protocol.
This basically means that XCP-looking transactions will appear in the blockchain, however, they will be invalid, because by the rules of XCP their outputs would already be spent.
In Bitcoin this is an invalid transaction, and it never enters the public ledger. This important because, it allows you to shortcut the path to figure out if an address has unspent outputs. Figuring out quickly if an address has unspent outputs or not is important for miners (they need to produce valid blocks), and it's important for participants to transactions, because it means the recepient can quickly verify that the sender is intending to make the transaction, and that a transaction, sufficiently confirmed, is not double spent. The recepient relies on the work of everybody who produced a block. And in turn, everybody who produces a block relies on the work of everybody before AND on the work of everybody after (who bases their block on his).
This is what I mean by iron-clad guarantee against a double spend.
But if nobody can reject an invalid TX for XCP, that means verifying that something has unspent outputs is an extremely expensive task. And the longer transactions go on, the more expensive this task becomes. And nobody can put in some kind of "block" that could be rejected by others to "proove" that some balances on addresses are now valid up to that point.
This means that in a short time, XCP will become unusable for everybody as the XCP-TX spam rises and everybody is checking the entire bitcoin blockchain over and over and over for XCP-looking TXes to figure out if the coin he thinks he got, aren't actually double spends.
Ok I think I understand your point that XCP-invalid-TX spam cannot be filtered at the point of origin like invalid BTC transactions and a motivated attacker could spam the network to make it extremely slow to use XCP.
I think this is a valid concern, even if somewhat mitigated by the 0.0001 BTC transaction fee. I'll post this to the BTCTalk thread and see if someone smarter than me has an idea to defend against it.
They are actually not using proof of burn. Counterparty is a decentralized exchange that sits on top of bitcoin. As such, I don't think it should be minable, not with proof of work and not with proof of anything.
Proof of burn was used during an initialization phase (let's call it distributed minting) which is over. Should really check it out more thoroughly, it looks like a pretty neat idea.
Thing is what proof of * you use don't matter. You're not in control of the chain, and anybody can just spam the bitcoin blockchain with fraudulent transactions (double spends, etc.)
And the only way for anybody want to accept any of those assets, would be to calculate the probability of having a real asset in hand from the entire blockchain history that this amount derives off of.
So, very sorry to say that, but, this'll crash&burn. That's just how it is if you forgoe the iron guarantees of proof of work.