Topic: NXT :: descendant of Bitcoin - Updated Information - page 157. (Read 2761645 times)
CfB, I think i missed the post, but is it true that you stay longer than 4.4.2014?
I was planning on staying to keep Emule company in the dark.
how nice of you. shall we dump some toghetter?
I hope u both don't mind against a trio?
Hey cfb why haven't I seen you yet in the other pub thread:
http://nxtforum.org/index.php?topic=91.0
I was planning on staying to keep Emule company in the dark.
how nice of you. shall we dump some toghetter?
I hope u both don't mind against a trio?
How can I create the most accurate NXT network health metric?
Ask guys from Infrastructure committee, they know some tricks.
I thought you guys had moved to the new thread.
Do u always go to the same pub? I prefer to visit them all during a night.
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.
how nice of you. shall we dump some toghetter?
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.
In any thread that is relevant to the question
CfB is on the forum, too.
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 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 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.
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.
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.
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.
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 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. Anyway, what should I do if I detect a collision of identical GUIDs?
U should publish that u found a collision in SHA256.
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.
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
Anyway, what should I do if I detect a collision of identical GUIDs?
U should publish that u found a collision in SHA256.
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.
Anyway, what should I do if I detect a collision of identical GUIDs?
U should publish that u found a collision in SHA256.
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.
Anyway, what should I do if I detect a collision of identical GUIDs?
U should publish that u found a collision in SHA256.
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
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!
Jump to: