There is a small problem with the protocol as it stands: if the issuer of an asset tries to pay dividends on or callback an asset that is then in escrow by the protocol, then the escrowed funds will not be accounted for in the dividend distribution, nor will they be called back with the rest of the asset.
One solution to this problem is to have dividends to and callbacks of asset A force the liquidation of all open orders of asset A. Then BTC would no longer be able to be traded with callable assets, because BTC sell offers cannot be cancelled freely without a material loss to the person who created that order (and paid an unredeemable BTC fee) Or weâd have to switch to a BTC order system which uses exclusively XCP escrows to prevent trolling. (See https://forums.counterparty.co/index.php/topic,132.msg1246.html#msg1246 It would be very hard to keep track of escrowed funds, and dividends paid on escrowed funds, and callbacks of escrowed funds, directly.
For the moment, donât expect asset callbacks to work properly, and dividends wonât be paid to assets of yours currently held in escrow.
Iâm confused or donât understand the problem yet.Â
Is this about paying dividends & escrowing other assets besides XCP? If so, Iâd agree that we should just stick to XCP escrows only.
[font=verdana]Is it possible to âscanâ the orderbook for open order relating to that particular asset and queue the dividend payment till asset is out out escrow, client side?[/font]
[quote author=dropkick link=topic=208.msg1661#msg1661 date=1396122281]
[font=verdana]Is it possible to âscanâ the orderbook for open order relating to that particular asset and queue the dividend payment till asset is out out escrow, client side?[/font]
[/quote]
This is the most complex and fragile of the options, I think.
Thank you for sharing this Phantom. This could be a risk for us where a customer puts an asset in Escrow then redeems that asset for physical delivery. Thus, we cannot call the asset back to remove it from circulation until it is out of escrow. We may have some other issues around this, but weâll have to track all our assets escrow state before we allow redemption.
[quote author=BitcoinTangibleTrust link=topic=208.msg1663#msg1663 date=1396131441]
Thank you for sharing this Phantom. This could be a risk for us where a customer puts an asset in Escrow then redeems that asset for physical delivery. Thus, we cannot call the asset back to remove it from circulation until it is out of escrow. We may have some other issues around this, but weâll have to track all our assets escrow state before we allow redemption.
[/quote]
How could someone redeem an asset in escrow? And callbacks have nothing to do with redemption, either.
[quote author=PhantomPhreak link=topic=208.msg1665#msg1665 date=1396131726]
[quote author=BitcoinTangibleTrust link=topic=208.msg1663#msg1663 date=1396131441]
Thank you for sharing this Phantom. This could be a risk for us where a customer puts an asset in Escrow then redeems that asset for physical delivery. Thus, we cannot call the asset back to remove it from circulation until it is out of escrow. We may have some other issues around this, but weâll have to track all our assets escrow state before we allow redemption.
[/quote]
How could someone redeem an asset in escrow? And callbacks have nothing to do with redemption, either.
[/quote]
We link physical assets (precious metals) to Counterparty assets. If a Counterparty asset is in escrow, then itâs our understanding that the holder of the private key of that address could sign a message with the private key and take the physical asset out of custody/storage. In our business model, we call the digital asset when this verification happens so that we can take the asset out of circulation and the owner doesnât have to send the asset back to us.
In our world, callbacks are our way to take control of the Counterparty asset and this particular issue constrains our ability to use the callback feature in this way when the digital asset is in escrow.
Does this clarify?
[quote author=BitcoinTangibleTrust link=topic=208.msg1666#msg1666 date=1396132696]
[quote author=PhantomPhreak link=topic=208.msg1665#msg1665 date=1396131726]
[quote author=BitcoinTangibleTrust link=topic=208.msg1663#msg1663 date=1396131441]
Thank you for sharing this Phantom. This could be a risk for us where a customer puts an asset in Escrow then redeems that asset for physical delivery. Thus, we cannot call the asset back to remove it from circulation until it is out of escrow. We may have some other issues around this, but weâll have to track all our assets escrow state before we allow redemption.
[/quote]
How could someone redeem an asset in escrow? And callbacks have nothing to do with redemption, either.
[/quote]
We link physical assets (precious metals) to Counterparty assets. If a Counterparty asset is in escrow, then itâs our understanding that the holder of the private key of that address could sign a message with the private key and take the physical asset out of custody/storage. In our business model, we call the digital asset when this verification happens so that we can take the asset out of circulation and the owner doesnât have to send the asset back to us.
In our world, callbacks are our way to take control of the Counterparty asset and this particular issue constrains our ability to use the callback feature in this way when the digital asset is in escrow.
Does this clarify?
[/quote]
Why donât you have users trigger redemption simply by sending the asset to a known address of yours? Thatâs the only secure way of doing it. (In general, not because of this bug.)
Callbacks arenât âtake peopleâs assets away from them and return them to the issuerâ. Thatâd just be useless. Calling back an asset returns to the issuer a constant fraction of an asset from all holders of it. Callable assets should almost exclusively be bonds.
Requiring the assets be sent to you handles everything all at once, in an optimally simple fashion.
Regarding payment of dividends to escrowed funds I canât think of any easy solutions. Iâd classify assets that are currently held in escrow to be still âownedâ by the source address they were escrowed from.
In this case, an addition of an 'escrowâs table which records some details such as the asset, source address and transaction txid associated with the escrow could be created. Each time an asset is held in escrow, this table is updated and each time the escrow released, the appropriate record removed.
When a dividend is issued, it should also scan for assets which are in the escrows table and pay the appropriate amount of dividend to the source address as recorded in the escrows table.
[quote author=BitcoinTangibleTrust link=topic=208.msg1666#msg1666 date=1396132696]
[quote author=PhantomPhreak link=topic=208.msg1665#msg1665 date=1396131726]
[quote author=BitcoinTangibleTrust link=topic=208.msg1663#msg1663 date=1396131441]
Thank you for sharing this Phantom. This could be a risk for us where a customer puts an asset in Escrow then redeems that asset for physical delivery. Thus, we cannot call the asset back to remove it from circulation until it is out of escrow. We may have some other issues around this, but weâll have to track all our assets escrow state before we allow redemption.
[/quote]
How could someone redeem an asset in escrow? And callbacks have nothing to do with redemption, either.
[/quote]
We link physical assets (precious metals) to Counterparty assets. If a Counterparty asset is in escrow, then itâs our understanding that the holder of the private key of that address could sign a message with the private key and take the physical asset out of custody/storage. In our business model, we call the digital asset when this verification happens so that we can take the asset out of circulation and the owner doesnât have to send the asset back to us.
In our world, callbacks are our way to take control of the Counterparty asset and this particular issue constrains our ability to use the callback feature in this way when the digital asset is in escrow.
Does this clarify?
[/quote]
As far as I am aware it is not possible to use an asset that is in escrow in any transaction.
Iâm not sure I understand the reason for using Callbacks?
Canât a person wishing to redeem an asset (physically) backed by your trust, simply send it to a designated address?
Are you trying to take it out of circulation entirely?
[quote author=Global_trade_repo link=topic=208.msg1674#msg1674 date=1396178926]
Regarding payment of dividends to escrowed funds I canât think of any easy solutions. Iâd classify assets that are currently held in escrow to be still âownedâ by the source address they were escrowed from.
In this case, an addition of an 'escrowâs table which records some details such as the asset, source address and transaction txid associated with the escrow could be created. Each time an asset is held in escrow, this table is updated and each time the escrow released, the appropriate record removed.
When a dividend is issued, it should also scan for assets which are in the escrows table and pay the appropriate amount of dividend to the source address as recorded in the escrows table.
[/quote]
Iâve implemented this (for dividends), but without the âescrowsâ table.
Callbacks will be harderâŚ
[quote author=porqupine link=topic=208.msg1678#msg1678 date=1396210397]
[quote author=BitcoinTangibleTrust link=topic=208.msg1666#msg1666 date=1396132696]
[quote author=PhantomPhreak link=topic=208.msg1665#msg1665 date=1396131726]
[quote author=BitcoinTangibleTrust link=topic=208.msg1663#msg1663 date=1396131441]
Thank you for sharing this Phantom. This could be a risk for us where a customer puts an asset in Escrow then redeems that asset for physical delivery. Thus, we cannot call the asset back to remove it from circulation until it is out of escrow. We may have some other issues around this, but weâll have to track all our assets escrow state before we allow redemption.
[/quote]
How could someone redeem an asset in escrow? And callbacks have nothing to do with redemption, either.
[/quote]
We link physical assets (precious metals) to Counterparty assets. If a Counterparty asset is in escrow, then itâs our understanding that the holder of the private key of that address could sign a message with the private key and take the physical asset out of custody/storage. In our business model, we call the digital asset when this verification happens so that we can take the asset out of circulation and the owner doesnât have to send the asset back to us.
In our world, callbacks are our way to take control of the Counterparty asset and this particular issue constrains our ability to use the callback feature in this way when the digital asset is in escrow.
Does this clarify?
[/quote]
As far as I am aware it is not possible to use an asset that is in escrow in any transaction.
Iâm not sure I understand the reason for using Callbacks?
Canât a person wishing to redeem an asset (physically) backed by your trust, simply send it to a designated address?
[/quote]
See my answer above: callbacks are for sophisticated bonds, and redemption should be done, as you say, by sending the funds to a designated address.
[quote author=PhantomPhreak link=topic=208.msg1669#msg1669 date=1396138801]
Why donât you have users trigger redemption simply by sending the asset to a known address of yours? Thatâs the only secure way of doing it. (In general, not because of this bug.)
[/quote]
Great point. We can have Alice send the asset to a BTT known address, but unfortunately if we receive the asset to trigger redemption, we have no way to guarantee that Alice is the person who is picking up the physical asset at the custodian. Bob could easily come to our custodian partner and pick up the asset without any challenge to prove his claim that he actually owns the asset. We use the private key, at redemption to verify that Alice actually owns the asset. We were looking for a way to reduce the number of steps Alice has to take to prove show owns the digital asset AND then to retire the digital asset after redemption. We were using the callable function as a hack to meet this objective. Ideally, we would want to be able to retire assets on Counterparty, but this is not yet available.
[quote author=PhantomPhreak link=topic=208.msg1669#msg1669 date=1396138801]
Callbacks arenât âtake peopleâs assets away from them and return them to the issuerâ. Thatâd just be useless. Calling back an asset returns to the issuer a constant fraction of an asset from all holders of it. Callable assets should almost exclusively be bonds.
[/quote]
Yes. We considered a callable asset equivalent to a repurchase agreement structure. We would buy back the asset at a later date for 0 XCP. Was this an incorrect understanding of the current feature of âcallableâ as you had designed it? Yes, we are thinking about building on this repurchase agreement bond structure in the future.
[quote author=PhantomPhreak link=topic=208.msg1669#msg1669 date=1396138801]
Requiring the assets be sent to you handles everything all at once, in an optimally simple fashion.
[/quote]
I hope we covered this in the first response above. We need to provably show that Alice owns the digital asset independent of BTT involvement. The private key does this for redemption purposes, but when she sends the asset, she no longer has this ability.
[quote author=BitcoinTangibleTrust link=topic=208.msg1681#msg1681 date=1396213063]
[quote author=PhantomPhreak link=topic=208.msg1669#msg1669 date=1396138801]
Why donât you have users trigger redemption simply by sending the asset to a known address of yours? Thatâs the only secure way of doing it. (In general, not because of this bug.)
[/quote]
Great point. We can have Alice send the asset to a BTT known address, but unfortunately if we receive the asset to trigger redemption, we have no way to guarantee that Alice is the person who is picking up the physical asset at the custodian. Bob could easily come to our custodian partner and pick up the asset without any challenge to prove his claim that he actually owns the asset. We use the private key, at redemption to verify that Alice actually owns the asset. We were looking for a way to reduce the number of steps Alice has to take to prove show owns the digital asset AND then to retire the digital asset after redemption. We were using the callable function as a hack to meet this objective. Ideally, we would want to be able to retire assets on Counterparty, but this is not yet available.
[/quote]
Thatâs where the address signatures come in⌠to associate identities with addresses. No hacks are necessary: Counterparty was designed for this use case (among other things).
[quote author=PhantomPhreak link=topic=208.msg1682#msg1682 date=1396214533]
[quote author=BitcoinTangibleTrust link=topic=208.msg1681#msg1681 date=1396213063]
[quote author=PhantomPhreak link=topic=208.msg1669#msg1669 date=1396138801]
Why donât you have users trigger redemption simply by sending the asset to a known address of yours? Thatâs the only secure way of doing it. (In general, not because of this bug.)
[/quote]
Great point. We can have Alice send the asset to a BTT known address, but unfortunately if we receive the asset to trigger redemption, we have no way to guarantee that Alice is the person who is picking up the physical asset at the custodian. Bob could easily come to our custodian partner and pick up the asset without any challenge to prove his claim that he actually owns the asset. We use the private key, at redemption to verify that Alice actually owns the asset. We were looking for a way to reduce the number of steps Alice has to take to prove show owns the digital asset AND then to retire the digital asset after redemption. We were using the callable function as a hack to meet this objective. Ideally, we would want to be able to retire assets on Counterparty, but this is not yet available.
[/quote]
Thatâs where the address signatures come in⌠to associate identities with addresses. No hacks are necessary: Counterparty was designed for this use case (among other things).
[/quote]
Thank you Phantom. So, let me repeat what I understood to be what you shared above to make sure Iâm doing it right: Alice sends her Counterparty asset to BTT. She sent it from her BTC address which we can verify by signing her private key to that address. No hacks are necessary because we will already know what address previously owned the Counterparty asset. As such, no callable type hacks are necessary. Only Alice can sign to prove that she owned the asset. This therefore has nothing to do with the escrow/callable issue above.
[quote author=BitcoinTangibleTrust link=topic=208.msg1683#msg1683 date=1396216881]
[quote author=PhantomPhreak link=topic=208.msg1682#msg1682 date=1396214533]
[quote author=BitcoinTangibleTrust link=topic=208.msg1681#msg1681 date=1396213063]
[quote author=PhantomPhreak link=topic=208.msg1669#msg1669 date=1396138801]
Why donât you have users trigger redemption simply by sending the asset to a known address of yours? Thatâs the only secure way of doing it. (In general, not because of this bug.)
[/quote]
Great point. We can have Alice send the asset to a BTT known address, but unfortunately if we receive the asset to trigger redemption, we have no way to guarantee that Alice is the person who is picking up the physical asset at the custodian. Bob could easily come to our custodian partner and pick up the asset without any challenge to prove his claim that he actually owns the asset. We use the private key, at redemption to verify that Alice actually owns the asset. We were looking for a way to reduce the number of steps Alice has to take to prove show owns the digital asset AND then to retire the digital asset after redemption. We were using the callable function as a hack to meet this objective. Ideally, we would want to be able to retire assets on Counterparty, but this is not yet available.
[/quote]
Thatâs where the address signatures come in⌠to associate identities with addresses. No hacks are necessary: Counterparty was designed for this use case (among other things).
[/quote]
Thank you Phantom. So, let me repeat what I understood to be what you shared above to make sure Iâm doing it right: Alice sends her Counterparty asset to BTT. She sent it from her BTC address which we can verify by signing her private key to that address. No hacks are necessary because we will already know what address previously owned the Counterparty asset. As such, no callable type hacks are necessary. Only Alice can sign to prove that she owned the asset. This therefore has nothing to do with the escrow/callable issue above.
[/quote]
Right. (You might have her sign a statement in person (proving her identity and simultaneously recognising that she received the physical asset), or you might have her associate a mailing address with a Counterparty address on your website, etcâŚ)
[quote author=PhantomPhreak link=topic=208.msg1679#msg1679 date=1396211177]
[quote author=Global_trade_repo link=topic=208.msg1674#msg1674 date=1396178926]
Regarding payment of dividends to escrowed funds I canât think of any easy solutions. Iâd classify assets that are currently held in escrow to be still âownedâ by the source address they were escrowed from.
In this case, an addition of an 'escrowâs table which records some details such as the asset, source address and transaction txid associated with the escrow could be created. Each time an asset is held in escrow, this table is updated and each time the escrow released, the appropriate record removed.
When a dividend is issued, it should also scan for assets which are in the escrows table and pay the appropriate amount of dividend to the source address as recorded in the escrows table.
[/quote]
Iâve implemented this (for dividends), but without the âescrowsâ table.
Callbacks will be harderâŚ
[/quote]
My question is how important is feature to partially callback an asset? Is there a use case that you have in mind?
If there is no particular use case, change callbacks to be 100% of the asset. When an asset is called back, cancel all outstanding orders.
I donât see a problem doing this. Callable assets will be traded at a discount with âcallabilityâ and âbtcpayâ as factors influencing the price.
[quote author=Global_trade_repo link=topic=208.msg1685#msg1685 date=1396221879]
[quote author=PhantomPhreak link=topic=208.msg1679#msg1679 date=1396211177]
[quote author=Global_trade_repo link=topic=208.msg1674#msg1674 date=1396178926]
Regarding payment of dividends to escrowed funds I canât think of any easy solutions. Iâd classify assets that are currently held in escrow to be still âownedâ by the source address they were escrowed from.
In this case, an addition of an 'escrowâs table which records some details such as the asset, source address and transaction txid associated with the escrow could be created. Each time an asset is held in escrow, this table is updated and each time the escrow released, the appropriate record removed.
When a dividend is issued, it should also scan for assets which are in the escrows table and pay the appropriate amount of dividend to the source address as recorded in the escrows table.
[/quote]
Iâve implemented this (for dividends), but without the âescrowsâ table.
Callbacks will be harderâŚ
[/quote]
My question is how important is feature to partially callback an asset? Is there a use case that you have in mind?
If there is no particular use case, change callbacks to be 100% of the asset. When an asset is called back, cancel all outstanding orders.
I donât see a problem doing this. Callable assets will be traded at a discount with âcallabilityâ and âbtcpayâ as factors influencing the price.
[/quote]
Just to be clear, the problem with cancelling outstanding orders is that order matches waiting for BTC payment canât be cancelled without a loss to the person selling the BTC, because the BTC fee that he paid canât be refunded. This, however, is not necessarily a deal-breaker, in my opinion.
We could implement this, of course, even allowing for fractional callbacks.
[quote author=PhantomPhreak link=topic=208.msg1686#msg1686 date=1396222192]
[quote author=Global_trade_repo link=topic=208.msg1685#msg1685 date=1396221879]
[quote author=PhantomPhreak link=topic=208.msg1679#msg1679 date=1396211177]
[quote author=Global_trade_repo link=topic=208.msg1674#msg1674 date=1396178926]
Regarding payment of dividends to escrowed funds I canât think of any easy solutions. Iâd classify assets that are currently held in escrow to be still âownedâ by the source address they were escrowed from.
In this case, an addition of an 'escrowâs table which records some details such as the asset, source address and transaction txid associated with the escrow could be created. Each time an asset is held in escrow, this table is updated and each time the escrow released, the appropriate record removed.
When a dividend is issued, it should also scan for assets which are in the escrows table and pay the appropriate amount of dividend to the source address as recorded in the escrows table.
[/quote]
Iâve implemented this (for dividends), but without the âescrowsâ table.
Callbacks will be harderâŚ
[/quote]
My question is how important is feature to partially callback an asset? Is there a use case that you have in mind?
If there is no particular use case, change callbacks to be 100% of the asset. When an asset is called back, cancel all outstanding orders.
I donât see a problem doing this. Callable assets will be traded at a discount with âcallabilityâ and âbtcpayâ as factors influencing the price.
[/quote]
Just to be clear, the problem with cancelling outstanding orders is that order matches waiting for BTC payment canât be cancelled without a loss to the person selling the BTC, because the BTC fee that he paid canât be refunded. This, however, is not necessarily a deal-breaker, in my opinion.
We could implement this, of course, even allowing for fractional callbacks.
[/quote]
I agree, itâs not a deal breaker to cancel outstanding orders for called back assets for the reason that callable assets will find their price on the market appropriately.
I donât think itâs a good idea to implement cancellation of all orders for fractional callbacks. The reason is it doesnât make functional sense whereas cancellation of all open orders for a 100% callback makes perfect sense.
Unless there was a use case for a fractional callback, Iâd remove it to simplify the protocol and to make the calling process consistent.
An optional partial call back could be performed by the issuer by a repurchase order on the DEX.
[quote author=Global_trade_repo link=topic=208.msg1687#msg1687 date=1396223881]
I donât think itâs a good idea to implement cancellation of all orders for fractional callbacks. The reason is it doesnât make functional sense whereas cancellation of all open orders for a 100% callback makes perfect sense.
[/quote]
I donât follow. Can you elaborate a little on this point?