elective-stereophonic
elective-stereophonic
Current 1.7 changelog  
Please login or register.

Login with username, password and session length
Advanced search  

News:

Latest Stable Nxt Client: Nxt 1.11.15 | Latest Experimental Nxt Client: Nxt 1.12.0e

Pages: 1 [2] 3  All

Author Topic: Current 1.7 changelog  (Read 17102 times)

Isildur23

  • Full Member
  • ***
  • Karma: +29/-0
  • Offline Offline
  • Posts: 173
    • View Profile
Re: Current 1.7 changelog
« Reply #20 on: November 12, 2015, 08:57:01 am »

Wow! Great changes! Thank you!
Logged

coinomat

  • Hero Member
  • *****
  • Karma: +214/-18
  • Offline Offline
  • Posts: 1520
    • View Profile
Re: Current 1.7 changelog
« Reply #21 on: November 12, 2015, 09:58:13 am »

To be frank I'm not really worried about coin shuffling any more, in the short run it just won't have sufficient volume to really matter
Why are you worried about coin shuffling (or have been in the beginning)? I think it is absolutely crucial for every cryptocurrency (including BTC) to be completely anonymous to become mainstream (and I mean regular use cases, not blackmarket stuff).
It is a GREAT step forward for Nxt to implement that protocol, we should promote/market that heavily
I have to start a separate thread about it probably. too many questions about this. on the other hand at the moment I don't want to do anything that could potentially hurt NXT
so let this be implemented first.
Logged
Time to go further

Ludom

  • Hero Member
  • *****
  • Karma: +197/-15
  • Offline Offline
  • Posts: 1733
    • View Profile
    • Plaisir & Valeur d'histoire
Re: Current 1.7 changelog
« Reply #22 on: November 12, 2015, 02:04:46 pm »

Shuffling is not about anonymity, it's about privacy. You will always see who owns what. The ownership is always visible, it changes only for payment.

Every thing is transparent, excepted some transactions. But for that, you can already shuffle outside the Nxt system with centralised systems. It's great that Nxt proposes an inside and trustless solution.
Logged
Support us to publish "The first book about Nxt"

Damelon

  • Hero Member
  • *****
  • Karma: +792/-54
  • Offline Offline
  • Posts: 2314
    • View Profile
    • Nxt Inside
Re: Current 1.7 changelog
« Reply #23 on: November 12, 2015, 04:16:17 pm »

Shuffling is not about anonymity, it's about privacy.

Thanks for this very important difference.

Privacy is a basic civil right.

Anonymity is a choice.

There is a big difference between the two.
Once people who insist on their basic rights are treated as criminals or prospective criminals, we are on a slippery slope.

Logged
Member of the Nxt Foundation | Donations: NXT-D6K7-MLY6-98FM-FLL5T
Join Nxt Slack! https://nxtchat.herokuapp.com/
Founder of Blockchain Workspace | Personal Site & Blog

BTCDDev

  • Full Member
  • ***
  • Karma: +20/-4
  • Offline Offline
  • Posts: 148
    • View Profile
Re: Current 1.7 changelog
« Reply #24 on: November 12, 2015, 04:42:16 pm »

What is the status of the UI?

Is there a timeframe?
Logged

Jean-Luc

  • Core Dev
  • Hero Member
  • *****
  • Karma: +816/-81
  • Offline Offline
  • Posts: 1610
    • View Profile
Re: Current 1.7 changelog
« Reply #25 on: November 12, 2015, 05:26:50 pm »

Who has reviewed the shuffle system? Does this mean we should be able to deposit btc into mgw and shuffle the superbtc, effectively creating a super cheap bitcoin mixer?

Tim Ruffing did the review.....
Here's his original paper on coin shuffling again:
https://www.petsymposium.org/2014/papers/Ruffing.pdf

Yes, and here is my discussion with Tim:
https://nxtforum.org/core-development-discussion/coin-shuffling-code-review-by-tim-ruffing/
Logged
GPG key fingerprint: 263A 9EB0 29CF C77A 3D06  FD13 811D 6940 E1E4 240C
NXT-X4LF-9A4G-WN9Z-2R322

LibertyNow

  • Sr. Member
  • ****
  • Karma: +78/-33
  • Offline Offline
  • Posts: 361
    • View Profile
    • Liquid Tech
Re: Current 1.7 changelog
« Reply #26 on: November 14, 2015, 05:41:44 pm »

Really fantastic change log.  A lot of exciting things coming down the pipe!  Good work @Jean-Luc and other developers.  This is why I'm doing the LQD IPO and why I continue to invest time and resources into NXT.  The tech is top tier and the best option for businesses. Once the crypto community gets this, we will see a massive new flow of funding.

LibertyNow
Logged
LQD NXT:17750387231635486778, EDGE NXT: 10713749908351947210
LQD: http://www.liquidtech.info, EDGE: https://www.bustabit.com/user/EDGE_NXTAE

chanc3r

  • Hero Member
  • *****
  • Karma: +124/-50
  • Offline Offline
  • Posts: 1019
  • NXTInspect
    • View Profile
Re: Current 1.7 changelog
« Reply #27 on: November 14, 2015, 09:19:15 pm »

Quote

Messages and EncryptedMessages (non-prunable):
Maximum length reduced to 160 bytes. 1 NXT fee for each 32 bytes after the first 32 bytes. For encrypted messages, the length is measured excluding the nonce and the 16 byte AES initialization vector.

I'm posting this here and in the other threads so its on record...
A Maximum permanent message length of 160 will cause some MGW transactions to fail unless this MGW is changed or this length is increased, still figuring out the minimum needed to sustain MGW unchanged but 160 is definitely too low. This will also increase MGW transaction costs depending on the base fee - for those of you voting...

BTW I already told J-L this but after this discussion was created.
Logged
NXT: 29996814460165 (NXT-JTA7-B2QR-8BFC-2V222)
@imrimr @NXTinspect

Jean-Luc

  • Core Dev
  • Hero Member
  • *****
  • Karma: +816/-81
  • Offline Offline
  • Posts: 1610
    • View Profile
Re: Current 1.7 changelog
« Reply #28 on: November 14, 2015, 09:27:11 pm »

The MGW must switch to prunable, and use archival nodes to retrieve expired prunable messages if needed. This is the solution, not forcing every node to store MGW messages forever, that only those using MGW need.
Logged
GPG key fingerprint: 263A 9EB0 29CF C77A 3D06  FD13 811D 6940 E1E4 240C
NXT-X4LF-9A4G-WN9Z-2R322

jl777

  • Hero Member
  • *****
  • Karma: +718/-123
  • Offline Offline
  • Posts: 6170
    • View Profile
Re: Current 1.7 changelog
« Reply #29 on: November 15, 2015, 12:15:00 am »

The MGW must switch to prunable, and use archival nodes to retrieve expired prunable messages if needed. This is the solution, not forcing every node to store MGW messages forever, that only those using MGW need.
As I posted elsewhere, I do not see how to make MGW reliable while using prunable messages, so any fee increase will have to be passed onto users.

With prunable messages, the edge case of an already paid deposit being forgotten as the data needed to make that correlation gets pruned away and cannot be found, will exist. That means the possibility of multiple payments sent out of the MGW and to prevent that would require all sorts of extra work. Also, the withdraws from users could also be forgotten, but that is less likely of a scenario as long as MGW doesnt go down for 2 weeks.

The deposit transfer though, that is something that is rescanned from scratch each time the MGW restarts. So if the data is pruned, it will look like a pending deposit that hasnt been paid.

Keep in mind these are NXT transactions, not MGW messages, as each MGW message is part of a transaction.

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

I am just a simple C programmer

Jean-Luc

  • Core Dev
  • Hero Member
  • *****
  • Karma: +816/-81
  • Offline Offline
  • Posts: 1610
    • View Profile
Re: Current 1.7 changelog
« Reply #30 on: November 15, 2015, 06:48:46 am »

As I posted elsewhere, I do not see how to make MGW reliable while using prunable messages, so any fee increase will have to be passed onto users.
I already explained elsewhere how to use prunable data and how they are as reliable as permanent.
Logged
GPG key fingerprint: 263A 9EB0 29CF C77A 3D06  FD13 811D 6940 E1E4 240C
NXT-X4LF-9A4G-WN9Z-2R322

blackyblack1

  • Hero Member
  • *****
  • Karma: +165/-82
  • Offline Offline
  • Posts: 1764
    • View Profile
Re: Current 1.7 changelog
« Reply #31 on: November 15, 2015, 06:57:32 am »

The MGW must switch to prunable, and use archival nodes to retrieve expired prunable messages if needed. This is the solution, not forcing every node to store MGW messages forever, that only those using MGW need.
As I posted elsewhere, I do not see how to make MGW reliable while using prunable messages, so any fee increase will have to be passed onto users.

With prunable messages, the edge case of an already paid deposit being forgotten as the data needed to make that correlation gets pruned away and cannot be found, will exist. That means the possibility of multiple payments sent out of the MGW and to prevent that would require all sorts of extra work. Also, the withdraws from users could also be forgotten, but that is less likely of a scenario as long as MGW doesnt go down for 2 weeks.

The deposit transfer though, that is something that is rescanned from scratch each time the MGW restarts. So if the data is pruned, it will look like a pending deposit that hasnt been paid.

Keep in mind these are NXT transactions, not MGW messages, as each MGW message is part of a transaction.

James
You can simply switch off prunning on your MGW machines. It will work the same way as permanent messages unless all your data is lost in some catastrophe.
Logged

jl777

  • Hero Member
  • *****
  • Karma: +718/-123
  • Offline Offline
  • Posts: 6170
    • View Profile
Re: Current 1.7 changelog
« Reply #32 on: November 15, 2015, 07:07:45 am »

The MGW must switch to prunable, and use archival nodes to retrieve expired prunable messages if needed. This is the solution, not forcing every node to store MGW messages forever, that only those using MGW need.
As I posted elsewhere, I do not see how to make MGW reliable while using prunable messages, so any fee increase will have to be passed onto users.

With prunable messages, the edge case of an already paid deposit being forgotten as the data needed to make that correlation gets pruned away and cannot be found, will exist. That means the possibility of multiple payments sent out of the MGW and to prevent that would require all sorts of extra work. Also, the withdraws from users could also be forgotten, but that is less likely of a scenario as long as MGW doesnt go down for 2 weeks.

The deposit transfer though, that is something that is rescanned from scratch each time the MGW restarts. So if the data is pruned, it will look like a pending deposit that hasnt been paid.

Keep in mind these are NXT transactions, not MGW messages, as each MGW message is part of a transaction.

James
You can simply switch off prunning on your MGW machines. It will work the same way as permanent messages unless all your data is lost in some catastrophe.
and its ok to just lose customer data in such a catastrophe?

and there wont ever be any migration to a new server, that maybe is misconfigured and doesnt have the data and then the startup sequence gets confused about phantom pending deposits?

So far we have had bitcoind corrupting its DB, data center breaking the relay nodes, and that is just recent history. In the real world things like that happen

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

I am just a simple C programmer

jl777

  • Hero Member
  • *****
  • Karma: +718/-123
  • Offline Offline
  • Posts: 6170
    • View Profile
Re: Current 1.7 changelog
« Reply #33 on: November 15, 2015, 07:11:47 am »

As I posted elsewhere, I do not see how to make MGW reliable while using prunable messages, so any fee increase will have to be passed onto users.
I already explained elsewhere how to use prunable data and how they are as reliable as permanent.
Are you really claiming that having the mgw data permanently in the blockchain with each mgwtx in the NXT blockchain is just as reliable as prunable data that is stored on whatever public nodes decide to keep them around and the local copies in the MGW servers?

so having 3 + P copies is as reliable as all NXT nodes and not having any special case code for finding the pruned data is just as simple and reliable as having code that checks locally, then remotely over the network to public nodes.

I am quite amazed by this

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

I am just a simple C programmer

Sabertooth

  • Jr. Member
  • **
  • Karma: +3/-1
  • Offline Offline
  • Posts: 53
    • View Profile
Re: Current 1.7 changelog
« Reply #34 on: November 15, 2015, 07:18:31 am »

As I posted elsewhere, I do not see how to make MGW reliable while using prunable messages, so any fee increase will have to be passed onto users.
I already explained elsewhere how to use prunable data and how they are as reliable as permanent.
Are you really claiming that having the mgw data permanently in the blockchain with each mgwtx in the NXT blockchain is just as reliable as prunable data that is stored on whatever public nodes decide to keep them around and the local copies in the MGW servers?

so having 3 + P copies is as reliable as all NXT nodes and not having any special case code for finding the pruned data is just as simple and reliable as having code that checks locally, then remotely over the network to public nodes.

I am quite amazed by this

James

I'm sure how many full blockchain copies that will be available will greatly outnumber the multisig data sets that you rely on to run the MGW servers.
Logged

Jean-Luc

  • Core Dev
  • Hero Member
  • *****
  • Karma: +816/-81
  • Offline Offline
  • Posts: 1610
    • View Profile
Re: Current 1.7 changelog
« Reply #35 on: November 15, 2015, 09:08:18 am »

There is no need to write any special case code to handle pruned data. Once your local servers are configured to store prunable data indefinitely, they take care of retrieving any missing prunable data from public archival nodes automatically. This was a major feature implemented in 1.6 (thanks, ScripterRon!). And such retrieval is only needed during the initial blockchain download, or if a server has been offline for more than 2 weeks.

I have also increased the default prunable lifetime from 2 weeks to 90 days in 1.6, so most nodes, public or not, will store 3 months worth of prunable data (although those running on limited performance devices can still prefer to reduce that to 2 weeks only). This gives you yet another redundancy layer, even if your servers are down for more than 2 weeks, and there are no public archival nodes, the last 3 months of data are still stored on almost all nodes.
Logged
GPG key fingerprint: 263A 9EB0 29CF C77A 3D06  FD13 811D 6940 E1E4 240C
NXT-X4LF-9A4G-WN9Z-2R322

chanc3r

  • Hero Member
  • *****
  • Karma: +124/-50
  • Offline Offline
  • Posts: 1019
  • NXTInspect
    • View Profile
Re: Current 1.7 changelog
« Reply #36 on: November 15, 2015, 09:36:49 am »

I'm talking to other members of the team as well.

MGW servers are already set to store prunable messages because of the risk the transfer requests coming in from client users are prunable.

As I understand it when a node runs the archive service it simply stores the blockchain 'unabridged' and the API calls work as expected, so if the node has the non pruned blocks then it will return it in the API call, nothing special needs to be done.

Basically NXT has evolved to have two types of peer, some storing the unabridged blockchain and some storing the pruned chain. Most end users (not using a lite client) will run a peer which retrieves the unabridged blockchain and it can get this from either type of peer.

Services like MGW & probably other businesses needing such records will need to run a peer which implements the archive service which will need to contact and retrieve the full blockchain from other peers also running the archive service..

This is where I think some nervousness comes in - does anyone know how many peers there are out there which are running the archive service ?
How can I be sure that I can always find an archive peer?
If at any point there are no archive peers running then the full blockchain cannot be retrieved if I need a new download.

Knowing and being confident of the size of the community you can rely on for that back up the full blockchain that you need I think is an important asoect of this change to 1.7 which will drive the use of prunable data.
Logged
NXT: 29996814460165 (NXT-JTA7-B2QR-8BFC-2V222)
@imrimr @NXTinspect

Sebastien256

  • Hero Member
  • *****
  • Karma: +169/-24
  • Offline Offline
  • Posts: 2823
  • ^LOOK UP^ = Nxt community!
    • View Profile
Re: Current 1.7 changelog
« Reply #37 on: November 15, 2015, 09:50:06 am »

So, if I understand from chanc3r post, it would be be nice to have a place in the NRS client that show:
1) the number of node runing nxt client
2) the type of node, archive node or not.

That would be important and pertinent information to retrieve and show in the default NRS clients, imo. That would increase confidence in the retrievability of the Nxt prunable system.
« Last Edit: November 15, 2015, 10:13:27 am by Sebastien256 »
Logged
Please drop your ideas concerning Nxt and/or NRS in this topic -> List of feature request for Nxt and/or NRS (with the full list in OP).

Seccour

  • Sr. Member
  • ****
  • Karma: +68/-15
  • Offline Offline
  • Posts: 380
    • View Profile
Re: Current 1.7 changelog
« Reply #38 on: November 15, 2015, 01:46:53 pm »

The MGW must switch to prunable, and use archival nodes to retrieve expired prunable messages if needed. This is the solution, not forcing every node to store MGW messages forever, that only those using MGW need.

Can we not just wait until MGW devs find a way to switch to prunable or to only use 32 bytes ?
Logged
SecFund : 9125535795764729261 (Asset ID)

Brangdon

  • Hero Member
  • *****
  • Karma: +229/-25
  • Offline Offline
  • Posts: 1389
  • Quality is addictive.
    • View Profile
Re: Current 1.7 changelog
« Reply #39 on: November 15, 2015, 03:30:05 pm »

Can we not just wait until MGW devs find a way to switch to prunable or to only use 32 bytes ?
Jean-Luc already offered to delay the new fee block; this can be done without delaying the other new features. He'd need to know how long for.

Increasing the maximum from 160 to 200 bytes might also be possible; Jean-Luc doesn't seem to want to, but I've not seen any rationale for why 160 bytes is the magic number here, rather than 128 or 256. Currently the vote seems to favour 2 NXT basic fee, so 200 bytes would cost 14 NXT. Of course, the next rounds of voting might push the cost up to 21 NXT or 28 NXT. That would provide SuperNet with some incentive to switch to prunable data, so after a while hopefully few transactions would actually be using the extra 40 bytes. Maybe the limit could be dropped again in a year's time, if nobody then needs it.
Logged
Pages: 1 [2] 3  All
 

elective-stereophonic
elective-stereophonic
assembly
assembly