Idea: Advanced Conditional Asset Trade

The idea is still at the brainstorming stage. It goes as follows:

  • This will be a new transaction type

  • A seller sets conditions for a sale

  • A transfer takes place when a buyer meets the conditions

  • This is not a market place, as each conditional sale is independent

  • Example use cases
    ** Escrow X assets on Alice’s address, to be sent to Bob after Bob transfers her Y BTC (this is simpler than BTCPAY on the DEX)
    ** Lottery where whoever bets X amount of asset has a chance of winning 100X of asset
    ** Sale of exactly one unit of a divisible token (on the DEX this is not possible - a problem if a card initially was made divisible)
    ** Sale of a random token
    ** Sale of a pack of random random cards
    ** Sale of an asset that only Bob can buy

  • This will all be coded into one function. When the seller makes an offer, all the parameters are set. Here’s what the parameters may be
    ** Sell asset - can be a single asset or XCP (but not BTC) or an array of assets or all current assets on address or all assets on address at any time
    ** Buy asset - is the asset buyer must send to address to make the trade. Can be a single asset, XCP or BTC
    ** Sell probability - value from 0 to 1, inclusive. 1 means a regular deterministic trade. Between 0 and 1 means the probability of buyer getting assets, else he gets nothing while the buy asset goes to the seller. 0 means probability proportional to current assets or assets at time respectively. If an array of sell asset, then an array of probabilities is possible, else the same value applies to all assets.
    ** Sell price - value is amount to sell per unit of buy asset. If an array of assets, a corresponding array of prices is possible, else the same value applies to all assets.
    ** Escrow amount - value is number or array of numbers of sell assets. Left out means the entire balance(s) of the respective asset(s) on the address are for sale.
    ** Min buy - value is the minimum allowed buy assets in a transaction. Left out means no minimum
    ** Max buy - value is the maximum allowed buy assets in a transaction. Left out means implied maximum by the sell assets escrowed.
    ** End time - value is either specific block or number of blocks from now
    ** Cancel - boolean. True means seller can cancel the offer before it expires
    ** Buyer - value is address who has the right to buy. If several, then an array. If left out then anyone can buy.

Alice makes a simple lottery. You send her 1 XCP. With a 0.9% probability you win 100 XCP, else you lose that one XCP.

To initiate this she sells XCP and buys XCP at prob=0.009 with price of 100 and escrows 100 XCP. Min buy and max buy are both set to 1.

Bob places a 1 XCP bet and loses.
Charlie places a 1 XCP bet and wins.
Alice is left with only 2 XCP and Charlie gets the 100 XCP jackpot.
Then the contract is automatically terminated since there is not enough on escrow for further bets.

Alice makes the same bet again but now with all XCP on the address on escrow and proportional probability. She starts with 2 XCP.
Bob bets 1 XCP and has 1/2 chance of winning 2 XCP. He loses
Charlie bets 1 XCP and has 1/3 chance of winning 3 XCP. He loses
Derrick bets 1 XCP and has 1/4 chance of winning 4 XCP. He wins
Then the contract is automatically terminated
(More advanced parameter options could make the payout less than 100%)

Alice agrees to sell a GAMEASSET to Bob for 0.1 BTC.
She places it for sale and specifies that only Bob can buy it.
Bob transfers the amount of BTC and gets the GAMEASSET.
(This is faster and cheaper than the DEX. Two txs instead of three. Also it eliminates the risk of a 3rd person snapping up the asset)

Alice has 10 GOLDCARD and 90 SILLYCARD. She puts probabilities 10% for G.C and 90% for S.C. Price is 10 XCP.
Bob pays 10 XCP and gets 1 S.C.
Charlie pays 20 XCP and gets 1. G.C and 1 S.C
Derrick tries to pay 20 XCP but transaction is invalid since a potential outcome is 2 G.C, which is more than on escrow
Eric pays 17 XCP and gets 1 S.C. and 7 XCP refunded since these are indivisible cards.
Franco pays 10 XCP and gets nothing. Unlucky, he lost both the 10% shot at G.C and 90% shot at 90 S.C

This last example illustrates that this approach will have limitations where you cannot always set the conditions you want. Maybe the buyer should always get one card per 10 XCP with a 10% shot at G.C and 90% prob of S.C.

Still, more parameters than those I outlined will reduce such problems. Especially boolean variables are great since they only take up one bit.

Since all logic fit one function, it shall not be too difficult to validate the code.

Potential spam problems are reduced with mandatory XCP fees.

I expect a lengthy discussion on which conditions to include and some very specific wishes. Generally, I just want the widest set of options for as many REAL use cases as possible. I mean, whatever people realistically are expected to use.

Let’s discuss iterations on this particular idea on this thread.

Whether hard coding new features is a good idea at all; discuss it here : Hard coded features better than EVM? The previous consensus was that it adds complexity which does not make sense with the EVM around the corner. Now with the EVM on hold, I think we should rethink this position.

In concept, I think this a great idea, a sort of “rule set” for transactions. My first thought is instead of creating a single new tx type, maybe we could just concatenate the rules to existing txs and create something like “advanced send” or “advanced dex order”.

Regarding encoding, since the rules are predefined, we could use something like the key/value pairs I described for subassets. Attached to the end of the standard tx data for a send or order, a single prefix byte that represents the key (unique for each implemented rule) followed by the value with a certain fixed number of bytes (which will vary based on the rule type).

Implementation is important, and I think we’d want a way to limit transactions to 80 bytes so that OP_RETURN encoding is an option. You could have a sort of incomplete tag to leave the transaction in a “pending” state, then add additional rules with additional txs, followed ultimately by a complete tag to indicate the tx should be open.


I came across this interesting issue earlier today (it’s about SIGHASH_SINGLE):

I wonder if SIGHASH_SINGLE may be useful for conditional trades (including of BTC).