[NXT] Development Discussion - The dev plan that keeps on delivering

[Daedelus]

Seems Nxt has a new core dev. I can't keep up.. 

Is Petko new?

Yes, active contributor made some improvements to peer layer & tests and working on AC [Account Control] now.

[Daedelus]

Important: Get ready for JAVA 8

Java 8 is needed for the NRS 1.5.x series of updates

You can do it when it is released but ChuckOne thought "some folks of you need more time to get this ready and test your environment well"


See Announcement thread here: https://nxtforum.org/general-discussion/(core)-get-ready-for-java-8-0/

[box0211]

2FA in Nxt will be realized with hashchains.

What if I have a smartphone app that has a secretphrase encrypted with the data in a qr code kept somewhere else, then I need to scan that qr code to decrypt the secretphrase, the app signs the transaction bytes with it and then discards the secretphrase and qr code data.

This isn't true 2FA. In 2FA the code is generated dynamically, so it changes every 30  second and can't be reused.

What you describe here is static password in the phone that you are scanning instead of typing.

That isn't 2FA

Nxt client never saves the password  anyway, so if you don't like typing that password, you can write an app that scans it instead. Same thing. This isn't 2FA

any link to how hashchains would work for 2fa?

[Daedelus]

Edited the OP to remove "Pay on Secret Reveal" Transaction type in version 1.7.x as this will be part of 1.5.x (in 2 Phased Transactions)

See:

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]

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

+1

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.

[Daedelus]

All being well, testnet NRS v.1.5e will be released in a couple of day 

Hi, do you know any release date yet for the 1.5 NRS?

Thanks

If nothing serious happen, we will be able to release 1.5.0e after this weekend. Please note, this is an experimental release for testnet first.

This is only for tech users to test before full release.

[Nxtblg]

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?

[Daedelus]

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'll ask.

[Daedelus]

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?

Reply from jl777

I will use this for InstantDEX

[Daedelus]

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.

[Nxtblg]

Thanks, Daedelus.

[Daedelus]

Vitalik Buterin of Ethereum fame finds Nxt's algo "cryptoeconomically secure"

https://bitcointalk.org/index.php?topic=1015354.0

[Daedelus]

Potential for expiring voting tokens in version 1.7, BUT...

https://nxtforum.org/voting-system/proposition-asset-token-that-expire-for-voting-system/

Sorry, no additions anymore(for 1.5.x at least), we're going to release! In 1.7 / further releases some additions to VS possible(features for 1.6 already considered and mostly implemented).

*snip*

...version 1.6.x features have already been decided and have already been implemented. Nice 

I think artificial delays are being used to allow bugs to emerge and be fixed between big feature updates in each release that we will be going through for a while yet. +1

[Daedelus]

From Above, go here...

https://bitcointalk.org/index.php?topic=587007.msg11009475#msg11009475  

..for general chat   Post copied across.

[Daedelus]

Account Control will be in NRS 1.6 

Yes, this is part of account control and is planned for 1.6, Petko is working on it.

[Hollowman338]

Fix fungability and maybe i will turn my head.

Can you show me where one unit of NXT is worth more than another?

[Daedelus]

Getting ahead of myself slightly....

Any info for what is in version 1.6?

Probably Coin Shuffling + Account Control(only phaseable in 1.6)

[Daedelus]

Prunable data being work on as we speak for a future release.. 

*snip*
...even with the prunable data I am implementing now...
*snip*

Source: https://nxtforum.org/general-discussion/maximum-block-size-is-too-restrictive/msg173057/#msg173057

[Hollowman338]

Prunable data being work on as we speak for a future release.. 

*snip*
...even with the prunable data I am implementing now...
*snip*

Source: https://nxtforum.org/general-discussion/maximum-block-size-is-too-restrictive/msg173057/#msg173057

This will be absolutely revolutionary. 

I expect TaunSew's head will explode soon after.

[Daedelus]

Jean Luc has finished Blockchain Pruning of Arbitrary Messages and will be included in the next testnet release 

The implementation of prunable plain and encrypted messages is complete and will be in 1.5.1e.