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

kushti · November 11, 2014, 02:35:02 pm

Two-Phased Transactions

Two-Phased Transactions is multisig transactions implementation in Nxt but much more powerful.

Simplest example, Alice starts a Two-Phased transaction. In the first stage a transaction is included in a blockchain but it isn’t processed immediately and has the status of ‘pending’. For it to be processed, Bob has to complete the second phase of the transaction by approving it. This has to be done before the deadline set by Alice has elapsed.

Use cases

* Bob approving a transaction of Alice

* Shareholders voting whether to send another 1M Nxt to a marketing service or not

* Nxt whales voting on whether to pay bounty or not

* Multisig wallet protected from a hacker(think about BTER case etc)

Features

* any kind of transaction could be 2-phased

* M-of-N consensus or by-balance consensus or shareholders voting to release transaction

* possible vote threshold setting(e.g. only accounts with 1M+ Nxt or 100+ assets balance could vote)

* whitelist of voters

* blacklist of voters

* transaction could be released only prior to maxHeight

Options

* MaxHeight - transaction has to be released before the mandatory height provided or it will be cancelled

* whitelist - list of accounts able to vote on transaction releasing. Max 10 accounts. If no given, any account has a right to vote! Mandatory for by-account voting

* blacklist - list of accounts voting is prohibited for. Only for by-balance & by-asset voting. Couldn't be combined with whitelist(so pending transaction submitter has to choose whether to use whitelist or blacklist).

* Voting option: by account, by balance, by asset.

* Consensus quorum - transaction released when gathered

* Vote threshold - min balance to vote. Only for by-balance & by-asset voting.

Example: accounts A(balance = 1000 nxt),B(700 nxt),C(400 nxt),D(200 nxt) are able to vote. Vote threshold is 300 nxt, so D can't vote. Consensus quorum is 1500 nxt, so transaction will be released only if A & B vote on this. The example doesn't take money transfers & heights into account.

Voting, Multivoting, Counting

It's possible to vote for multiple (max 10) pending transactions withing one voting transaction. It gives
possibility for trustless escrows etc.

In case of by-account(M-out-of-N) voting a pending transaction will be released on block Mth vote being including into a blockchain.

In case of by-balance or by-asset voting following algorithm is applied:

* votes weights are stored into database

* on getting a vote if vote weight + cached weights >= quorum weights rechecking with database update is taking place. if sum(updated weights) >=
quorum transaction is going to be released

* on maxHeight block there's is a final recheck

* this algo means in some cases of balances moving pending transaction could be released on maxHeight only

Trustless escrows

With 2-phased transactions some kinds of trustless escrows are possible. E.g.

Quote

Tx 1. Alice publishes into blockchain a pending transaction to Bob which will be released only when both Alice and Bob vote for it
Tx 2. Bob publishes into blockchain a pending transaction to Alice which will be released only when both Alice and Bob vote for it
Tx 3. Alice generates transaction bytes for a multivote transaction with votes for both transactions 1 & 2 & sends unsigned transaction bytes, the full transaction hash, and the signature hash to Bob
Tx 4. Bob sends to the unconfirmed transactions pool a transaction with votes for both transactions 1 & 2 & reference to hash of transaction #3

See https://nxtforum.org/general/trustless-escrows-are-coming!/ for details

Implementation

To implement 2-phased transactions, 1 new Appendix type & 2 new Transaction types are needed.

* TwoPhased appendix to each type of transaction will mark 2-phased transactions from ordinary ones. Appendix parameters will specify max height to gather consensus to release transaction & poll options(by-account / by-balance / by asset voting), consensus quorum,
list of accounts able to vote, max 10)

* PENDING_PAYMENT_VOTE_CASTING transaction type to for transaction(s) to release (if an account doesn't want this, it should skip voting at all). Max 10 votes possible, so voter can vote up to 10 pending transactions at once. Transaction will be released when quorum(specified by threshold) will be gathered. It will be cancelled if no consensus being gathered @ height maxHeight provided in pending transaction params.

Java API

Let's consider sort of classic example: Alice pays 50 Nxts to Chris, but only after Bob's approval and within 30 blocks after pending transaction issuance. Please note TransactionBuilder got `twoPhased` method which accepts `TwoPhased` appendix object. We use `TwoPhased` constructor accepting maxHeight, voting model, quorum, vote threshold, whitelist, blacklist as params. Scala language is used, but code is very like Java in the example.

Quote

val Fee = Constants.ONE_NXT
val h = Nxt.getBlockchain.getHeight

val tb = Nxt.getTransactionProcessor.newTransactionBuilder(alicePubKey, 50*Fee, Fee, defaultDeadline, Attachment.ORDINARY_PAYMENT)
tb.twoPhased(new TwoPhased(h+30, Constants.VOTING_MODEL_ACCOUNT, 1, 0, Array[Long](voterId), null))
tb.recipientId(chrisId)

val tx = tb.build()
tx.sign(alicePhrase)
Nxt.getTransactionProcessor.broadcast(tx)

Now Bob's turn to vote on transaction:

Quote

val vatt = new Attachment.PendingPaymentVoteCasting(tx.getId)
val vtb = Nxt.getTransactionProcessor.newTransactionBuilder(bobPubKey, 0, Fee, defaultDeadline, vatt)
val vtx = vtb.build()
vtx.sign(bobPhrase)
Nxt.getTransactionProcessor.broadcast(vtx)

And on block height when transaction is going into the blockchain balance of Chris is increasing by 50 Nxt
(if this height within 30 blocks after Alice's transaction block).

HTTP API

From now every kind of API call creating a transaction has additional parameters:

* pendingVotingModel - mandatory - could be 0,1 or 2 according to following constants:

Quote

public static final byte VOTING_MODEL_BALANCE = 0;
public static final byte VOTING_MODEL_ACCOUNT = 1;
public static final byte VOTING_MODEL_ASSET = 2;

* pendingMaxHeight - mandatory - height to refuse transaction if there's no quorum @ this height. Not less than
10 blocks from current height.

* pendingQuorum - mandatory - number of accounts/total Nxt/assets balance to get transaction released

* pendingMinBalance - optional - vote threshold. 0 if skipped

* pendingAssetId - mandatory if pendingVotingModel == 2 (e.g. by-asset voting)

* pendingWhitelisted - mandatory if by-account voting, provide multiple values if needed (e.g. `pendingWhitelisted=${account1Id}&pendingWhitelisted=${account2Id}`)

* pendingBlacklisted - optional, couldn't be combined with whitelist, provide multiple values if needed

Example:

Poll will be created only after approval of the account 7926777737834261541:

Quote

curl -d 'name=cryptos&description=rate+cryptos+you+like&finishHeight=112000&votingModel=1&minNumberOfOptions=1&maxNumberOfOptions=2&minRangeValue=-5&maxRangeValue=5&secretPhrase=secret+phrase&deadline=1000&feeNQT=1000000000&option1=nxt&option2=btc&isPending=true&pendingVotingModel=1&pendingMaxHeight=111800&pendingQuorum=1&pendingWhitelisted=7926777737834261541' http://localhost:6876/nxt?requestType=createPoll

Also there are some new API calls to get pending transactions, for now just:

* GetAccountPendingTransactionIds - to get pending transactions issued by some account. Possible parameters are "account", "finished", "firstIndex", "lastIndex", where "finished" could be empty or skipped.

* GetAccountPendingTransactionToSignIds - to get pending transactions where account is whitelisted. Parameters are the same as above.

* GetAssetPendingTransactionIds - to get pending transactions where some asset mentioned. Parameters are as above but "asset" instead of "account".

Fees

In case of by-balance & by-account voting pending transaction should be a subject for a higher fee probably,
as a lot of computations could be needed on vote processing. For now fee is standard (i.e. 1 Nxt) though.

jefdiesel · November 11, 2014, 02:45:13 pm

just wow

gs02xzz · November 11, 2014, 03:27:34 pm

awesome! some very smart contracts.

bitcoinpaul · November 11, 2014, 03:37:21 pm

We can consider ourself very lucky for having guys like kushti working on Nxt.

Roiman · November 11, 2014, 03:41:11 pm

Quote from: bitcoinpaul on November 11, 2014, 03:37:21 pm

We can consider ourself very lucky for having guys like kushti working on Nxt.

+1
exciting stuff, cant wait

_mr_e · November 11, 2014, 03:58:23 pm

Awesome man! I hope we will be able to use this to force a confirmation on your mobile device before a transaction on your account can go through.

jones · November 11, 2014, 05:35:53 pm

Quote from: _mr_e on November 11, 2014, 03:58:23 pm

Awesome man! I hope we will be able to use this to force a confirmation on your mobile device before a transaction on your account can go through.

Who ever said 2-factor authentication wasn't possible to do in crypto, they'd be surprised now

There are some really cool options here, your giving me a lot to do ui side

msin · November 11, 2014, 05:53:57 pm

Wow, really great work Kushti!

ThomasVeil · November 11, 2014, 10:04:20 pm

Amazing - really curious to see this in the wild! Respect Kushti!

SwissAlps · November 12, 2014, 07:40:08 am

Quote from: kushti on November 11, 2014, 02:35:02 pm

Two-Phased Transactions

Two-Phased Transactions is multisig transactions implementation in Nxt but much more powerful.

Simplest example, Alice starts a Two-Phased transaction. In the first stage a transaction is included in a blockchain but it isn’t processed immediately and has the status of ‘pending’. For it to be processed, Bob has to complete the second phase of the transaction by approving it. This has to be done before the deadline set by Alice has elapsed.

Use cases

* Bob approving a transaction of Alice

* Shareholders voting whether to send another 1M Nxt to a marketing service or not

* Nxt whales voting on whether to pay bounty or not

* Multisig wallet protected from a hacker(think about BTER case etc)

Features

* any kind of transaction could be 2-phased

* M-of-N consensus or by-balance consensus or shareholders voting to release transaction

* possible vote threshold setting(e.g. only accounts with 1M+ Nxt or 100+ assets balance could vote)

* whitelist of voters

* blacklist of voters

* transaction could be released only prior to maxHeight

Options

* MaxHeight - transaction has to be released before the mandatory height provided or it will be cancelled

* whitelist - list of accounts able to vote on transaction releasing. Max 10 accounts. If no given, any account has a right to vote! Mandatory for by-account voting

* blacklist - list of accounts voting is prohibited for. Only for by-balance & by-asset voting. Couldn't be combined with whitelist(so pending transaction submitter has to choose whether to use whitelist or blacklist).

* Voting option: by account, by balance, by asset.

* Consensus quorum - transaction released when gathered

* Vote threshold - min balance to vote. Only for by-balance & by-asset voting.

Example: accounts A(balance = 1000 nxt),B(700 nxt),C(400 nxt),D(200 nxt) are able to vote. Vote threshold is 300 nxt, so D can't vote. Consensus quorum is 1500 nxt, so transaction will be released only if A & B vote on this. The example doesn't take money transfers & heights into account.

Voting, Multivoting, Counting

It's possible to vote for multiple (max 10) pending transactions withing one voting transaction. It gives
possibility for trustless escrows etc.

In case of by-account(M-out-of-N) voting a pending transaction will be released on block Mth vote being including into a blockchain.

In case of by-balance or by-asset voting following algorithm is applied:

* votes weights are stored into database

* on getting a vote if vote weight + cached weights >= quorum weights rechecking with database update is taking place. if sum(updated weights) >=
quorum transaction is going to be released

* on maxHeight block there's is a final recheck

* this algo means in some cases of balances moving pending transaction could be released on maxHeight only

Trustless escrows

With 2-phased transactions some kinds of trustless escrows are possible. E.g.
Quote
Tx 1. Alice publishes into blockchain a pending transaction to Bob which will be released only when both Alice and Bob vote for it
Tx 2. Bob publishes into blockchain a pending transaction to Alice which will be released only when both Alice and Bob vote for it
Tx 3. Alice generates transaction bytes for a multivote transaction with votes for both transactions 1 & 2 & sends unsigned transaction bytes, the full transaction hash, and the signature hash to Bob
Tx 4. Bob sends to the unconfirmed transactions pool a transaction with votes for both transactions 1 & 2 & reference to hash of transaction #3

See https://nxtforum.org/general/trustless-escrows-are-coming!/ for details

Implementation

To implement 2-phased transactions, 1 new Appendix type & 2 new Transaction types are needed.

* TwoPhased appendix to each type of transaction will mark 2-phased transactions from ordinary ones. Appendix parameters will specify max height to gather consensus to release transaction & poll options(by-account / by-balance / by asset voting), consensus quorum,
list of accounts able to vote, max 10)

* PENDING_PAYMENT_VOTE_CASTING transaction type to for transaction(s) to release (if an account doesn't want this, it should skip voting at all). Max 10 votes possible, so voter can vote up to 10 pending transactions at once. Transaction will be released when quorum(specified by threshold) will be gathered. It will be cancelled if no consensus being gathered @ height maxHeight provided in pending transaction params.

Java API

Let's consider sort of classic example: Alice pays 50 Nxts to Chris, but only after Bob's approval and within 30 blocks after pending transaction issuance. Please note TransactionBuilder got `twoPhased` method which accepts `TwoPhased` appendix object. We use `TwoPhased` constructor accepting maxHeight, voting model, quorum, vote threshold, whitelist, blacklist as params. Scala language is used, but code is very like Java in the example.

Quote
val Fee = Constants.ONE_NXT
val h = Nxt.getBlockchain.getHeight

val tb = Nxt.getTransactionProcessor.newTransactionBuilder(alicePubKey, 50*Fee, Fee, defaultDeadline, Attachment.ORDINARY_PAYMENT)
tb.twoPhased(new TwoPhased(h+30, Constants.VOTING_MODEL_ACCOUNT, 1, 0, Array[Long](voterId), null))
tb.recipientId(chrisId)

val tx = tb.build()
tx.sign(alicePhrase)
Nxt.getTransactionProcessor.broadcast(tx)

Now Bob's turn to vote on transaction:

Quote

val vatt = new Attachment.PendingPaymentVoteCasting(tx.getId)
val vtb = Nxt.getTransactionProcessor.newTransactionBuilder(bobPubKey, 0, Fee, defaultDeadline, vatt)
val vtx = vtb.build()
vtx.sign(bobPhrase)
Nxt.getTransactionProcessor.broadcast(vtx)

And on block height when transaction is going into the blockchain balance of Chris is increasing by 50 Nxt
(if this height within 30 blocks after Alice's transaction block).

HTTP API

From now every kind of API call creating a transaction has additional parameters:

* pendingVotingModel - mandatory - could be 0,1 or 2 according to following constants:

Quote
public static final byte VOTING_MODEL_BALANCE = 0;
public static final byte VOTING_MODEL_ACCOUNT = 1;
public static final byte VOTING_MODEL_ASSET = 2;

* pendingMaxHeight - mandatory - height to refuse transaction if there's no quorum @ this height. Not less than
10 blocks from current height.

* pendingQuorum - mandatory - number of accounts/total Nxt/assets balance to get transaction released

* pendingMinBalance - optional - vote threshold. 0 if skipped

* pendingAssetId - mandatory if pendingVotingModel == 2 (e.g. by-asset voting)

* pendingWhitelisted - mandatory if by-account voting, provide multiple values if needed (e.g. `pendingWhitelisted=${account1Id}&pendingWhitelisted=${account2Id}`)

* pendingBlacklisted - optional, couldn't be combined with whitelist, provide multiple values if needed

Example:

Poll will be created only after approval of the account 7926777737834261541:

Quote
curl -d 'name=cryptos&description=rate+cryptos+you+like&finishHeight=112000&votingModel=1&minNumberOfOptions=1&maxNumberOfOptions=2&minRangeValue=-5&maxRangeValue=5&secretPhrase=secret+phrase&deadline=1000&feeNQT=1000000000&option1=nxt&option2=btc&isPending=true&pendingVotingModel=1&pendingMaxHeight=111800&pendingQuorum=1&pendingWhitelisted=7926777737834261541' http://localhost:6876/nxt?requestType=createPoll

Also there are some new API calls to get pending transactions, for now just:

* GetAccountPendingTransactionIds - to get pending transactions issued by some account. Possible parameters are "account", "finished", "firstIndex", "lastIndex", where "finished" could be empty or skipped.

* GetAccountPendingTransactionToSignIds - to get pending transactions where account is whitelisted. Parameters are the same as above.

* GetAssetPendingTransactionIds - to get pending transactions where some asset mentioned. Parameters are as above but "asset" instead of "account".

Fees

In case of by-balance & by-account voting pending transaction should be a subject for a higher fee probably,
as a lot of computations could be needed on vote processing. For now fee is standard (i.e. 1 Nxt) though.

Hi Kushti,

Yes, it is very near the CETx ! You have got the message !

But to me, it still seems a little complex if you compare it with the ease of use of CETx ?

kushti · November 13, 2014, 12:01:55 am

Quote from: SwissAlps on November 12, 2014, 07:40:08 am

Yes, it is very near the CETx ! You have got the message ![/b][/size]

But to me, it still seems a little complex if you compare it with the ease of use of CETx ?

Sorry got no any message(you meant a PM isnt' it)?

Read most of CETx topic few days ago. The concept seems interesting, the question is whether Nxt has suitable internal data model for scalable implementation of them. Unfortunately, I'm pretty overbusy to do investigation now, mb will be relatively free only after new features will be released.

Seems UI dev is needed for 2-phased stuff as jones will concentrate on Jay framework after voting UI.

P.S. Thank you a lot guys! I'm happy to work for you!

bitcoinpaul · November 13, 2014, 07:12:50 am

Quote from: kushti on November 13, 2014, 12:01:55 am

Quote from: SwissAlps on November 12, 2014, 07:40:08 am
Yes, it is very near the CETx ! You have got the message !

Sorry got no any message(you meant a PM isnt' it)?

He meant u grasped the idea

_mr_e · November 13, 2014, 04:14:49 pm

Kushti,

Are there any plans to implement the following, I believe it can be a game changer for online services like securea or and online version of freemarket as BTCDEV listed here: https://162.243.13.81.

These services look awesome, and I would love to use secureae but I will not enter my password into an online website. Not gonna happen. Can we make phasing so that we can give these services one password and every time they try to do a transaction phasing is used to send a push notification to our phone which we have to accept with a yes/no.

This would have a few interesting benefits.

For example, I can use an easy to remember password to access these sites, while keeping the complex secondary password on the other device. This means, I can now easily log into these services from any computer anywhere in the world from memory without my password really being at risk.

These services are also very convenient and powerful. The secureae site is actually much better then the client itself. This could open up the door to a swath of innovative online services that cannot steal your password but can make tx you approve. Online wallets, exchanges, free market, supernet features etc. I would use secureae 100% of the time to do my trading if this was the case.

I wouldn't ever need to enter my real password onto a computer! This makes me protected from all sorts of nasty viruses / keyloggers. Right now I hate that I have to store/enter my password over and over on my pc, especially when my account controls a good amount of money. It's a very scary experience given todays computers are not easily secured.

Is this on the roadmap? If not I may like to look into deving such a feature myself when phasing is complete. Please let me know what you think about these being a possibility because I believe this would be a MASSIVE game changer for nxt if done right. All we need is a secure android application that can protect and encrpyt your complex passphrase with a pin and we would easily thwart a large number of possible attack vectors on your account, while opening the door to untold amounts of innovation.

benjyz · November 13, 2014, 08:08:57 pm

I think Two-Factor authentication in a decentral way could be done. You basically generate a one-time password and use an out of band channel for verification. This might be possible to do via Twillio or other 2FA providers (maybe authentify). I've thought about it, but have not worked out the details. https://nxtforum.org/general/two-factor-auth/

newsilike · November 14, 2014, 12:18:08 am

Awesome archievment I like!

benjyz · November 16, 2014, 10:49:35 pm

Is this merged yet in master? If I search for phase in the codebase I get no results.

HolgerD77 · November 17, 2014, 08:29:20 am

Quote from: benjyz on November 16, 2014, 10:49:35 pm

Is this merged yet in master? If I search for phase in the codebase I get no results.

No, it's not.

SwissAlps · November 17, 2014, 08:47:40 am

Quote from: bitcoinpaul on November 13, 2014, 07:12:50 am

Quote from: kushti on November 13, 2014, 12:01:55 am
Quote from: SwissAlps on November 12, 2014, 07:40:08 am
Yes, it is very near the CETx ! You have got the message !

Sorry got no any message(you meant a PM isnt' it)?

He meant u grasped the idea

Yes, bitcoinpaul, perfectly right.

Sorry about that, again my english; everything would be so nice in the world if everybody just speaks the same language, ie french.

rudeboi · November 17, 2014, 12:49:20 pm

Quote from: jones on November 11, 2014, 05:35:53 pm

Quote from: _mr_e on November 11, 2014, 03:58:23 pm
Awesome man! I hope we will be able to use this to force a confirmation on your mobile device before a transaction on your account can go through.

Who ever said 2-factor authentication wasn't possible to do in crypto, they'd be surprised now

There are some really cool options here, your giving me a lot to do ui side

This would be amazing if this would enable 2 factor auth on the mobile app.
But at the moment don't you have to choose to send transactions as 2 phased, meaning that if your account is hacked the attacker would just choose not to use 2 phased?

Unless there is some kind of set all transactions as 2 phased switch, that can only be changed via agreement of primary and secondary account?

bitcoinpaul · November 17, 2014, 01:04:10 pm

account control to the rescue!

benjyz · November 17, 2014, 01:54:27 pm

Quote from: rudeboi on November 17, 2014, 12:49:20 pm

Quote from: jones on November 11, 2014, 05:35:53 pm
Quote from: _mr_e on November 11, 2014, 03:58:23 pm
Awesome man! I hope we will be able to use this to force a confirmation on your mobile device before a transaction on your account can go through.

Who ever said 2-factor authentication wasn't possible to do in crypto, they'd be surprised now

There are some really cool options here, your giving me a lot to do ui side

This would be amazing if this would enable 2 factor auth on the mobile app.
But at the moment don't you have to choose to send transactions as 2 phased, meaning that if your account is hacked the attacker would just choose not to use 2 phased?

Unless there is some kind of set all transactions as 2 phased switch, that can only be changed via agreement of primary and secondary account?

Enabling 2FA means giving up control. It's tricky. usually the way this is done via a provider such as google. So you need really a tool to build 2FA from scratch. With Twillio this might be done. So instead of building standard 2FA it would be like building a 2FA provider. A 2FA provider sends a one-time token. 2FA provider needs to be trusted. Whether this security architecture really makes sense, would have to be evaluated in more detail. My experience from security is that it's usually corrupted in one or many ways - sometimes because of malice sometimes because or stupidity.

rudeboi · November 17, 2014, 04:01:18 pm

If there was a flag that could be set on an account that means that only 2 phased transactions get processed.

Set flag by setting in primary account, then have your secondary account confirm this.

Disable flag by the exact same process as above, but it has to be the same secondary account confirming. Sensibly we should also enable flag to be auto disabled after a period of time (block) period (eg: 1 month but adjustable) this is for everyone that loses there secondary device so they aren’t locked out forever, however the user always has the chance to reset the flag whenever they want.

During flag enabled period, only 2 phased transactions that at least contain the secondary account will get processed. (Can also have more accounts if wanted Bob, Alice and all the chums haha)

All that needs to happen is for someone to write a lightweight blockchainless android client app “Nxt 2FA”, it’s only job is to confirm 2 phased transactions and flags. Boom Nxt has solved decentralised 2FA!

Notes:

Using the 2FA app would cost the minimum fee, so the account would have to be funded.
App monitors the pre-set account on the block chain (through an online public node) for any incoming 2 phased requests, if new one is seen, send a push notification to the user, user has to sign in and confirm, it would be locally signed via a short password through an encrypted database that stores the secondary secret phrase.

kushti · November 17, 2014, 09:23:52 pm

Quote from: rudeboi on November 17, 2014, 04:01:18 pm

If there was a flag that could be set on an account that means that only 2 phased transactions get processed.

Set flag by setting in primary account, then have your secondary account confirm this.

Yes, we need for Account Control with 2-phased restriction support. yustas is working on AC now, I dunno details right now unfortunately

rudeboi · November 17, 2014, 09:45:34 pm

Quote from: kushti on November 17, 2014, 09:23:52 pm

Quote from: rudeboi on November 17, 2014, 04:01:18 pm
If there was a flag that could be set on an account that means that only 2 phased transactions get processed.

Set flag by setting in primary account, then have your secondary account confirm this.

Yes, we need for Account Control with 2-phased restriction support. yustas is working on AC now, I dunno details right now unfortunately

Exciting! I knew AC was coming, but I didn't know a dev was already working on it.

I don't think I read on cfb's AC thread that 2 phased restriction support was on the planned list, I'll go have a read of it again now.

benjyz · November 18, 2014, 07:32:03 am

Quote from: rudeboi on November 17, 2014, 04:01:18 pm

Boom Nxt has solved decentralised 2FA!

If you're not using Google's service you need to be able to send a message / SMS via code. So someone could build an open 2FA provider service paid in Nxt. It's possible to do based on Twillio.

SwissAlps · November 18, 2014, 07:59:29 am

Quote from: bitcoinpaul on November 17, 2014, 01:04:10 pm

account control to the rescue!

Yes, very usefull.

It is quite important to be able to lock a given account (permanently or temporary), or be able to receive in this account only from a list of specific assets or subcurrencies.

farl4bit · February 05, 2015, 07:11:38 pm

Interesting post! Tweeted it!

_mr_e · February 05, 2015, 09:03:51 pm

Quote from: rudeboi on November 17, 2014, 04:01:18 pm

If there was a flag that could be set on an account that means that only 2 phased transactions get processed.

Set flag by setting in primary account, then have your secondary account confirm this.

Disable flag by the exact same process as above, but it has to be the same secondary account confirming. Sensibly we should also enable flag to be auto disabled after a period of time (block) period (eg: 1 month but adjustable) this is for everyone that loses there secondary device so they aren’t locked out forever, however the user always has the chance to reset the flag whenever they want.

During flag enabled period, only 2 phased transactions that at least contain the secondary account will get processed. (Can also have more accounts if wanted Bob, Alice and all the chums haha)

All that needs to happen is for someone to write a lightweight blockchainless android client app “Nxt 2FA”, it’s only job is to confirm 2 phased transactions and flags. Boom Nxt has solved decentralised 2FA!

Notes:
Using the 2FA app would cost the minimum fee, so the account would have to be funded.
App monitors the pre-set account on the block chain (through an online public node) for any incoming 2 phased requests, if new one is seen, send a push notification to the user, user has to sign in and confirm, it would be locally signed via a short password through an encrypted database that stores the secondary secret phrase.

I have already developed this android app and a supernet plugin to help accomplish the initialization stuff. I am only now awaiting account control.

rudeboi · February 05, 2015, 09:41:40 pm

Quote from: _mr_e on February 05, 2015, 09:03:51 pm

Quote from: rudeboi on November 17, 2014, 04:01:18 pm
If there was a flag that could be set on an account that means that only 2 phased transactions get processed.

Set flag by setting in primary account, then have your secondary account confirm this.

Disable flag by the exact same process as above, but it has to be the same secondary account confirming. Sensibly we should also enable flag to be auto disabled after a period of time (block) period (eg: 1 month but adjustable) this is for everyone that loses there secondary device so they aren’t locked out forever, however the user always has the chance to reset the flag whenever they want.

During flag enabled period, only 2 phased transactions that at least contain the secondary account will get processed. (Can also have more accounts if wanted Bob, Alice and all the chums haha)

All that needs to happen is for someone to write a lightweight blockchainless android client app “Nxt 2FA”, it’s only job is to confirm 2 phased transactions and flags. Boom Nxt has solved decentralised 2FA!

Notes:
Using the 2FA app would cost the minimum fee, so the account would have to be funded.
App monitors the pre-set account on the block chain (through an online public node) for any incoming 2 phased requests, if new one is seen, send a push notification to the user, user has to sign in and confirm, it would be locally signed via a short password through an encrypted database that stores the secondary secret phrase.
I have already developed this android app and a supernet plugin to help accomplish the initialization stuff. I am only now awaiting account control.

Brilliant! Great work.

I assume local signing, and local encrypted password storing the passphrase?

How does your blockchain less consensus work?

_mr_e · February 05, 2015, 09:59:34 pm

Quote from: rudeboi on February 05, 2015, 09:41:40 pm

Brilliant! Great work.

I assume local signing, and local encrypted password storing the passphrase?

How does your blockchain less consensus work?

Yes to local signing and password is locked in private app storage and will never need to leave the device. (Other then the recommended backing up your passphrase by writing it down somewhere)

Initially I will have a server that will register your phone app with it's google id. You will then link up your phone to your account through a supernet plugin(This will also enable AC and fund your phone account). The server then begins watching for 2 phased transactions through a local NRS node and is responsible for sending the push notification to your phone when it sees one. You are then able to accept the transaction on your device which will sign the transaction and push it to the server to broadcase to NRS. (I'm thinking of including a screen where you can manually enter a transaction id and sign the confirmation and push it directly to any NRS node, in case the server is unavailable you can still manually confirm. This would be v1.1 though.)

Future versions will include distributing the server across supernet nodes and hopefully eventually becoming more decentralized through advanced supernet features. Protecting the google id for push notifications across a distributed system is a concern we haven't solved yet.

slothbag · February 05, 2015, 11:44:59 pm

I'd love to see the "Pay on secret reveal" included as part of 2-phased transactions.. It removes the need for escrow when doing cross chain trades.. and opens the doors for truly decentralizaed exchanges. Would be great for Nxt to be leading this

https://bitbucket.org/JeanLucPicard/nxt/issue/224/proposal-new-tx-type-pay-on-reveal-secret

lovely89 · February 06, 2015, 02:11:42 am

I heard that 2-phased transactions is the same as account control. With account control, I was under the impression you could send multiple assets at once. E.g. moving to a new account with 1 fee for all transfers .

Will this be a feature with 2-phased transactions or is it already existing in the api and just needs a ui implementation... Or is it yet to be possible?

Regards.

kushti · February 06, 2015, 04:55:06 pm

Account Control is not a part of Two-Phased Transaction. It will be released later(1.6-1.7).

P2SH also will be implemented later(1.6?).

HCLivess · February 13, 2015, 10:34:29 am

Great, thank you

Daedelus · February 16, 2015, 04:10:39 pm

Quote from: kushti on February 06, 2015, 04:55:06 pm

Account Control is not a part of Two-Phased Transaction. It will be released later(1.6-1.7).

P2SH also will be implemented later(1.6?).

Sorry, but what is P2SH?

valarmg · February 16, 2015, 04:13:15 pm

Quote from: Daedelus on February 16, 2015, 04:10:39 pm

Quote from: kushti on February 06, 2015, 04:55:06 pm
Account Control is not a part of Two-Phased Transaction. It will be released later(1.6-1.7).

P2SH also will be implemented later(1.6?).

Sorry, but what is P2SH?

This, I assume: (Pay 2 Secret Hash?)

Quote from: slothbag on February 05, 2015, 11:44:59 pm

I'd love to see the "Pay on secret reveal" included as part of 2-phased transactions.. It removes the need for escrow when doing cross chain trades.. and opens the doors for truly decentralizaed exchanges. Would be great for Nxt to be leading this

https://bitbucket.org/JeanLucPicard/nxt/issue/224/proposal-new-tx-type-pay-on-reveal-secret

Daedelus · February 16, 2015, 04:16:44 pm

Thanks but what does it stand for? Can't figure it out..

Edit: I guessed "Pay 2 show hand" but that is backwards to how it works

It would be something like "Show hand 2 pay"

jones · February 16, 2015, 07:48:50 pm

Quote from: Daedelus on February 16, 2015, 04:16:44 pm

Thanks but what does it stand for? Can't figure it out..

Edit: I guessed "Pay 2 show hand" but that is backwards to how it works It would be something like "Show hand 2 pay"

Pay to Script Hash, from Bitcoin's BIP 16

https://en.bitcoin.it/wiki/Pay_to_script_hash

Daedelus · February 16, 2015, 09:31:23 pm

Quote from: jones on February 16, 2015, 07:48:50 pm

Quote from: Daedelus on February 16, 2015, 04:16:44 pm
Thanks but what does it stand for? Can't figure it out..

Edit: I guessed "Pay 2 show hand" but that is backwards to how it works It would be something like "Show hand 2 pay"

Pay to Script Hash, from Bitcoin's BIP 16

https://en.bitcoin.it/wiki/Pay_to_script_hash

Ty, good reference. Someone is bound to ask me sooner or later if I keep mentioning it

Daedelus · March 19, 2015, 01:34:31 pm

Bump.

For anyone interested in the up coming 2-phased transactions (aka phasing or advanced multisig) to be released in NRS version 1.5.0 (the next release!)

Daedelus · 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)

Fatih87SK · March 19, 2015, 02:35:33 pm

Quote from: Daedelus 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)

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

bob_ggg · 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.

Daedelus · 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?

kushti · March 28, 2015, 04:16:42 am

Quote from: Daedelus 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?

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

_mr_e · March 28, 2015, 04:36:56 am

Quote from: kushti on March 28, 2015, 04:16:42 am

Quote from: Daedelus 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?

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.

Riker · March 28, 2015, 03:25:53 pm

Quote from: bob_ggg 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.

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.

jl777 · 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

Riker · March 28, 2015, 05:11:42 pm

Quote from: jl777 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

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.

jl777 · March 28, 2015, 05:14:01 pm

Quote from: lyaffe on March 28, 2015, 05:11:42 pm

Quote from: jl777 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

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

bob_ggg · March 30, 2015, 02:15:35 pm

Quote from: lyaffe on March 28, 2015, 03:25:53 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.

bob_ggg · March 30, 2015, 02:22:50 pm

Quote from: lyaffe on March 28, 2015, 03:25:53 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.

coretechs · 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?

Jean-Luc · 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.

Daedelus · March 30, 2015, 08:29:28 pm

Quote from: kushti on March 28, 2015, 04:16:42 am

Quote from: Daedelus 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?

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?

Riker · March 30, 2015, 08:38:47 pm

Quote from: jl777 on March 28, 2015, 05:14:01 pm

Quote from: lyaffe on March 28, 2015, 05:11:42 pm
Quote from: jl777 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

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.

jl777 · March 30, 2015, 08:45:49 pm

Quote from: lyaffe on March 30, 2015, 08:38:47 pm

Quote from: jl777 on March 28, 2015, 05:14:01 pm
Quote from: lyaffe on March 28, 2015, 05:11:42 pm
Quote from: jl777 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

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.

Riker · March 30, 2015, 08:49:50 pm

Quote from: jl777 on March 30, 2015, 08:45:49 pm

Quote from: lyaffe on March 30, 2015, 08:38:47 pm
Quote from: jl777 on March 28, 2015, 05:14:01 pm
Quote from: lyaffe on March 28, 2015, 05:11:42 pm
Quote from: jl777 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

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.

jl777 · March 30, 2015, 09:20:51 pm

Quote from: lyaffe on March 30, 2015, 08:49:50 pm

Quote from: jl777 on March 30, 2015, 08:45:49 pm
Quote from: lyaffe on March 30, 2015, 08:38:47 pm
Quote from: jl777 on March 28, 2015, 05:14:01 pm
Quote from: lyaffe on March 28, 2015, 05:11:42 pm
Quote from: jl777 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

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

Riker · 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.

kushti · April 01, 2015, 08:30:06 am

Quote from: Daedelus on March 30, 2015, 08:29:28 pm

Quote from: kushti on March 28, 2015, 04:16:42 am
Quote from: Daedelus 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?

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.

Daedelus · April 01, 2015, 08:47:00 am

Thanks, that cleared that up.

Jean-Luc · April 01, 2015, 11:52:09 pm

Quote from: lyaffe 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.

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.

jl777 · April 01, 2015, 11:57:47 pm

Quote from: Jean-Luc on April 01, 2015, 11:52:09 pm

Quote from: lyaffe 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.

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!!

msin · April 02, 2015, 01:51:02 am

Quote from: Jean-Luc on April 01, 2015, 11:52:09 pm

Quote from: lyaffe 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.

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!

kushti · 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.

slothbag · 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?

Jean-Luc · 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).

slothbag · 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.

Jean-Luc · 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.

verymuchso · April 04, 2015, 07:56:07 pm

Quote from: Jean-Luc 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.

Why was 100 bytes selected and not 1000 bytes? Would 1000 bytes not be handy when somewhat longer JSON data is hashed?

Jean-Luc · 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.

verymuchso · April 04, 2015, 08:14:42 pm

Quote from: Jean-Luc 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.

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?

jl777 · April 04, 2015, 08:17:22 pm

Quote from: Jean-Luc 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.

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

Daedelus · April 05, 2015, 06:46:37 pm

Quote from: Jean-Luc on April 01, 2015, 11:52:09 pm

Quote from: lyaffe 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.

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:

Quote from: Nxtblg on April 05, 2015, 04:40:11 pm

Quote from: Daedelus on April 02, 2015, 12:44:09 pm
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?

jl777 · April 05, 2015, 07:16:26 pm

Quote from: Daedelus on April 05, 2015, 06:46:37 pm

Quote from: Jean-Luc on April 01, 2015, 11:52:09 pm
Quote from: lyaffe 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.

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:

Quote from: Nxtblg on April 05, 2015, 04:40:11 pm
Quote from: Daedelus on April 02, 2015, 12:44:09 pm
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

Jean-Luc · 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.

jl777 · April 05, 2015, 08:12:54 pm

Quote from: Jean-Luc 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.

RMD160

plz make sure it can be made compatible with bitcoin

Jean-Luc · 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.

jl777 · April 05, 2015, 09:30:32 pm

Quote from: Jean-Luc 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.

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

Jean-Luc · April 06, 2015, 08:47:12 am

I will support sha256, ripemd160, and ripemd160(sha256(x)).

Daedelus · May 16, 2015, 11:31:29 am

There is a call for non technical users to test the testnet; you your uncle, your mother your boyfriend.. everyone needs to give it a try.

https://nxtforum.org/general-discussion/%28core%29-release-or-not-release/

Using the testnet it easy (they designed it that way

)

What is testnet? It is a play area for new features to be trialled and broken before going on the mainnet that we all use otherwise. It looks the same, works the same as you are used to but you get to play with the newest features before they are released

Things beginners need to know:

1) Don't use your mainnet passwords on the testnet.

2) Do not use your mainnet passwords on the testnet. Create new testnet accounts you only use on testnet, do this and you will be completely safe.

3) Put the testnet client folder in a different place to you mainnet client folder. Cos you can't have two 'nxt' folders in the same place (stop laughing please)

4) Once you have the testnet client running with a brand new testnet account set up, post you account ID here: https://nxtforum.org/testnet/some-testnxt-to-test-asset-exchange/

5) By doing 4), you will shortly be sent some FREE TestNXT! (that aren't worth anything). So you will then have the ammunition to...

Have a vote on the world's best bobsleigh team
Phase a transaction to yourself to stop you spending your pocket money until next week
Play with the various plugins that aren't available on mainnet yet, like NxtBubble everyone has been losing their minds over recently. Play for free
and more

Personally, I am going to create an MSCoin and use it as tokens in a vote (yes, you can vote with stuff other than NXT

). If you want to take part, please post your testnet account here and I will send you a few tokens.

If I have convinced you to give it a whirl (what is the worst that could happen?), the latest testnet client is 1.5.8e and you can download it from: https://nxtforum.org/nrs-releases/nrs-v1-5-8e/

If this post is scary and frightening (understandable), then don't worry. Just ignore it and make sure you have upgraded the latest stable mainnet client (at time of writing NRS v1.4.18)

Please post any questions and I will find someone who can answer them

News:

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