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 25057 times)

kushti

  • Sr. Member
  • ****
  • Karma: +184/-5
  • Offline Offline
  • Posts: 384
  • Nxt Core & Apps Dev
    • View Profile
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #60 on: April 01, 2015, 08:30:06 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.

I was under the impression P2SH was different to P2H?

No, all is about paying to hash. In bitcoin, P2SH is paying to script hash, but there're no scripts in Nxt.
Logged
for donations / messages: NXT-PKXM-WH25-UXXG-CJAVD (alias: kushti)

Daedelus

  • Hero Member
  • *****
  • Karma: +230/-12
  • Offline Offline
  • Posts: 3280
    • View Profile
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #61 on: April 01, 2015, 08:47:00 am »

Thanks, that cleared that up.
Logged
NXT: NXT-4CS7-S4N5-PTH5-A8R2Q

Jean-Luc

  • Core Dev
  • Hero Member
  • *****
  • Karma: +816/-81
  • Offline Offline
  • Posts: 1610
    • View Profile
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #62 on: April 01, 2015, 11:52:09 pm »

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.

After some more brainstorming, I believe we have a working solution that I will implement for 1.5. It will be possible to use phasing to make two transactions of any type atomic (they are either both executed, or both not executed), as long as at least one of them is phasing safe (asset transfers and AE orders are safe). And the good news is that this will not require any additional transactions, just the two that need to be coupled.
 
Logged
GPG key fingerprint: 263A 9EB0 29CF C77A 3D06  FD13 811D 6940 E1E4 240C
NXT-X4LF-9A4G-WN9Z-2R322

jl777

  • Hero Member
  • *****
  • Karma: +718/-123
  • Offline Offline
  • Posts: 6170
    • View Profile
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #63 on: April 01, 2015, 11:57:47 pm »

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.

After some more brainstorming, I believe we have a working solution that I will implement for 1.5. It will be possible to use phasing to make two transactions of any type atomic (they are either both executed, or both not executed), as long as at least one of them is phasing safe (asset transfers and AE orders are safe). And the good news is that this will not require any additional transactions, just the two that need to be coupled.
this is fantastic news!!
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

msin

  • Hero Member
  • *****
  • Karma: +138/-18
  • Offline Offline
  • Posts: 1288
    • View Profile
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #64 on: April 02, 2015, 01:51:02 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.

After some more brainstorming, I believe we have a working solution that I will implement for 1.5. It will be possible to use phasing to make two transactions of any type atomic (they are either both executed, or both not executed), as long as at least one of them is phasing safe (asset transfers and AE orders are safe). And the good news is that this will not require any additional transactions, just the two that need to be coupled.

Very cool, great work JL!
Logged

kushti

  • Sr. Member
  • ****
  • Karma: +184/-5
  • Offline Offline
  • Posts: 384
  • Nxt Core & Apps Dev
    • View Profile
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #65 on: April 02, 2015, 05:32:39 am »

Oh yeah, and I hope after that we'll be fully packed, so going to make a final spec.
Logged
for donations / messages: NXT-PKXM-WH25-UXXG-CJAVD (alias: kushti)

slothbag

  • Sr. Member
  • ****
  • Karma: +74/-4
  • Offline Offline
  • Posts: 454
    • View Profile
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #66 on: April 04, 2015, 04:54:08 am »

I'm so confused with all this 2-phased, p2h, p2sh and pay on secret reveal business.

I requested the pay on secret reveal tx which from what I understand is essentially p2h (or Pay to hash).

It has been said that it cant be implemented due to "evil forger" problem, which i'm not sure what that is.. it sounds like a forger can cancel their tx at the last minute or something, but surely if both parties wait a minimum number of confirmations like say 10, then the problem goes away?
Logged

Jean-Luc

  • Core Dev
  • Hero Member
  • *****
  • Karma: +816/-81
  • Offline Offline
  • Posts: 1610
    • View Profile
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #67 on: April 04, 2015, 08:31:00 am »

For cross-blockchain transactions, how is pay on secret reveal supposed to handle the situation when the secret reveal transaction does not get accepted on one of the blockchains and the timeout is reached? This can happen if the timeout is only a few blocks ahead and forgers collude not to accept that transaction, or an attacker floods the blockchain with bogus transactions with slightly higher fee, so that the honest forgers include those in preference to the secret reveal transaction.

For atomic execution two or more transactions on the same blockchain, I will try to implement pay on secret reveal in 1.5. The phased transactions being linked by secret reveal still need to be set to finish at the same height, to avoid the above attack (someone preventing the inclusion of the reveal transaction until only one of the phased ones expires).
Logged
GPG key fingerprint: 263A 9EB0 29CF C77A 3D06  FD13 811D 6940 E1E4 240C
NXT-X4LF-9A4G-WN9Z-2R322

slothbag

  • Sr. Member
  • ****
  • Karma: +74/-4
  • Offline Offline
  • Posts: 454
    • View Profile
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #68 on: April 04, 2015, 09:02:10 am »

Seems like this attack vector relies on the attacker to be able to completely control a consecutive number of blocks either mining each and every one or filling them completely with transactions.. if this is possible on any coin for a decent amount of time (say an hour or two) then i'd say thats a pretty massive flaw in the coin not just atomic trade txs.

I'd imagine anyone doing cross chain trades to demand at least a 24 hour window for the settlement to take place, perhaps 12 hours for the first "secret reveal" on one blockchain and then another 12 hours on the 2nd blockchain.  If someone can clog up a blockchain for 12 hours then that coin is useless.
Logged

Jean-Luc

  • Core Dev
  • Hero Member
  • *****
  • Karma: +816/-81
  • Offline Offline
  • Posts: 1610
    • View Profile
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #69 on: April 04, 2015, 07:44:43 pm »

The pay on secret reveal is in 1.5 now. A transaction can be made phased (i.e., executed at some later height, subject to approval), and a hash attached to it. If an approval transaction is received before that height, with an attachment containing a secret such that the sha256(secret) = hash, where the secret is up to 100 bytes string/binary, at finish height the phased transaction is executed, else it is reversed.

It doesn't matter who sends the approval transaction. Also a single approval transaction can approve up to 10 phased transactions, as long as the same secret is used. The approval transaction must specify the full hash(es) of the phased transaction(s) it approves.
Logged
GPG key fingerprint: 263A 9EB0 29CF C77A 3D06  FD13 811D 6940 E1E4 240C
NXT-X4LF-9A4G-WN9Z-2R322

verymuchso

  • Hero Member
  • *****
  • Karma: +118/-2
  • Offline Offline
  • Posts: 549
    • View Profile
    • HEAT Ledger
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #70 on: April 04, 2015, 07:56:07 pm »

The pay on secret reveal is in 1.5 now. A transaction can be made phased (i.e., executed at some later height, subject to approval), and a hash attached to it. If an approval transaction is received before that height, with an attachment containing a secret such that the sha256(secret) = hash, where the secret is up to 100 bytes string/binary, at finish height the phased transaction is executed, else it is reversed.

It doesn't matter who sends the approval transaction. Also a single approval transaction can approve up to 10 phased transactions, as long as the same secret is used. The approval transaction must specify the full hash(es) of the phased transaction(s) it approves.

Why was 100 bytes selected and not 1000 bytes? Would 1000 bytes not be handy when somewhat longer JSON data is hashed?
Logged
HEAT: DEX | SDK | HOME

Jean-Luc

  • Core Dev
  • Hero Member
  • *****
  • Karma: +816/-81
  • Offline Offline
  • Posts: 1610
    • View Profile
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #71 on: April 04, 2015, 08:03:00 pm »

Why would you want to use JSON data as the secret? My understanding is that the secret is a random sequence of bytes, known only to the sender, so that it cannot be guessed or brute forced.
Logged
GPG key fingerprint: 263A 9EB0 29CF C77A 3D06  FD13 811D 6940 E1E4 240C
NXT-X4LF-9A4G-WN9Z-2R322

verymuchso

  • Hero Member
  • *****
  • Karma: +118/-2
  • Offline Offline
  • Posts: 549
    • View Profile
    • HEAT Ledger
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #72 on: April 04, 2015, 08:14:42 pm »

Why would you want to use JSON data as the secret? My understanding is that the secret is a random sequence of bytes, known only to the sender, so that it cannot be guessed or brute forced.

Oke if you say so, I havent dived in as deep into this as you did of course.

It just sounds kindof limiting when everything else (alias, msg etc..) allows for bigger blobs yet the secret can only be 100 bytes.
Is this set to 100 to save blockchain real-estate or maybe to save processing time of SHA routine having to go over all secrets on the chain?
If that is the case then why not pick 64 bytes as as an upper limit, would probably suffice also in most cases.

Just saying if it doesn't really cost anything why not give some more room?
Logged
HEAT: DEX | SDK | HOME

jl777

  • Hero Member
  • *****
  • Karma: +718/-123
  • Offline Offline
  • Posts: 6170
    • View Profile
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #73 on: April 04, 2015, 08:17:22 pm »

Why would you want to use JSON data as the secret? My understanding is that the secret is a random sequence of bytes, known only to the sender, so that it cannot be guessed or brute forced.
I think this allows crosschain swaps using the same secret for both halves. So that spending one half reveals the secret that allows the other side to spend their half

and yes, typically the secret will be some sort of hashed high entropy value, as long as it is 100 bytes -> 800 bits of data, I think that is plenty
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

Daedelus

  • Hero Member
  • *****
  • Karma: +230/-12
  • Offline Offline
  • Posts: 3280
    • View Profile
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #74 on: April 05, 2015, 06:46:37 pm »

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.

After some more brainstorming, I believe we have a working solution that I will implement for 1.5. It will be possible to use phasing to make two transactions of any type atomic (they are either both executed, or both not executed), as long as at least one of them is phasing safe (asset transfers and AE orders are safe). And the good news is that this will not require any additional transactions, just the two that need to be coupled.

Question:

Jean-Luc and friends have found a way to make 2 phased transactions atomic (both executed or both not executed).

Any plans to adapt that technique towards atomic Asset-to-Asset transactions?
Logged
NXT: NXT-4CS7-S4N5-PTH5-A8R2Q

jl777

  • Hero Member
  • *****
  • Karma: +718/-123
  • Offline Offline
  • Posts: 6170
    • View Profile
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #75 on: April 05, 2015, 07:16:26 pm »

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.

After some more brainstorming, I believe we have a working solution that I will implement for 1.5. It will be possible to use phasing to make two transactions of any type atomic (they are either both executed, or both not executed), as long as at least one of them is phasing safe (asset transfers and AE orders are safe). And the good news is that this will not require any additional transactions, just the two that need to be coupled.

Question:

Jean-Luc and friends have found a way to make 2 phased transactions atomic (both executed or both not executed).

Any plans to adapt that technique towards atomic Asset-to-Asset transactions?
I will use this for InstantDEX
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

Jean-Luc

  • Core Dev
  • Hero Member
  • *****
  • Karma: +816/-81
  • Offline Offline
  • Posts: 1610
    • View Profile
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #76 on: April 05, 2015, 08:09:08 pm »

There will be two ways to make two transactions execute atomically in 1.5: phasing with by-transaction voting, and phasing with by-hash voting.

By-transaction is analogous to using referenced transactions, except the attacks possible due to the fact that the referencing transaction is still in the unconfirmed pool when the other one (referenced) is broadcast are avoided, because the phased transaction is already in the blockchain (and if desired, one could wait for 720 confirmations on it) when the other one (linked) transaction is broadcast. As I said, two transactions of any type can be coupled this way, for example two asset transfers. Also a phased transaction can link to up to 10 transaction and be set to require at least n of them to be present in order to get executed.

By-hash is pay-on-reveal-secret, and takes three transactions in total. The two transactions that need to be executed atomically are created as phased, both depending on the same hash, and will be executed only when a third transaction is received that contains a secret which matches that hash. This can be extended to up to 10 transactions being released with the same secret.

Pay on reveal secret can also be used to create cross-blockchain atomic transactions with other blockchains that support the same method, as long as the same hash function (sha256 in our case) is used. If needed, we will extend this to support other hash functions.
« Last Edit: April 05, 2015, 08:11:28 pm by Jean-Luc »
Logged
GPG key fingerprint: 263A 9EB0 29CF C77A 3D06  FD13 811D 6940 E1E4 240C
NXT-X4LF-9A4G-WN9Z-2R322

jl777

  • Hero Member
  • *****
  • Karma: +718/-123
  • Offline Offline
  • Posts: 6170
    • View Profile
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #77 on: April 05, 2015, 08:12:54 pm »

There will be two ways to make two transactions execute atomically in 1.5: phasing with by-transaction voting, and phasing with by-hash voting.

By-transaction is analogous to using referenced transactions, except the attacks possible due to the fact that the referencing transaction is still in the unconfirmed pool when the other one (referenced) is broadcast are avoided, because the phased transaction is already in the blockchain (and if desired, one could wait for 720 confirmations on it) when the other one (linked) transaction is broadcast. As I said, two transactions of any type can be coupled this way, for example two asset transfers. Also a phased transaction can link to up to 10 transaction and be set to require at least n of them to be present in order to get executed.

By-hash is pay-on-reveal-secret, and takes three transactions in total. The two transactions that need to be executed atomically are created as phased, both depending on the same hash, and will be executed only when a third transaction is received that contains a secret which matches that hash. This can be extended to up to 10 transactions being released with the same secret.

Pay on reveal secret can also be used to create cross-blockchain atomic transactions with other blockchains that support the same method, as long as the same hash function (sha256 in our case) is used. If needed, we will extend this to support other hash functions.
RMD160

plz make sure it can be made compatible with bitcoin
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

Jean-Luc

  • Core Dev
  • Hero Member
  • *****
  • Karma: +816/-81
  • Offline Offline
  • Posts: 1610
    • View Profile
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #78 on: April 05, 2015, 09:09:06 pm »

Would it make sense to support the same set of hash functions that we support for currency minting: sha256, sha3, scrypt, keccak25, and also add ripemd160 to it? Is there a reason why any of the others would not be suitable for reveal on secret hash, or would ripemd160 be not suitable for minting? So that I don't need to define two separate lists of supported hash functions for different purposes.
Logged
GPG key fingerprint: 263A 9EB0 29CF C77A 3D06  FD13 811D 6940 E1E4 240C
NXT-X4LF-9A4G-WN9Z-2R322

jl777

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

Would it make sense to support the same set of hash functions that we support for currency minting: sha256, sha3, scrypt, keccak25, and also add ripemd160 to it? Is there a reason why any of the others would not be suitable for reveal on secret hash, or would ripemd160 be not suitable for minting? So that I don't need to define two separate lists of supported hash functions for different purposes.
I dont know about the minting, but I would think that the same list of hash functions makes sense
can double sha256 be supported too? I think bitcoin uses that too

or was it RMD160(SHA256(x))

anyway, what is important is to support the same hash results that bitcoin uses (as a minimum)

https://bhelx.simst.im/articles/generating-bitcoin-keys-from-scratch-with-ruby/ has some details, but I am sure there are other sources
« Last Edit: April 05, 2015, 09:33:54 pm by jl777 »
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
Pages: 1 2 3 [4] 5  All
 

elective-stereophonic
elective-stereophonic
assembly
assembly