Topic: Start preparing for 1.7 - NOW! (Read 16038 times)

BTCDDev · « **Reply #20 on:** November 18, 2015, 09:41:15 pm »

Quote from: Thames on November 18, 2015, 09:24:54 pm

Quote from: BTCDDev on November 18, 2015, 08:59:00 pm
I have been very disturbed by the recent tone. Nxt changed the API with no advance notice and broke existing user applications right after the community donated $70,000 for increased attention on Nxt. They have to own that.

Please stop insinuating that developers of user applications are whiners. This is doing harm to Nxt, something I do not want to see.

In short, cut the drama.

Other than that, I'm looking forward to 1.7.
Apart from James related stuff, and i think coinomat, who else are we talking about, who felt entitled to be aggrieved with the API change?

Not sure I understand the question, why does it matter?

3rdStryker · « **Reply #21 on:** November 19, 2015, 05:11:39 am »

I agree with BTCDDev in every sense. Even if it was a small amount of applications you are thinking too one dimensional. You are eliminating the possibly for more applications to be built on NXT by changing the API so often. For the end user everything looks A OK. But for developers it is a big deal. How do you expect NXT to grow if no one wants to build on it? How do you expect NXT to grow if you are forcing the people who are currently working on it to move to another block chain?

For the record, SuperNet, Skynet (Finhive), drachmae and coinomat were all affected. I am sure there are more, but these 4 entities alone are working just as hard for NXT as the NXT core devs are so their voices should be heard.

Damelon · « **Reply #22 on:** November 19, 2015, 11:45:07 am »

Just want to put some of my observations in here, as experienced the last week.

As you know, Dave and I were asked to mediate in the dispute, and because we want NXT to flourish, we did.

We think it's vital that all voices are heard and that all concerns are taken aboard.

The situation we were confronted with was frankly almost impossible.

BOTH parties, and their support, just kept hammering on their own respective positions, and there was NO willingness to move even an inch.

Party one was insistent his position was best and party two insisted just the same, and no amount of talking on our part could persuade the other that giving some ground would help us get past the shitty situation we had gotten ourselves in and move on to the future where we would create protocols to make this less possible to happen.

Because that's what you do: if the jug is broken, you cannot put back the milk, but clean up and make sure it doesn't get broken again.

Meanwhile, things got even worse. Things got personal for no reason. Emotion began to overtake the whole process. Factions were forming that became even more entrenched in their positions.

Now I read some of these posts and am groaning out loud.

I have a newsflash: NXT is NOT a major corporation with a large amount of resources!

We are a grass roots group that has done an awesome job of making what we have, with resources that are laughably low!

Yes, in a perfect world all of these things would be possible, but as has been explained numerous times by the devs, without more resources (talking people here) they can only do so much.
I advise the hardliners on the issue of complete industry standard compliance to realise that we don't have the means to reach that standard yet!

On the other hand, I see the core devs apparently making arbitrary decisions that hurt a large partner. I deplore the hardness exhibited here and the fact that it doesn't seem to loom large in their conciousness.

From my end: both sides have an enormous part of blame in this whole situation.

My advice: get off your soapbox and TALK to eachother, knowing that a large part of this community is getting fed up with you sitting in your rooms not communicating directly. You are all grown-ups and taken responsibility for your respective projects. You have a responsibility and should man up and take it. Your investors and users want resolution.

Resolution does NOT mean forcing the other party to capitulate! It means working out a means to get a compromise. It means building trust and earning it. This also goes for both sides.

Compromise, be creative, think, put yourself in the others position.

For the supporters: quit fanning the fires. It's not helping your project. It's not helping yourself. This is not a contest. We are not ten year olds that need to "win". We are adults and can behave this way.

In the last two weeks, we got an agreement from both James and Jean Luc to go into a chat together. This never was done and I think they should ASAP.

Thames · « **Reply #23 on:** November 19, 2015, 12:34:59 pm »

Heres my view, and then i will STFU....

The claim that entities are 'working hard for NXT' is not only logically false, but its this kind of self-appointed importance that needs to stop.
Firstly, entities, will always have their own business/project self interests at the forefront of their motives, way before any meaningful considerations of its associated platform. By meaningful, i mean, what value does the current crop of crap on the AE, REALLY give to NXT? As ive said, currently 95% are worthless shit that does, and will do absolutely nothing, for the much needed broad ordinary user base, and business adoption that NXT needs to survive as a viable platform.
Secondly, Vitalik certainly doesnt need help from third party interests to 'work hard' for ETH. Quite rightly, people choosing ETH as a platform to work on, will do so for their own self-interest and motives. Microsoft aint getting involved to work for ETH, and i would be utterly amazed if their main consideration was based on how many times they believe an API was going to changed.

At some point, NXT will hopefully attract the interest of a company/business that has a turnover several magnitudes higher than the minnows on the AE and their associated operators/devs, and then the voices of those operators/devs should be ignored as being insignificant. Sorry if that sounds arrogant and misguided, but if Jean-Luc's inbox had 5 enquires on a given day, and one of them was from Microsoft or similar, who should he prioritise his attention to? Its just business. The kind of business NXT now needs, and hopefully, the kind of business the Tennessee project will produce. And, probably the kind of business that would have enough clout and relevance to nail any core devs bollocks to the mast, as far as future change is concerned, and it would be quite right for Jean-Luc to go out his way to accommodate a close working relationship. But that clout does not exist right now.
I dont personally consider James or anyone else to have the necessary clout, to feel entitled to influence Jean-Luc's roadmap, until those projects start behaving like REAL businesses that have meaningful and significant turnover, and that crosses over into real world use.

Seen the price of NXT and most of the assets lately? Tis a metric that tells me its time to move away from interesting and clever projects, cos the experiment aint working my friends. C'mon, lets start moving towards the end-game. Its getting tedious around here.

Cassius · « **Reply #24 on:** November 19, 2015, 12:49:11 pm »

This is a remarkably unhelpful post. Many of those involved in Nxt-related businesses are committed to the success of Nxt. Ask them if you disagree. They hold plenty of NXT as well as their own assets. Interests are aligned, as they should be and as they can be at this still-early point in Nxt's growth.

valarmg · « **Reply #25 on:** November 19, 2015, 01:05:49 pm »

Quote from: Thames on November 19, 2015, 12:34:59 pm

Heres my view, and then i will STFU....

The claim that entities are 'working hard for NXT' is not only logically false, but its this kind of self-appointed importance that needs to stop.
Firstly, entities, will always have their own business/project self interests at the forefront of their motives, way before any meaningful considerations of its associated platform. By meaningful, i mean, what value does the current crop of crap on the AE, REALLY give to NXT? As ive said, currently 95% are worthless shit that does, and will do absolutely nothing, for the much needed broad ordinary user base, and business adoption that NXT needs to survive as a viable platform.
Secondly, Vitalik certainly doesnt need help from third party interests to 'work hard' for ETH. Quite rightly, people choosing ETH as a platform to work on, will do so for their own self-interest and motives. Microsoft aint getting involved to work for ETH, and i would be utterly amazed if their main consideration was based on how many times they believe an API was going to changed.

At some point, NXT will hopefully attract the interest of a company/business that has a turnover several magnitudes higher than the minnows on the AE and their associated operators/devs, and then the voices of those operators/devs should be ignored as being insignificant. Sorry if that sounds arrogant and misguided, but if Jean-Luc's inbox had 5 enquires on a given day, and one of them was from Microsoft or similar, who should he prioritise his attention to? Its just business. The kind of business NXT now needs, and hopefully, the kind of business the Tennessee project will produce. And, probably the kind of business that would have enough clout and relevance to nail any core devs bollocks to the mast, as far as future change is concerned, and it would be quite right for Jean-Luc to go out his way to accommodate a close working relationship. But that clout does not exist right now.
I dont personally consider James or anyone else to have the necessary clout, to feel entitled to influence Jean-Luc's roadmap, until those projects start behaving like REAL businesses that have meaningful and significant turnover, and that crosses over into real world use.

Seen the price of NXT and most of the assets lately? Tis a metric that tells me its time to move away from interesting and clever projects, cos the experiment aint working my friends. C'mon, lets start moving towards the end-game. Its getting tedious around here.

Yes, forget about everyone who is working hard on the Nxt platform right now because they are not that important. Wait for a Microsoft to magically decide to start using Nxt. (Remember how great getting OverStock worked out for Counterparty. Of course, possibly the devs wouldn't listen to any big fish either.) If any of the small projects did become big and real-world, well by then they'll likely have moved away from using Nxt the way things are going.

wesley · « **Reply #26 on:** November 19, 2015, 01:20:46 pm »

It seems to me the maximum is being done to make the changes as easy for developers as possible. Switching to calculated fees couldn't be easier (just set feeNQT to 0). They've even added a configuration property in nxt.properties that allows you not to change any code at all, if set will simply ignore invalid (too low) fees and use the minimum fee instead.

Same for pruned messages, configuration options have been added so that all pruned data can be stored indefinitely. And prunable messages have been available since april or something. The issue some third party developers have seems to be about the feature itself, not about the API design in this case.

chanc3r · « **Reply #27 on:** November 19, 2015, 01:50:46 pm »

How the tone of this thread changed, maybe I unfortunately contributed...

I saw no drama, I saw no one being accused of whining.
The NXT team have admitted that 1.6.2 changes could have been publicised better.
I'admit that if I'd read the 1.6.1e release notes (admittedly) a lot more carefully I would have picked up the changes, it was there but not in big red letters hopefully in the future it will be.

This is why there is so much being posted about 1.7
A lot has been done to enable people to prepare for 1.7 now before its even live and offers have been made to have more than one fork to introduce new features and give people more time to prepare.

I have only seen 2 specific issues posted, one has been resolved already by J-L, the other is more difficult issue.

It is unfortunate that there is still a disagreement with James and J-L on a permanent message change that impacts MGW but this does not need to magnify into general argument between users of the NXT platform and its core developers.

So perhaps we can use this thread as intended to post and discuss specific issues people have with preparing for the changes in 1.7 around fees and limits and let the specific MGW issue take its own path.

Brangdon · « **Reply #28 on:** November 19, 2015, 08:47:02 pm »

Quote from: 3rdStryker on November 18, 2015, 04:10:25 pm

Will there be a point in the not so distant future when the NXT devs will implement a stable API?

I gather that's the intention for 1.7. I believe Jean-Luc said there were no more backwards compatibility changes planned for the foreseeable future.

chanc3r · « **Reply #29 on:** November 19, 2015, 10:56:14 pm »

@J-L - I have a question about prunable messages - forgive me I may use the wrong terms...

If I download a block containing a transaction with a permanent message, I can trust the contents of the message returned by the API call as the message is part of the block and therefore someone can't try to fake the message.

If the message is prunable then when its pruned its no longer part of the block or is it? So if I set my node to download the pruned data - does my node automatically verify that the pruned messages it receives from an archival node are the ones that were originally pruned from the block?

I am trying to work out whether I can rely on anonymous public archival nodes, whether I need to use a 'known' public or my own archival node... what verification of pruned data NXT does for me and whether I need to include specific verification that a pruned item was the one that was originally in the block e.g. by comparing hashes...

I hope the question is clear, yes I'm being paranoid that someone might try to set up a bad archival node..

Cassius · « **Reply #30 on:** November 20, 2015, 09:57:18 am »

Quote from: Brangdon on November 19, 2015, 08:47:02 pm

Quote from: 3rdStryker on November 18, 2015, 04:10:25 pm
Will there be a point in the not so distant future when the NXT devs will implement a stable API?
I gather that's the intention for 1.7. I believe Jean-Luc said there were no more backwards compatibility changes planned for the foreseeable future.

Not to labour the point for reasons that should be obvious, but can someone confirm this or point me to the latest statement on this from the core devs?

Jean-Luc · « **Reply #31 on:** November 20, 2015, 10:34:30 am »

Quote from: chanc3r on November 19, 2015, 10:56:14 pm

If the message is prunable then when its pruned its no longer part of the block or is it? So if I set my node to download the pruned data - does my node automatically verify that the pruned messages it receives from an archival node are the ones that were originally pruned from the block?

The prunable message is never actually a part of the transaction bytes that are being signed and stored in the transaction table, only a sha256 hash of it is included in the transaction bytes. When restoring, the transaction JSON received from the archival node is parsed, the transaction signature verified, and in that process the fact that the prunable part included in that JSON gives the same hash is also verified. You will get an error like this if the archival node tried to modify the pruned message:

Code: [Select]

2015-11-20 01:45:37 SEVERE: Peer 178.162.198.109 returned invalid prunable transaction
nxt.NxtException$NotValidException: Invalid transaction signature for transaction {"senderPublicKey":"b978af7a6ea8e1bff4df6080703d5750604b2a5ebe90c5011e37e2a89e220152","signature":"55bb1e4838269aad9d484ec2f526163206b86ceda8f279156c8cd65b966f1d04786c7ede96df8961b2b95364f3019926eaf6f0c4b57fed2c0a293ab064bf044a","feeNQT":100000000,"type":1,"version":1,"ecBlockId":"2306000649502458297","attachment":{"version.PrunablePlainMessage":1,"messageIsText":true,"messageHash":"5db6a9f46e3830fcad98cf9607fa3cf6cae9736998e202df64002d4c51d158c4","message":"test plain prunable messagV","version.ArbitraryMessage":0},"subtype":0,"amountNQT":0,"recipient":"11274269400387066343","ecBlockHeight":497932,"deadline":1440,"timestamp":62590768}
	at nxt.TransactionImpl.parseTransaction(TransactionImpl.java:814)
	at nxt.TransactionProcessorImpl.restorePrunableData(TransactionProcessorImpl.java:769)
	at nxt.BlockchainProcessorImpl$RestorePrunableDataTask.run(BlockchainProcessorImpl.java:905)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)

Note that the archival nodes don't need to have their API open to the public, retrieval of pruned data is done on the peer to peer network (port 7874).

allwelder · « **Reply #32 on:** November 20, 2015, 11:42:05 am »

Whether we should we think more about the coin shuffle feature before release?
It's better from a third party service provider.

"Interior and justice ministers from the European Union have organized a crisis meeting this Friday to plan an effective crackdown of anonymous payment method and virtual currencies to curb terrorism funding."
https://www.cryptocoinsnews.com/breaking-european-union-crisis-meeting-planned-to-call-for-control-of-virtual-currencies-after-paris-attacks/

Brangdon · « **Reply #33 on:** November 20, 2015, 09:38:03 pm »

Quote from: Cassius on November 20, 2015, 09:57:18 am

Quote from: Brangdon on November 19, 2015, 08:47:02 pm
I believe Jean-Luc said there were no more backwards compatibility changes planned for the foreseeable future.

Not to labour the point for reasons that should be obvious, but can someone confirm this or point me to the latest statement on this from the core devs?

https://nxtforum.org/general-discussion/protocol-for-new-feature-implementation-and-significant-changes-in-nxt-core/msg200264/#msg200264 "Should also note that we don't have any plans for incompatible API changes in the near future."
https://nxtforum.org/nrs-releases/nrs-v1-6-2/msg199422/#msg199422 "Nxt will therefore have have a stable API for at least the next 3-6 months, probably longer"
Page 43 of https://drive.google.com/file/d/0B4OEA-peIYHXd3JOTUY4VndQLW8/view "we don't plan more API changes soon at all"

chanc3r · « **Reply #34 on:** November 20, 2015, 10:13:17 pm »

Quote from: Jean-Luc on November 20, 2015, 10:34:30 am

The prunable message is never actually a part of the transaction bytes that are being signed and stored in the transaction table, only a sha256 hash of it is included in the transaction bytes. When restoring, the transaction JSON received from the archival node is parsed, the transaction signature verified, and in that process the fact that the prunable part included in that JSON gives the same hash is also verified. You will get an error like this if the archival node tried to modify the pruned message:

J-L one last clarification - does this mean prunable and permanent messages are stored differently? i.e. permanent messages AE stored in the transaction table?

Jean-Luc · « **Reply #35 on:** November 21, 2015, 07:18:32 am »

Yes, they are stored differently. Transaction attachment are stored as byte array in a column in the transaction table, this byte array representing exactly the bytes that are being signed. The prunable messages, tagged data, and shuffling processing data, are not part of those bytes (only their hashes are), and they are stored in a separate table which makes pruning (and restoring) easier. For almost all attachments, derived objects are also created in separate tables, so that the bytes in the attachment column don't need to be parsed again. Currently this is not done for permanent message.

The details of what is stored where can change at any time because it is a matter of implementation, no one should assume the database schema will stay unchanged.

chanc3r · « **Reply #36 on:** November 21, 2015, 10:02:07 am »

Thanks J-L that was useful, sorry then it brings up one more...

Message attachments in asset transfers can be permanent also - yes?

So does this mean they are stored in the attachment table also, whether prunable or not, because the transaction itself uses up the transaction bytes?

Jean-Luc · « **Reply #37 on:** November 21, 2015, 10:05:35 am »

Quote from: chanc3r on November 21, 2015, 10:02:07 am

Message attachments in asset transfers can be permanent also - yes?

Yes, it does not matter what transaction type a message is attached to.

Quote

So does this mean they are stored in the attachment table also, whether prunable or not, because the transaction itself uses up the transaction bytes?

No, if prunable they are not stored in the transaction table, never.

Switch to ArdorForum

News:

Author Topic: Start preparing for 1.7 - NOW! (Read 16038 times)

BTCDDev

Re: Start preparing for 1.7 - NOW!

3rdStryker

Re: Start preparing for 1.7 - NOW!

Damelon

Re: Start preparing for 1.7 - NOW!

Thames

Re: Start preparing for 1.7 - NOW!

Cassius

Re: Start preparing for 1.7 - NOW!

valarmg

Re: Start preparing for 1.7 - NOW!

wesley

Re: Start preparing for 1.7 - NOW!

chanc3r

Re: Start preparing for 1.7 - NOW!

Brangdon

Re: Start preparing for 1.7 - NOW!

chanc3r

Re: Start preparing for 1.7 - NOW!

Cassius

Re: Start preparing for 1.7 - NOW!

Jean-Luc

Re: Start preparing for 1.7 - NOW!

allwelder

Re: Start preparing for 1.7 - NOW!

Brangdon

Re: Start preparing for 1.7 - NOW!

chanc3r

Re: Start preparing for 1.7 - NOW!

Jean-Luc

Re: Start preparing for 1.7 - NOW!

chanc3r

Re: Start preparing for 1.7 - NOW!

Jean-Luc

Re: Start preparing for 1.7 - NOW!