Are multi-blockchain assets for cross-blockchain trading possible?

Projects
1

I wondered if the following scenario would be possible with PeerAssets:

  • A person or group issues a PeerAsset on two blockchains (for example, PPC and BTC): PPCPeerAsset and BTCPeerAsset.
  • To prove it’s the same person, there is a special message digitally signed by this person in both blockchains.
  • The issuer states that if a PPCPeerAsset is burnt, a BTCPeerAsset will be created and transferred to the same owner, and the other way around. In the “burn transaction” the “burner” must specify its address on the other blockchain. Maybe these additional steps can be done automatically by the client, but the asset creation on the other blockchain must be signed by the asset creator’s private key.

Now, in theory, if I buy an asset of this kind with BTC, I can trade it directly to the PPC asset.

As (like we were discussing in the main PeerAssets thread) it is possible to trade PPC to a PeerAsset (and BTC to PeerAsset) in a trustless manner via a multi-input multi-signature transaction, this could allow the following cross-blockchain trade:

  • Step 1: BTC -> BTCPeerAsset
  • Step 2: BTCPeerAsset -> PPCPeerAsset (BTCPeerAsset is burnt, PPCPeerAsset created)
  • Step 3: PPCPeerAsset -> PPC

It would not be totally trustless (because the PeerAsset issuer or “issuer group” is involved) but it may be a more secure solution than today’s altcoin exchanges. The issuer, for example, could be a larger group of PPC/BTC users from which the majority must sign the “transfer transaction”, so it would not depend on a single user.

Am I overlooking something or is this scenario possible with PeerAssets? Is something like this the “blockchain independence” stated in the whitepaper?

That may be possibly a pretty advanced application and obviously not a feature for the first version. But it would be interested if this is possible with actual PPC protocol and the proposed PeerAssets specification.

2

Edit:Accidently clicked post before finishing.

Just a thought.

For initial asset creation lets assume there is an originating chain. Let’s say it’s a PeerAsset on the PPC blockchain.

Within the initial deck spawning metadata I believe there would exist stated intended authority addresses, deterministic, which are associated with other chains that PeerAssets will be created, modified, burned, or transferred . In this way the client will be able to verify status of a given asset based on tagged transactions utilizing P2TH. In this original deck spawning the protocol would have the information necessary to verify the status of a given Asset on the individual chains where the addresses that have been given authority to create, transfer, or burn assets exist.

So first would be the deck spawning transaction which is specified through P2TH as “PeerAssets/deck spawning”+salt

meta = { name: hopium
quantity: 120
BTC:14kbuTxMeVCkPrnHGoXP19GAxrEFUBaCBa
LTC:LWTnPCVWhVstHFwRedERdBTdCwcVS2y6cX
}.

It would then determine if it is a multi-chain asset by referencing the meta data provided during deck spawning.
If there is to be a transfer of an asset then the transaction, transferring a PPC PeerAsset to a BTC PeerAsset , metadata would look something like

meta = { name: hopium
quantity: 60
PPC:PDZbeauCyhLpoUHwrsQeJj98YzjUt3yiyK
BTC:1AbpgTp7dbW2wDPfpBmxLzuaPAVS2659ho
}.
where this transaction is sent by and to the owner of the asset in order to burn and transfer ownership.
The BTC address now creates an asset which is only valid if it includes within the transaction meta data the transaction id showing the burn of asset on previous chain.

This is a deck spawning transaction which is specified through P2TH as “PeerAssets/deck spawning”+salt
meta = { name: hopium
quantity: 60
transaction: dd8711a72832a2af9821209d4b3edd564348dad229dbcd19b9f08e6875acf210
}.
With this, the original deck spawning transaction can be found by walking up the transaction chain until the deck spawning transaction is reached.

If an asset’s ownership is transferred from the PPC addresses to the BTC address listed above then the client must subsequently check the BTC address and deduce, through the use of proof of timeline, a valid history of the asset by following P2TH tagged transactions.

The following would transfer ownership of 30 units of total quantity from the asset owned by the BTC address to a LTC address
meta = { name: hopium
quantity: 30
BTC:1AbpgTp7dbW2wDPfpBmxLzuaPAVS2659ho
LTC:LStZaGSJKqGjAyfztewXpZhW9Lo8XwyRGz
}.

Edit 2: removed confusing language.

3

Transferring funds from a PPC to a BTC address is exactly the same as transferring between PPC addresses.
There is no third party or burning involved.

The only thing needed is a system that zips the two blockchains, which can be implemented as a PeerAsset. Timestamps of different chains are not reliable. AFAIK BTC blocks can be given any timestamp as long as it is later than the previous block.

Practically this means is that the issuer will need to indicate which chains are valid for their asset, nothing more.

4

@saeveritt: Yes, that was aproximately the way I thought it would work …

@hroebers: Thanks! That is really interesting and would make cross-blockchain trading via PeerAssets even easier.

But wouldn’t there be confusion if an asset was created in one chain (let’s say PPC), identified by a transaction ID, and - in theory - there is another transaction in another blockchain with the same ID? Or are transaction IDs unique across blockchains, e.g. determined by the “magic bytes” of every chain?

(I’m not so much of an expert, perhaps I need to read the whitepaper once more and dig a bit into the Bitcoin protocol …)

5

I made this quick diagram in order to express my thoughts more clearly.

DLxucxs.png1332×1091

[quote=“hrobeers, post:3, topic:3955”]The only thing needed is a system that zips the two blockchains, which can be implemented as a PeerAsset.
Practically this means is that the issuer will need to indicate which chains are valid for their asset, nothing more.[/quote]

I’m not sure I fully understand how the system will zip the two blockchains together.
Could the way I mentioned above be a valid method to indicate which chain is valid for their asset?

For Cross-Chain Asset Transfer (XCAT?) the stated address is given the authority on the new chain to create that particular asset at that quantity which was burned. The new address automatically become an issuing address bound and limited by name and quantity stated by the respective burn transactionID. During issuance on new chain the transaction must include the transactionID of the burned asset in order to provide proof of ownership and must use the same name and a value of quantity that is equal to the burned name and quantity. To check if a quantity is valid on a chain that is not the assets originating chain you would walk up the transaction list until the last one that contains proof of burn transaction id, then you could walk up that transaction list to arrive at the original deck spawning transaction

Also, having those authority addresses gives the deck spawner the ability to create new quantity on each chain individually. So there would be two methods of adding quantity to a chain. One would be the transfer method by the owner and the other would be new issuance by the deck spawner/authority addresses.

6

[member=31975]saeveritt[/member] you’re overcomplicating it.
There is no such thing as multiple authority addresses on multiple chains, there is only one issuance address in the whole system.

The key to this is to zip the two (or more) blockchains into one chain like a zipper:

The resulting chain will be the proof-of-timeline.

7

[quote=“hrobeers, post:6, topic:3955”][member=31975]saeveritt[/member] you’re overcomplicating it.
There is no such thing as multiple authority addresses on multiple chains, there is only one issuance address in the whole system.

The key to this is to zip the two (or more) blockchains into one chain like a zipper:

The resulting chain will be the proof-of-timeline.[/quote]

I understand the zipper analogy but wouldn’t that require external trust in the system that is combining the chains?
Also, why limit the system to having one issuance address when the possibility of multiple addresses being capable of issuance exists?

One would be able to deduce a proper proof of timeline through the manner I suggested in cross chain asset transfer even without the use of multiple issuance addresses.

8

The zipping would indeed be done by a third party.

I see this third party as a PeerAssets DAO that uses PoS to zip all supported chains.
This DAO would deliver the “zipping service” to all multi chain PeerAssets.

If I understand your idea correctly, transferring assets between chains would require the asset issuer to respawn the assets burned on one chain, on the other chain.
Imagine that the node(s) having access to the issuance key(s) are temporarily (or permanently) unavailable, that would mean that the chain to chain transfer is blocked for an extended period of time.

I’d rather have a dependency on a decentralized third party (zipping DAO) rather than a centralized one (asset issuer).

[member=31975]saeveritt[/member] Did I understood your diagram correctly?

9

[quote=“hrobeers, post:8, topic:3955”]If I understand your idea correctly, transferring assets between chains would require the asset issuer to respawn the assets burned on one chain, on the other chain.
Imagine that the node(s) having access to the issuance key(s) are temporarily (or permanently) unavailable, that would mean that the chain to chain transfer is blocked for an extended period of time.[/quote]

The ownership of the named asset and its quantity is declared during the burn transaction on the first chain. Even though the deck has yet to be spawned on the receiving chain the owner is known. The length of time until re-spawning the asset on the receiving chain would be dependent upon use case and does not delay or invalidate ownership. To validate, walking up the transaction list from the burn transactionid must always lead to the original deck spawning transaction by the Issuer.

10

Ok that makes sense, apparently I understood you incorrectly.
But how do we maintain the total asset checksum (the sum of the balance of all addresses is 0).

With the current proposal, the balance of the issuance address is the negative of the total issued assets.
Provable burning is done by sending your assets back to the issuance address which maintains the checksum.

Do you have an idea on how to do this?
Do we need a dedicated burn address per chain?

11

[quote=“hrobeers, post:10, topic:3955”]Ok that makes sense, apparently I understood you incorrectly.
But how do we maintain the total asset checksum (the sum of the balance of all addresses is 0).[/quote]

A cross-chain asset transfer wouldn’t be considered reducing the quantity total of the asset, just burning ownership and declaring a new owner on a separate chain. In the diagram the multi chain addresses designated in meta data during deck spawning would be the burn addresses, in terms of quantity, for each respective chain. In this way we can always get the total asset checksum by checking these addresses for either issuance or burned quantities to compare for checksum.

12

So my question again, do we need a dedicated burn address per chain?
e.g. a dedicated burn address for transfers from ppc to btc.

Because the burn shouldn’t be accounted for in the checksum.

13

[quote=“hrobeers, post:12, topic:3955”]So my question again, do we need a dedicated burn address per chain?
e.g. a dedicated burn address for transfers from ppc to btc.

Because the burn shouldn’t be accounted for in the checksum.[/quote]

Instead of having a separate dedicated burn address do you believe it would be possible to instead use a separate PeerAssets transaction type of which is sent to the Issuer?

14

I it seems to me that cross blockchain asset trading proposed here can be done by trading of tokens on B&C exchange , which exchange tokens between blockchains using automatic escrow signers.

15

Good thinking! I like that.

16

Good thinking! I like that.[/quote]

Ok, awesome!

Went ahead and made an example utilizing the various types of PeerAssets transactions.

17

Why do john and alice need to burn a unit of what they received?

18

Oh, they don’t. I just was using them as examples of burn transactions. Sorry if that wasn’t clear.