NXT :: descendant of Bitcoin - Updated Information

[Alias]

Has anyone seen this - http://blog.ethereum.org/?p=39/slasher-a-punitive-proof-of-stake-algorithm? I don't think it is hugely relevant to us but an interesting read none the less.

[1714222872]

1714222872

[pandaisftw]

This is what the blockchain about.

Right, but it wouldn't be updated "instantly" for C or D to check, there is still a block time of 1 minute.

Read https://bitcointalk.org/index.php?topic=316104.0

Account A makes his account special.

He now has 10 NXT in instant balance.

What's stopping him from sending 10 NXT to both peer B and C as payment if they are not connected? I mean sure, it could be prevented at the next block, but that isn't instant.

B and C would both send the goods to account A instantly and then get screwed 1 minute later when they find out it was a doublespend.

If you have 100 NXT in your account, that means you have 10 NXT for "instant transactions". In order for you to "double-spend" (literally to spend 200 NXT, so 10 NXT * 20 times), you would have to fool all the peers on the network 20 times. Chance of that is so low, in most cases you will just end up paying the merchant multiple times

In the scenario of A sending to unconnected B and C, because he has 100 NXT in his account, he ends up sending 10 NXT to B and 10 NXT to C, no ripoff there.

EDIT: Also, I'm not sure if the balance is updated instantly (can malicious attacker ignore this?), but if so, in this case it would be 10 NXT to B and 9 NXT to C, and as n -> infinity, eventually 0, but never past zero.

[Come-from-Beyond]

Taking this to the logical extreme, what if he sends it to 11 merchants, and gets 110 NXT worth of product instantly? This approach is good but not airtight.

Chance that all 10 merchants r isolated from Nxt network is below zero, I think.

[coolmist]

If you have 100 NXT in your account, that means you have 10 NXT for "instant transactions". In order for you to "double-spend" (literally to spend 200 NXT, so 10 NXT * 20 times), you would have to fool all the peers on the network 20 times. Chance of that is so low, in most cases you will just end up paying the merchant multiple times

In the scenario of A sending to unconnected B and C, because he has 100 NXT in his account, he ends up sending 10 NXT to B and 10 NXT to C, no ripoff there.

You would have to fool all the (20) peers on the network 1 time.

They are "instant" transactions, peers don't have time to communicate that quickly relative to an automated doublespend attempt.

Chance that all 10 merchants r isolated from Nxt network is below zero, I think.

Chance of peers being isolated is below zero, but the chance of all peers being able to communicate with all other peers to prevent double spend is even lower than that. Plus, the doublespender has a one minute window with BCNext's proposed method, his balance would have to be updated in the blockchain for doublespends to be prevented.

[Come-from-Beyond]

Has anyone seen this - http://blog.ethereum.org/?p=39/slasher-a-punitive-proof-of-stake-algorithm? I don't think it is hugely relevant to us but an interesting read none the less.

Aye, interesting. But it looks quite complex comparing to Nxt PoS algo. It doesn't make sense to use something more sophisticated, only due to political reasons.

[Come-from-Beyond]

Chance of peers being isolated is below zero, but the chance of all peers being able to communicate with all other peers to prevent double spend is even lower than that. Plus, the doublespender has a one minute window with BCNext's proposed method, his balance would have to be updated in the blockchain for doublespends to be prevented.

Don't read "instant" literally. A merchant will give purchased goods only after sending the transaction to next generator. The other 10 merchants will do the same and they'll get a reply that their transactions r illegal. This will take 3-5 sec.

[coolmist]

Don't read "instant" literally. A merchant will give purchased goods only after sending the transaction to next generator. The other 10 merchants will do the same and they'll get a reply that their transactions r illegal. This will take 3-5 sec.

Ok, this makes sense. But won't this will lead to a massive amount of data being sent to one peer (the forging account)? This would also cause the next forging account to do a massive amount of work, even if the work is distributed across multiple future predicted forging accounts.

[Passion_ltc]

nxtion.com update


....

Wow that is really exciting!
You could basically secure accounts on websites now by linking them to your Nxt-Account.
If your data gets compromised you can verify the rightful ownership.

@How does this token thing actually work?
Some information on that?

Yes. The token system is like a 1.5 factor auth.

nxtion.com update


...

I like how you constantly keep working to make your services as accessible as possible.

Thank you. I'm working hard for that!

Why do u ask for Nxt ID? Token already contains the ID.

You are right, sir! I will change it later.

[Come-from-Beyond]

Don't read "instant" literally. A merchant will give purchased goods only after sending the transaction to next generator. The other 10 merchants will do the same and they'll get a reply that their transactions r illegal. This will take 3-5 sec.

Ok, this makes sense. But won't this will lead to a massive amount of data being sent to one peer (the forging account)? This would also cause the next forging account to do a massive amount of work, even if the work is distributed across multiple future predicted forging accounts.

1000 tps require only 1 Mbps bandwidth. I wouldn't say it's "massive".

[l8orre]

hmmm -- the only way of obtaining the information that s.t. has happend is by polling the NRS - it does not operate in push mode. So The less often I poll, the less I know.

I have not been trying to load test - 1 second just seemd like something reasonable. Besides, someone from the GUI devs also recommended 1 second.

What would you use?

What's "s.t."? I just can't think of anything so critical that it needs to arrive with 1 second precision.

s.t. just lazy for 'something' ---

Yes, but still - there MUST be a defining event to poll the NRS. Either it is a user input click 'poll' , or it is an external event. incoming message from other source, OR a periodical poll.

In which case you are stuck with the decision: what frequency? why not 100 milliseconds? why not 100 seconds? again, one of the other devs mentioned 1 second, which wihtin a human window of attention span is 'instant'.

what would you use?

[coolmist]

Don't read "instant" literally. A merchant will give purchased goods only after sending the transaction to next generator. The other 10 merchants will do the same and they'll get a reply that their transactions r illegal. This will take 3-5 sec.

Ok, this makes sense. But won't this will lead to a massive amount of data being sent to one peer (the forging account)? This would also cause the next forging account to do a massive amount of work, even if the work is distributed across multiple future predicted forging accounts.

1000 tps require only 1 Mbps bandwidth. I wouldn't say it's "massive".

True, the data amount isn't massive, however the amount of work that has to be done by the computer verifying the instant transactions has to be huge, right?

In one five second interval it has to receive data from 5k different peers, store this data, check the validity of each transaction and rebroadcast this out to 5k more peers.

[NxtChg]

In which case you are stuck with the decision: what frequency? why not 100 milliseconds? why not 100 seconds? again, one of the other devs mentioned 1 second, which wihtin a human window of attention span is 'instant'.

what would you use?

It's possible that API will change in the future to something like websockets so you could push clients.

For now, I would use something like 20-30 seconds: blocks are generated with no less than 1 minute interval, so no reason to pull more often.

If you need to display peer info it can be somewhat less, like 5-10 seconds. But one second is overkill.

[Come-from-Beyond]

True, the data amount isn't massive, however the amount of work that has to be done by the computer verifying the instant transactions has to be huge, right?

In one five second interval it has to receive data from 5k different peers, store this data, check the validity of each transaction and rebroadcast this out to 5k more peers.

My notebook can validate 100k transactions per second. Still too far from massive.

[l8orre]

In which case you are stuck with the decision: what frequency? why not 100 milliseconds? why not 100 seconds? again, one of the other devs mentioned 1 second, which wihtin a human window of attention span is 'instant'.

what would you use?

It's possible that API will change in the future to something like websockets so you could push clients.

For now, I would use something like 20-30 seconds: blocks are generated with no less than 1 minute interval, so no reason to pull more often.

If you need to display peer info it can be somewhat less, like 5-10 seconds. But one second is overkill.

thanks for the input. the block generation time argument is good. currently, I use 5 seconds on my raspi, that it can handle. The testnet server appears to have some real clout - I tried with 500ms, no problem.

I have not tested my samsung s3 laptop yet.

[pandaisftw]

If you have 100 NXT in your account, that means you have 10 NXT for "instant transactions". In order for you to "double-spend" (literally to spend 200 NXT, so 10 NXT * 20 times), you would have to fool all the peers on the network 20 times. Chance of that is so low, in most cases you will just end up paying the merchant multiple times

In the scenario of A sending to unconnected B and C, because he has 100 NXT in his account, he ends up sending 10 NXT to B and 10 NXT to C, no ripoff there.

You would have to fool all the (20) peers on the network 1 time.

They are "instant" transactions, peers don't have time to communicate that quickly relative to an automated doublespend attempt.

Chance that all 10 merchants r isolated from Nxt network is below zero, I think.

Chance of peers being isolated is below zero, but the chance of all peers being able to communicate with all other peers to prevent double spend is even lower than that. Plus, the doublespender has a one minute window with BCNext's proposed method, his balance would have to be updated in the blockchain for doublespends to be prevented.

Hm... my example was wrong.

Sorry if someone mentioned this before, but if the merchant receives an instant transaction from the special account, it can broadcast it to the network (connected peers) to check to see if this account has already sent this type of special transaction in the last minute. Those peers will then rebroadcast this request, and so on. If a match is found, then the peer who has a match will send this information back to the merchant. Assuming a latency of 200ms, this request can be rebroadcast 5 times in 1 second. So if the merchant is connect to 10 peers, each who is connected to 10 peers, etc. then the network can quickly check 100,000 peers in 1 second. Not to mention, some hallmarked nodes have thousands of peers, so this number can be exponentially larger.

If a match is found, then the merchant can just say, "sorry, you already sent an instant transaction in the last minute, please wait wait one minute for confirmation." So time is not an issue unless the merchant is completely isolated (which is nearly impossible). Most humans will never need to place a large number of small orders in a span of 1 minute from multiple sources, so this is not a limitation. If they really need to, then it makes more sense to use their normal account (with 100% spendable funds), and just wait 1 minute for the confirmation. Instant transactions are useful for things like grocery shopping, I suppose. You're not going to checkout 100 times in a minute.

[klee]

This analysis ignores opportunity cost. When opportunity costs are taken into consideration, owning 1million coins is no more beneficial than owing 1 coin. Except for the sense in which being wealthy is, in general, better than the alternative.

Thanks everyone for their replies!
I find the  'dialogue' really interesting - I encouraged him to post here too.
He is a good guy, no need to be impolite if he chimes in

@Anon - can you elaborate some more on this please?

[coolmist]

My notebook can validate 100k transactions per second. Still too far from massive.

I don't doubt it, I was just really curious as to how it all worked  . Thanks for taking time to explain.

[BitAddict]

Has anyone seen this - http://blog.ethereum.org/?p=39/slasher-a-punitive-proof-of-stake-algorithm? I don't think it is hugely relevant to us but an interesting read none the less.

Aye, interesting. But it looks quite complex comparing to Nxt PoS algo. It doesn't make sense to use something more sophisticated, only due to political reasons.

Is not working now? 

[pinarello]

weekend sell of on bter?

[jl777]

For anybody expecting social security (usa), i have some bad news
It turns out that frictionlesscoin might actually have worked for them. He admits he is carlos in the other thread, carlos has resume including work for social security

James