elective-stereophonic
elective-stereophonic
2-Phased Transactions Post-Implementation Specification singapore
Please login or register.

Login with username, password and session length
Advanced search  

News:

Latest Stable Nxt Client: Nxt 1.12.2

Pages: 1 2 [3] 4 5  All

Author Topic: 2-Phased Transactions Post-Implementation Specification  (Read 24414 times)

Daedelus

  • Hero Member
  • *****
  • Karma: +230/-12
  • Offline Offline
  • Posts: 3280
    • View Profile
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #40 on: March 19, 2015, 01:43:00 pm »

Just for curiosity, it is 364 days since the first mention (that I recall) of 'Phaser'  ;)

https://bitcointalk.org/index.php?topic=345619.msg5805491#msg5805491


Come-from-Beyond replied:

Quote
This feature will make obsolete cold storage, escrow and few other things. This is a big step to true decentralization.
https://bitcointalk.org/index.php?topic=345619.msg5805999#msg5805999


Almost there now (measured in weeks months, not days)  ;D
Logged
NXT: NXT-4CS7-S4N5-PTH5-A8R2Q

Fatih87SK

  • Hero Member
  • *****
  • Karma: +127/-36
  • Offline Offline
  • Posts: 2206
    • View Profile
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #41 on: March 19, 2015, 02:35:33 pm »

Just for curiosity, it is 364 days since the first mention (that I recall) of 'Phaser'  ;)

https://bitcointalk.org/index.php?topic=345619.msg5805491#msg5805491


Come-from-Beyond replied:

Quote
This feature will make obsolete cold storage, escrow and few other things. This is a big step to true decentralization.
https://bitcointalk.org/index.php?topic=345619.msg5805999#msg5805999


Almost there now (measured in weeks months, not days)  ;D

I was looking for that picture as well yesterday. Couldn't find it.  :D
Logged

bob_ggg

  • Jr. Member
  • **
  • Karma: +9/-0
  • Offline Offline
  • Posts: 90
    • View Profile
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #42 on: March 19, 2015, 04:53:39 pm »

Here is the presentation of a business case. Please forgive the cross-post.
In the insurance business, contracts between the insured (A) and the insurer (B) could be mapped on the Phased transaction system if a few extensions are considered.
In its essential form, a fully collateralized insurance contract could follow these steps:

A and B select an oracle O who will decide the outcome of the contract (for sake of simplicity I do not consider the multi-oracle case)

a multisig transaction is created with funds from B covering the amount that could be potentially paid to A; signatures to the contract enabling the disbursement are from A, B and O

if A does not show proof of payment to B within a given time, O closes the transaction returning funds to B

if A pays the premium, the transaction starts and is closed at a predefined time

before closing the transaction, A and/or B could decide to sell their position in this transaction; clearly, the value of the position of A and B are different so it is necessary to keep into account that a transaction that cashes out A is different from one that cashes out B

at the expiration of the insurance contract, O decides the outcome: it is very common to have a situation where part of the funds are disbursed to A and the remaining is returned to B; O is in charge of deciding how to split the deposit.

If this scenario could be mapped on the proposed Phased transaction framework, most of the financial contracts in use today could be built around this skeleton.
Logged

Daedelus

  • Hero Member
  • *****
  • Karma: +230/-12
  • Offline Offline
  • Posts: 3280
    • View Profile
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #43 on: March 25, 2015, 01:03:49 pm »

If P2SH is due out at a later date than two-phased transaction, will Nxt still support support m-of-n via P2SH?
Logged
NXT: NXT-4CS7-S4N5-PTH5-A8R2Q

kushti

  • Sr. Member
  • ****
  • Karma: +184/-5
  • Offline Offline
  • Posts: 384
  • Nxt Core & Apps Dev
    • View Profile
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #44 on: March 28, 2015, 04:16:42 am »

If P2SH is due out at a later date than two-phased transaction, will Nxt still support support m-of-n via P2SH?

Sure, m-of-n will be easily possible with 1.5.0, P2H isn't needed for that.

Logged
for donations / messages: NXT-PKXM-WH25-UXXG-CJAVD (alias: kushti)

_mr_e

  • Hero Member
  • *****
  • Karma: +88/-18
  • Offline Offline
  • Posts: 956
    • View Profile
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #45 on: March 28, 2015, 04:36:56 am »

If P2SH is due out at a later date than two-phased transaction, will Nxt still support support m-of-n via P2SH?

Sure, m-of-n will be easily possible with 1.5.0, P2H isn't needed for that.
Except you have to wait two blocks and pay extra fees.
Logged

Riker

  • Core Dev
  • Hero Member
  • *****
  • Karma: +440/-42
  • Offline Offline
  • Posts: 1796
    • View Profile
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #46 on: March 28, 2015, 03:25:53 pm »

Here is the presentation of a business case. Please forgive the cross-post.
In the insurance business, contracts between the insured (A) and the insurer (B) could be mapped on the Phased transaction system if a few extensions are considered.
In its essential form, a fully collateralized insurance contract could follow these steps:

A and B select an oracle O who will decide the outcome of the contract (for sake of simplicity I do not consider the multi-oracle case)

a multisig transaction is created with funds from B covering the amount that could be potentially paid to A; signatures to the contract enabling the disbursement are from A, B and O

if A does not show proof of payment to B within a given time, O closes the transaction returning funds to B

if A pays the premium, the transaction starts and is closed at a predefined time

before closing the transaction, A and/or B could decide to sell their position in this transaction; clearly, the value of the position of A and B are different so it is necessary to keep into account that a transaction that cashes out A is different from one that cashes out B

at the expiration of the insurance contract, O decides the outcome: it is very common to have a situation where part of the funds are disbursed to A and the remaining is returned to B; O is in charge of deciding how to split the deposit.

If this scenario could be mapped on the proposed Phased transaction framework, most of the financial contracts in use today could be built around this skeleton.

Phased transactions has the following limitations:
1. There is only a single phase, checked when reaching the phasing height, at this phase the transaction is either applied or cancelled.
2. The phasing transaction cannot be cancelled before the phasing height.
3. At the phasing height, the transaction can only be applied as is. It cannot change its properties based on some "Oracle" decision.

Its possible that the building blocks provided by phasing can provide partial solution for this scenario and that together with some actions performed by a trusted Oracle itself can cover this use case but this requires some more specification.
Logged
NXT Core Dev
Account: NXT-HBFW-X8TE-WXPW-DZFAG
Public Key: D8311651 Key fingerprint: 0560 443B 035C EE08 0EC0  D2DD 275E 94A7 D831 1651

jl777

  • Hero Member
  • *****
  • Karma: +718/-123
  • Offline Offline
  • Posts: 6170
    • View Profile
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #47 on: March 28, 2015, 03:35:23 pm »

If I want to make an atomic AssetA <-> AssetB swap can you confirm how to use Phasing for this?

I am assuming I can setup a trigger transaction that both asset transfers are triggered from:

trigger <- transferAssetA
trigger <- transferAssetB

Now A and B both signoff on the above 2 (or 3?) transactions and the effective blockheight can be set to currentblock+1

So all these things (other than the trigger) can be submitted to the blockchain and be in the unconfirmed transactions BEFORE the trigger itself is released. Ideally, all this happens in the same block.

Then the trigger is released, confirmed, the two transfers become valid and confirmed.

I am a bit unclear on the exact way to setup something like this, any guidance is appreciated

James
Logged
There are over 1000 people in SuperNET slack! http://slackinvite.supernet.org/ automatically sends you an invite

I am just a simple C programmer

Riker

  • Core Dev
  • Hero Member
  • *****
  • Karma: +440/-42
  • Offline Offline
  • Posts: 1796
    • View Profile
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #48 on: March 28, 2015, 05:11:42 pm »

If I want to make an atomic AssetA <-> AssetB swap can you confirm how to use Phasing for this?

I am assuming I can setup a trigger transaction that both asset transfers are triggered from:

trigger <- transferAssetA
trigger <- transferAssetB

Now A and B both signoff on the above 2 (or 3?) transactions and the effective blockheight can be set to currentblock+1

So all these things (other than the trigger) can be submitted to the blockchain and be in the unconfirmed transactions BEFORE the trigger itself is released. Ideally, all this happens in the same block.

Then the trigger is released, confirmed, the two transfers become valid and confirmed.

I am a bit unclear on the exact way to setup something like this, any guidance is appreciated

James

You submit the two transfer transactions as phased transactions and set the phasing height for some block in the future. You add that two votes are necessary to accept each transaction and that accounts A and B are the only ones who can vote (i.e. both compose the "whitelist"). At this point the unconfirmed asset quantities are reduced to prevent double spend.
A and B both approve transferAssetA and transferAssetB (you can approve more than one transaction in a single vote so this requires two transactions in total)
Now when the phasing height is reached, both transfers are performed, assuming the transactions are still valid and there is no reason they shouldn't be, the transfers are both included in the next block.
In total you perform 4 transactions, 2 transfers and 2 approvals.
Logged
NXT Core Dev
Account: NXT-HBFW-X8TE-WXPW-DZFAG
Public Key: D8311651 Key fingerprint: 0560 443B 035C EE08 0EC0  D2DD 275E 94A7 D831 1651

jl777

  • Hero Member
  • *****
  • Karma: +718/-123
  • Offline Offline
  • Posts: 6170
    • View Profile
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #49 on: March 28, 2015, 05:14:01 pm »

If I want to make an atomic AssetA <-> AssetB swap can you confirm how to use Phasing for this?

I am assuming I can setup a trigger transaction that both asset transfers are triggered from:

trigger <- transferAssetA
trigger <- transferAssetB

Now A and B both signoff on the above 2 (or 3?) transactions and the effective blockheight can be set to currentblock+1

So all these things (other than the trigger) can be submitted to the blockchain and be in the unconfirmed transactions BEFORE the trigger itself is released. Ideally, all this happens in the same block.

Then the trigger is released, confirmed, the two transfers become valid and confirmed.

I am a bit unclear on the exact way to setup something like this, any guidance is appreciated

James

You submit the two transfer transactions as phased transactions and set the phasing height for some block in the future. You add that two votes are necessary to accept each transaction and that accounts A and B are the only ones who can vote (i.e. both compose the "whitelist"). At this point the unconfirmed asset quantities are reduced to prevent double spend.
A and B both approve transferAssetA and transferAssetB (you can approve more than one transaction in a single vote so this requires two transactions in total)
Now when the phasing height is reached, both transfers are performed, assuming the transactions are still valid and there is no reason they shouldn't be, the transfers are both included in the next block.
In total you perform 4 transactions, 2 transfers and 2 approvals.
Fantastic! this will make things much more efficient

Thanks

James
Logged
There are over 1000 people in SuperNET slack! http://slackinvite.supernet.org/ automatically sends you an invite

I am just a simple C programmer

bob_ggg

  • Jr. Member
  • **
  • Karma: +9/-0
  • Offline Offline
  • Posts: 90
    • View Profile
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #50 on: March 30, 2015, 02:15:35 pm »


Phased transactions has the following limitations:
1. There is only a single phase, checked when reaching the phasing height, at this phase the transaction is either applied or cancelled.
2. The phasing transaction cannot be cancelled before the phasing height.
3. At the phasing height, the transaction can only be applied as is. It cannot change its properties based on some "Oracle" decision.

Its possible that the building blocks provided by phasing can provide partial solution for this scenario and that together with some actions performed by a trusted Oracle itself can cover this use case but this requires some more specification.
I understand from your description some current limitations of Phased Transactions. I think that this sequence of steps should be relatively simple to implement using the existing building blocks.

Since being on the receiving side of a phased transaction has financial value and is very much alike to an asset that can be sold, I would like to obtain the following sequence of "chained" transactions:
  • before the expiration of the insurance contract, A creates another transaction that has a
    beneficiary, C, and an "undefined" input value
  • the input of this transaction has the same value of the output of the insurance contract, whatever it is.
Ideally, this transaction is submitted to the blockchain allowing this process to be repeated as many times as required.
Any suggestion is appreciated.
Logged

bob_ggg

  • Jr. Member
  • **
  • Karma: +9/-0
  • Offline Offline
  • Posts: 90
    • View Profile
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #51 on: March 30, 2015, 02:22:50 pm »



Phased transactions has the following limitations:
1. There is only a single phase, checked when reaching the phasing height, at this phase the transaction is either applied or cancelled.
2. The phasing transaction cannot be cancelled before the phasing height.
3. At the phasing height, the transaction can only be applied as is. It cannot change its properties based on some "Oracle" decision.

Its possible that the building blocks provided by phasing can provide partial solution for this scenario and that together with some actions performed by a trusted Oracle itself can cover this use case but this requires some more specification.
I might be wrong but if the trusted Oracle has the power to sign the transaction transferring to A its entire balance, it could also decide to transfer to A any balance that is below the one set aside in the transaction itself without creating additional trust problems. Clearly, the role of the Oracle is different from that of other parties, but this extension would make it possible to create many interesting financial contracts.
Logged

coretechs

  • Sr. Member
  • ****
  • Karma: +161/-1
  • Offline Offline
  • Posts: 436
    • View Profile
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #52 on: March 30, 2015, 03:56:03 pm »

Will it be possible to trade aliases in sets?

For example, if A wanted to trade 5 aliases for a single alias owned by B, would A be able to phase 5 alias transfer transactions as a set to match B's individual alias transfer transaction?
Logged
https://ardorportal.org - Ardor blockchain explorer | https://nxtportal.org - Nxt blockchain explorer | http://bitcoindoc.com - The Rise and Rise of Bitcoin
ARDOR-T43P-R2K9-8W79-9W2AL | NXT-WY9K-ZMTT-QQTT-3NBL7

Jean-Luc

  • Core Dev
  • Hero Member
  • *****
  • Karma: +816/-81
  • Offline Offline
  • Posts: 1610
    • View Profile
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #53 on: March 30, 2015, 04:27:54 pm »

Unfortunately alias trading is exactly one of the examples where phased transactions are not guaranteed to be executed. Don't do it, you will get cheated.
Logged
GPG key fingerprint: 263A 9EB0 29CF C77A 3D06  FD13 811D 6940 E1E4 240C
NXT-X4LF-9A4G-WN9Z-2R322

Daedelus

  • Hero Member
  • *****
  • Karma: +230/-12
  • Offline Offline
  • Posts: 3280
    • View Profile
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #54 on: March 30, 2015, 08:29:28 pm »

If P2SH is due out at a later date than two-phased transaction, will Nxt still support support m-of-n via P2SH?

Sure, m-of-n will be easily possible with 1.5.0, P2H isn't needed for that.

I was under the impression P2SH was different to P2H?
Logged
NXT: NXT-4CS7-S4N5-PTH5-A8R2Q

Riker

  • Core Dev
  • Hero Member
  • *****
  • Karma: +440/-42
  • Offline Offline
  • Posts: 1796
    • View Profile
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #55 on: March 30, 2015, 08:38:47 pm »

If I want to make an atomic AssetA <-> AssetB swap can you confirm how to use Phasing for this?

I am assuming I can setup a trigger transaction that both asset transfers are triggered from:

trigger <- transferAssetA
trigger <- transferAssetB

Now A and B both signoff on the above 2 (or 3?) transactions and the effective blockheight can be set to currentblock+1

So all these things (other than the trigger) can be submitted to the blockchain and be in the unconfirmed transactions BEFORE the trigger itself is released. Ideally, all this happens in the same block.

Then the trigger is released, confirmed, the two transfers become valid and confirmed.

I am a bit unclear on the exact way to setup something like this, any guidance is appreciated

James

You submit the two transfer transactions as phased transactions and set the phasing height for some block in the future. You add that two votes are necessary to accept each transaction and that accounts A and B are the only ones who can vote (i.e. both compose the "whitelist"). At this point the unconfirmed asset quantities are reduced to prevent double spend.
A and B both approve transferAssetA and transferAssetB (you can approve more than one transaction in a single vote so this requires two transactions in total)
Now when the phasing height is reached, both transfers are performed, assuming the transactions are still valid and there is no reason they shouldn't be, the transfers are both included in the next block.
In total you perform 4 transactions, 2 transfers and 2 approvals.
Fantastic! this will make things much more efficient

Thanks

James

The scenario I described is naive since it requires cooperation from A and B. It appears that there are several possible attacks on this transaction sequence.
We are looking into ways to improve this.
Logged
NXT Core Dev
Account: NXT-HBFW-X8TE-WXPW-DZFAG
Public Key: D8311651 Key fingerprint: 0560 443B 035C EE08 0EC0  D2DD 275E 94A7 D831 1651

jl777

  • Hero Member
  • *****
  • Karma: +718/-123
  • Offline Offline
  • Posts: 6170
    • View Profile
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #56 on: March 30, 2015, 08:45:49 pm »

If I want to make an atomic AssetA <-> AssetB swap can you confirm how to use Phasing for this?

I am assuming I can setup a trigger transaction that both asset transfers are triggered from:

trigger <- transferAssetA
trigger <- transferAssetB

Now A and B both signoff on the above 2 (or 3?) transactions and the effective blockheight can be set to currentblock+1

So all these things (other than the trigger) can be submitted to the blockchain and be in the unconfirmed transactions BEFORE the trigger itself is released. Ideally, all this happens in the same block.

Then the trigger is released, confirmed, the two transfers become valid and confirmed.

I am a bit unclear on the exact way to setup something like this, any guidance is appreciated

James

You submit the two transfer transactions as phased transactions and set the phasing height for some block in the future. You add that two votes are necessary to accept each transaction and that accounts A and B are the only ones who can vote (i.e. both compose the "whitelist"). At this point the unconfirmed asset quantities are reduced to prevent double spend.
A and B both approve transferAssetA and transferAssetB (you can approve more than one transaction in a single vote so this requires two transactions in total)
Now when the phasing height is reached, both transfers are performed, assuming the transactions are still valid and there is no reason they shouldn't be, the transfers are both included in the next block.
In total you perform 4 transactions, 2 transfers and 2 approvals.
Fantastic! this will make things much more efficient

Thanks

James

The scenario I described is naive since it requires cooperation from A and B. It appears that there are several possible attacks on this transaction sequence.
We are looking into ways to improve this.
I am glad we are finding such things now. but the way things are setup A and B are cooperating offchain and making sure each side's tx is acceptable before signing off.
Logged
There are over 1000 people in SuperNET slack! http://slackinvite.supernet.org/ automatically sends you an invite

I am just a simple C programmer

Riker

  • Core Dev
  • Hero Member
  • *****
  • Karma: +440/-42
  • Offline Offline
  • Posts: 1796
    • View Profile
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #57 on: March 30, 2015, 08:49:50 pm »

If I want to make an atomic AssetA <-> AssetB swap can you confirm how to use Phasing for this?

I am assuming I can setup a trigger transaction that both asset transfers are triggered from:

trigger <- transferAssetA
trigger <- transferAssetB

Now A and B both signoff on the above 2 (or 3?) transactions and the effective blockheight can be set to currentblock+1

So all these things (other than the trigger) can be submitted to the blockchain and be in the unconfirmed transactions BEFORE the trigger itself is released. Ideally, all this happens in the same block.

Then the trigger is released, confirmed, the two transfers become valid and confirmed.

I am a bit unclear on the exact way to setup something like this, any guidance is appreciated

James

You submit the two transfer transactions as phased transactions and set the phasing height for some block in the future. You add that two votes are necessary to accept each transaction and that accounts A and B are the only ones who can vote (i.e. both compose the "whitelist"). At this point the unconfirmed asset quantities are reduced to prevent double spend.
A and B both approve transferAssetA and transferAssetB (you can approve more than one transaction in a single vote so this requires two transactions in total)
Now when the phasing height is reached, both transfers are performed, assuming the transactions are still valid and there is no reason they shouldn't be, the transfers are both included in the next block.
In total you perform 4 transactions, 2 transfers and 2 approvals.
Fantastic! this will make things much more efficient

Thanks

James

The scenario I described is naive since it requires cooperation from A and B. It appears that there are several possible attacks on this transaction sequence.
We are looking into ways to improve this.
I am glad we are finding such things now. but the way things are setup A and B are cooperating offchain and making sure each side's tx is acceptable before signing off.

True, but they can try to front run their honest transactions after they were submitted with contradicting transactions or even decline to accept these transactions as forgers.
Logged
NXT Core Dev
Account: NXT-HBFW-X8TE-WXPW-DZFAG
Public Key: D8311651 Key fingerprint: 0560 443B 035C EE08 0EC0  D2DD 275E 94A7 D831 1651

jl777

  • Hero Member
  • *****
  • Karma: +718/-123
  • Offline Offline
  • Posts: 6170
    • View Profile
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #58 on: March 30, 2015, 09:20:51 pm »

If I want to make an atomic AssetA <-> AssetB swap can you confirm how to use Phasing for this?

I am assuming I can setup a trigger transaction that both asset transfers are triggered from:

trigger <- transferAssetA
trigger <- transferAssetB

Now A and B both signoff on the above 2 (or 3?) transactions and the effective blockheight can be set to currentblock+1

So all these things (other than the trigger) can be submitted to the blockchain and be in the unconfirmed transactions BEFORE the trigger itself is released. Ideally, all this happens in the same block.

Then the trigger is released, confirmed, the two transfers become valid and confirmed.

I am a bit unclear on the exact way to setup something like this, any guidance is appreciated

James

You submit the two transfer transactions as phased transactions and set the phasing height for some block in the future. You add that two votes are necessary to accept each transaction and that accounts A and B are the only ones who can vote (i.e. both compose the "whitelist"). At this point the unconfirmed asset quantities are reduced to prevent double spend.
A and B both approve transferAssetA and transferAssetB (you can approve more than one transaction in a single vote so this requires two transactions in total)
Now when the phasing height is reached, both transfers are performed, assuming the transactions are still valid and there is no reason they shouldn't be, the transfers are both included in the next block.
In total you perform 4 transactions, 2 transfers and 2 approvals.
Fantastic! this will make things much more efficient

Thanks

James

The scenario I described is naive since it requires cooperation from A and B. It appears that there are several possible attacks on this transaction sequence.
We are looking into ways to improve this.
I am glad we are finding such things now. but the way things are setup A and B are cooperating offchain and making sure each side's tx is acceptable before signing off.

True, but they can try to front run their honest transactions after they were submitted with contradicting transactions or even decline to accept these transactions as forgers.
how can an transferAsset from A -> B be front runned?

the evil forger can do all sorts of bad things, but as long as the network wont accept any partially filled bundle of transactions, then I can live with waiting for the first block generator that will include it into a block.

I realized that the network cant reject a perfectly valid block based on inaction by a block generator (who ignores a tx with its referenced tx already in the blockchain) as this would assume perfect consensus in the rampool

But as long as there is a deterministic decision possible using data in the blockchain, this should be possible to make it an all or nothing for a set of transactions. The proviso is to make sure the expiration times are matched, so the current deadline being relative to the transaction timestamp and not tied to a block makes for another edge case where we only get part of the trades filled if the block comes right in between the group of transactions.

eg. txA deadline 10 timestamp X and txB deadline 10 timestamp Y
txA expires X+600 and txB expires Y+600, in seconds! since we have the +/- 15 seconds for the nodes, this alone creates all sorts of edge cases, so I need to use the TF mechanism to estimate the next two blocks and how long it will be and set the deadline to be beyond the second block.

which works fine, unless one of the expected large accts doesnt generate the block. If I can just say these transactions expire at a specific block, it avoids all these edge cases and even setting it to be 4 blocks ahead will be less time on average than using a reasonable worst case estimate for the time to make the next two blocks.

What I am doing is creating a list of transactions that are needed for a trade to happen. The trade can be assetA <-> assetB, but this is structured now so that assetA -> intermediate -> assetB, and assetB -> intermediate2 -> assetA. If assetA or assetB is NXT itself, it is dramatically simpler, but if it isnt and intermediate != intermediate2 (in amount or what it is), then a balancing payment(s) need to be made, so it becomes quite a big bundle and all of them must be done or somebody will be unhappy.

Practically speaking I dont think we will need more than three parties involved in a trade and if a pair of transferAsset can be made atomic, it makes things much, much, much, much, much easier.

James

Logged
There are over 1000 people in SuperNET slack! http://slackinvite.supernet.org/ automatically sends you an invite

I am just a simple C programmer

Riker

  • Core Dev
  • Hero Member
  • *****
  • Karma: +440/-42
  • Offline Offline
  • Posts: 1796
    • View Profile
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #59 on: March 31, 2015, 07:09:29 am »

In a nutshell, one of the problems is that the last approval transaction which should approve both transfer A and B can be front run by the submitter with another transaction to approve just A, then the original transaction would be removed as duplicate. We had a long discussion about ways this can be mitigated. Currently the direction is to rely on account control to prevent this. This means that this specific scenario won't be supported before 1.6.
In 1.5 you'll be able to approve multiple phased transactions with the same approval transaction but the last approver can front run its own approval transaction with a different approval.
Logged
NXT Core Dev
Account: NXT-HBFW-X8TE-WXPW-DZFAG
Public Key: D8311651 Key fingerprint: 0560 443B 035C EE08 0EC0  D2DD 275E 94A7 D831 1651
Pages: 1 2 [3] 4 5  All
 

elective-stereophonic
elective-stereophonic
assembly
assembly