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

Login with username, password and session length
Advanced search  

News:

Latest Nxt Client: Nxt 1.11.15

Pages: [1] 2 3 ... 5  All

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

kushti

  • Core Dev
  • Sr. Member
  • ****
  • Karma: +184/-5
  • Offline Offline
  • Posts: 384
  • Nxt Core & Apps Dev
    • View Profile
2-Phased Transactions Post-Implementation Specification
« 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.
Logged
for donations / messages: NXT-PKXM-WH25-UXXG-CJAVD (alias: kushti)

jefdiesel

  • Hero Member
  • *****
  • Karma: +88/-77
  • Offline Offline
  • Posts: 1275
    • View Profile
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #1 on: November 11, 2014, 02:45:13 pm »

just wow
Logged
Member of D.O.R.C.S., creators of Lyth - An Emergent Trading Game | Asset ID: 2318361924203311027

gs02xzz

  • Hero Member
  • *****
  • Karma: +56/-12
  • Offline Offline
  • Posts: 1101
    • View Profile
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #2 on: November 11, 2014, 03:27:34 pm »

awesome! some very smart contracts.
Logged
Nxt Mission is to commercialize the crypto technology and build new commerce and society.

bitcoinpaul

  • Hero Member
  • *****
  • Karma: +589/-588
  • Offline Offline
  • Posts: 3093
  • Karmageddon
    • View Profile
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #3 on: November 11, 2014, 03:37:21 pm »

We can consider ourself very lucky for having guys like kushti working on Nxt.
Logged
Like my Avatar? Reply now! NXT-M5JR-2L5Z-CFBP-8X7P3

Roiman

  • Jr. Member
  • **
  • Karma: +11/-0
  • Offline Offline
  • Posts: 78
    • View Profile
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #4 on: November 11, 2014, 03:41:11 pm »

We can consider ourself very lucky for having guys like kushti working on Nxt.
+1
exciting stuff,  cant  wait :)
Logged

_mr_e

  • Hero Member
  • *****
  • Karma: +88/-18
  • Offline Offline
  • Posts: 956
    • View Profile
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #5 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.
Logged

jones

  • Hero Member
  • *****
  • Karma: +310/-8
  • Offline Offline
  • Posts: 1043
  • write code not war
    • View Profile
    • jNxt
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #6 on: November 11, 2014, 05:35:53 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  ;D

There are some really cool options here, your giving me a lot to do ui side  ;)
Logged
-- Jones NXT-RJU8-JSNR-H9J4-2KWKY

msin

  • Hero Member
  • *****
  • Karma: +138/-18
  • Offline Offline
  • Posts: 1288
    • View Profile
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #7 on: November 11, 2014, 05:53:57 pm »

Wow, really great work Kushti!
Logged

ThomasVeil

  • Hero Member
  • *****
  • Karma: +183/-11
  • Offline Offline
  • Posts: 1400
    • View Profile
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #8 on: November 11, 2014, 10:04:20 pm »

Amazing - really curious to see this in the wild! Respect Kushti!
Logged
ARDOR-BPV3-837M-QZTQ-9DQ69  oxpal.com

SwissAlps

  • Hero Member
  • *****
  • Karma: +31/-16
  • Offline Offline
  • Posts: 519
    • View Profile
    • NxtTracker.com
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #9 on: November 12, 2014, 07:40:08 am »

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 ?
Logged
CryptoNanoPay project
Note that the "Barter Point" test has just started...

kushti

  • Core Dev
  • Sr. Member
  • ****
  • Karma: +184/-5
  • Offline Offline
  • Posts: 384
  • Nxt Core & Apps Dev
    • View Profile
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #10 on: November 13, 2014, 12:01:55 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!
Logged
for donations / messages: NXT-PKXM-WH25-UXXG-CJAVD (alias: kushti)

bitcoinpaul

  • Hero Member
  • *****
  • Karma: +589/-588
  • Offline Offline
  • Posts: 3093
  • Karmageddon
    • View Profile
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #11 on: November 13, 2014, 07:12:50 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 ;)
Logged
Like my Avatar? Reply now! NXT-M5JR-2L5Z-CFBP-8X7P3

_mr_e

  • Hero Member
  • *****
  • Karma: +88/-18
  • Offline Offline
  • Posts: 956
    • View Profile
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #12 on: 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.

« Last Edit: November 13, 2014, 04:20:20 pm by _mr_e »
Logged

benjyz

  • Hero Member
  • *****
  • Karma: +71/-4
  • Offline Offline
  • Posts: 508
    • View Profile
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #13 on: 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/
Logged

newsilike

  • Jr. Member
  • **
  • Karma: +7/-0
  • Offline Offline
  • Posts: 52
  • We Are Familee We Are Free
    • View Profile
    • Jesus Eternal Life in Freedom
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #14 on: November 14, 2014, 12:18:08 am »

Awesome archievment I like!  :D
Logged
I was seeking Freedom then I found Jesus
Jesus wasn't a christian and neither a muslim
https://www.jesuslivenow.info/

benjyz

  • Hero Member
  • *****
  • Karma: +71/-4
  • Offline Offline
  • Posts: 508
    • View Profile
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #15 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.
Logged

HolgerD77

  • Core Dev
  • Sr. Member
  • ****
  • Karma: +49/-0
  • Offline Offline
  • Posts: 299
    • View Profile
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #16 on: November 17, 2014, 08:29:20 am »

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

No, it's not.
Logged
NXT-AQ9F-JC4F-NCM2-4JSXZ

SwissAlps

  • Hero Member
  • *****
  • Karma: +31/-16
  • Offline Offline
  • Posts: 519
    • View Profile
    • NxtTracker.com
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #17 on: November 17, 2014, 08:47:40 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.
Logged
CryptoNanoPay project
Note that the "Barter Point" test has just started...

rudeboi

  • Hero Member
  • *****
  • Karma: +55/-4
  • Offline Offline
  • Posts: 633
  • Nxt Organization Member
    • View Profile
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #18 on: November 17, 2014, 12:49:20 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  ;D

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?
Logged
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬  ▄▀▀▀▀▀▀▀▀▄  ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬●  nimirum  ●▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
▬▬▬ ◖ENDING CENSORSHIP ONLINE◗  ◖ ICO OPEN NOW◗ ▬▬▬

bitcoinpaul

  • Hero Member
  • *****
  • Karma: +589/-588
  • Offline Offline
  • Posts: 3093
  • Karmageddon
    • View Profile
Re: 2-Phased Transactions Post-Implementation Specification
« Reply #19 on: November 17, 2014, 01:04:10 pm »

account control to the rescue!
Logged
Like my Avatar? Reply now! NXT-M5JR-2L5Z-CFBP-8X7P3
Pages: [1] 2 3 ... 5  All
 

elective-stereophonic
elective-stereophonic
assembly
assembly