NXT :: descendant of Bitcoin - Updated Information

[Come-from-Beyond]

now all them cheerleaders, fantasts and pumpers are gone can we go back to basics of nxt thank you

Sure. So u was going to dump 100M NXT... What's next?

[bitcoinpaul]

SSL is needed on the new Nxt forum immediately! Rickyjames stop spamming this thread. Do not close this thread, keep it open for reference.

Get SSL on nxtforum.org because every single person registering or logging in over there now is risking their passwords to plain text http transmission.

Sincerely,
Brian Snyder

I don't think this thread will be closed. And Ricky stopped a while ago posting it.

SSL is in the works right now.

[Damelon]

now all them cheerleaders, fantasts and pumpers are gone can we go back to basics of nxt thank you

I'm taking you with us!

[Emule]

[BitcoinForumator]

I see you're into BDSM.

[bitcoinpaul]

I'm glad we have a new forum. BTT just sucks right now by not showing images.

[Emill]

Guy's not sure if you had a secret vote to leave but i wish you good luck. It's been like keeping up with Breaking Bad using hand bags instead of guns. Very enjoyable reading and i will miss the episodes. 

[wesleyh]

Guy's not sure if you had a secret vote to leave but i wish you good luck. It's been like keeping up with Breaking Bad using hand bags instead of guns. Very enjoyable reading and i will miss the episodes. 

There is a pub thread at the new forum too: http://nxtforum.org/index.php?topic=91.0 - come join!

[jl777]

Anyway, what should I do if I detect a collision of identical GUIDs?

U should publish that u found a collision in SHA256.

I thought the issue is that it is possible to double spend by having txidA and evil txidB that are the same tx and both have the same SHA256 because Evil Bob modified txidA and resubmitted it as txidB. Both having the same SHA256 would indicate that it is the same tx (or super rare actual SHA256 collision)

I am getting totally confused about this issue. Partly because I dont know what info is in the rawtransaction bytes. If the txid is in there, then SHA256 of an evil copy wont match, so there is no need to do any checking.

jean-luc says NXT core ensures txids can be trusted, so doesnt that mean that I dont have to worry about this as a caller of NXT API. If all txids are ensured to be unique and having different SHA256, then why do I need to do any calculations from scratch or even both checking for unique SHA256 at all?

What exactly is the attack vector if I am tracking transactions by txid and totally ignoring SHA256 "hash" field?

James

[Come-from-Beyond]

Anyway, what should I do if I detect a collision of identical GUIDs?

U should publish that u found a collision in SHA256.

I thought the issue is that it is possible to double spend by having txidA and evil txidB that are the same tx and both have the same SHA256 because Evil Bob modified txidA and resubmitted it as txidB. Both having the same SHA256 would indicate that it is the same tx (or super rare actual SHA256 collision)

I am getting totally confused about this issue. Partly because I dont know what info is in the rawtransaction bytes. If the txid is in there, then SHA256 of an evil copy wont match, so there is no need to do any checking.

jean-luc says NXT core ensures txids can be trusted, so doesnt that mean that I dont have to worry about this as a caller of NXT API. If all txids are ensured to be unique and having different SHA256, then why do I need to do any calculations from scratch or even both checking for unique SHA256 at all?

What exactly is the attack vector if I am tracking transactions by txid and totally ignoring SHA256 "hash" field?

James

If u rely on confirmations then use tx id only.

[windjc]

Anyway, what should I do if I detect a collision of identical GUIDs?

U should publish that u found a collision in SHA256.

I thought the issue is that it is possible to double spend by having txidA and evil txidB that are the same tx and both have the same SHA256 because Evil Bob modified txidA and resubmitted it as txidB. Both having the same SHA256 would indicate that it is the same tx (or super rare actual SHA256 collision)

I am getting totally confused about this issue. Partly because I dont know what info is in the rawtransaction bytes. If the txid is in there, then SHA256 of an evil copy wont match, so there is no need to do any checking.

jean-luc says NXT core ensures txids can be trusted, so doesnt that mean that I dont have to worry about this as a caller of NXT API. If all txids are ensured to be unique and having different SHA256, then why do I need to do any calculations from scratch or even both checking for unique SHA256 at all?

What exactly is the attack vector if I am tracking transactions by txid and totally ignoring SHA256 "hash" field?

James

If u rely on confirmations then use tx id only.

I thought you guys had moved to the new thread.

[jl777]

Anyway, what should I do if I detect a collision of identical GUIDs?

U should publish that u found a collision in SHA256.

I thought the issue is that it is possible to double spend by having txidA and evil txidB that are the same tx and both have the same SHA256 because Evil Bob modified txidA and resubmitted it as txidB. Both having the same SHA256 would indicate that it is the same tx (or super rare actual SHA256 collision)

I am getting totally confused about this issue. Partly because I dont know what info is in the rawtransaction bytes. If the txid is in there, then SHA256 of an evil copy wont match, so there is no need to do any checking.

jean-luc says NXT core ensures txids can be trusted, so doesnt that mean that I dont have to worry about this as a caller of NXT API. If all txids are ensured to be unique and having different SHA256, then why do I need to do any calculations from scratch or even both checking for unique SHA256 at all?

What exactly is the attack vector if I am tracking transactions by txid and totally ignoring SHA256 "hash" field?

James

If u rely on confirmations then use tx id only.

Great! Thinks are complicated enough as it is.

How can I create the most accurate NXT network health metric? I want to get some probabilistic sense of whether we are on a fork or not.

Is it as simple as latest block and comparing it globally? Assuming there are three different blocks reported, each with its percentage of overall, then if the block your node is on would have the same chance as the global percentage?

For example if the following is reported globally:
block A) 75%
block B) 20%
block C) 5%

Then, anybody not on blockA would be on a fork? To make it better, would need to have current block and previous block so that we can filter out people who are lagging a bit, but you get the idea. Will this be somewhat effective? What other data can I use to make a better predictor. I would like to be able to dynamically adapt the number of confirmations needed.

If 100% of the nodes are reporting the same current block and previous block, then is there any need to wait for any more confirmations?

James

[jl777]

I thought you guys had moved to the new thread.

I dont remember agreeing to moving. It is easier for me to follow a linear thread.

[BitcoinForumator]

I thought you guys had moved to the new thread.

I dont remember agreeing to moving. It is easier for me to follow a linear thread.

I can see people coming back really quickly.

[xyzzyx]

I thought you guys had moved to the new thread.

I dont remember agreeing to moving. It is easier for me to follow a linear thread.

I can see people coming back really quickly.

I was planning on staying to keep Emule company in the dark.

[windjc]

I thought you guys had moved to the new thread.

I dont remember agreeing to moving. It is easier for me to follow a linear thread.

Maybe you did not agree to move, but if you and CFB don't move, others are not going to move either.

[windjc]

I thought you guys had moved to the new thread.

I dont remember agreeing to moving. It is easier for me to follow a linear thread.

I can see people coming back really quickly.

Well of course. If the core components of this thread do not cooperate in the move. That's common sense. But moving is a good idea as this thread is not the most efficient and effective way of communication and promotion, EVEN if its currently the most COMFORTABLE.

[Eadeqa]

I thought you guys had moved to the new thread.

I dont remember agreeing to moving. It is easier for me to follow a linear thread.

Maybe you did not agree to move, but if you and CFB don't move, others are not going to move either.

It doesn't have to be either this or that. You can still build that forum while this thread is alive. BT has a lot more traffic and new people  come and see this thread.

[BitcoinForumator]

I thought you guys had moved to the new thread.

I dont remember agreeing to moving. It is easier for me to follow a linear thread.

You have the option of the long&single thread there too.

[jl777]

I thought you guys had moved to the new thread.

I dont remember agreeing to moving. It is easier for me to follow a linear thread.

You have the option of the long&single thread there too.

I will post multigateway status over there, but ask tech questions here as I have no idea where I am supposed to post questions to CfB on the forum