is there an exchange API call to give back assetID based on asset name?
No.
can we have one? please
Topic: NXT :: descendant of Bitcoin - Updated Information - page 1388. (Read 2761645 times)
No.
can we have one? please
NXT Newsletter
Letter will be here: http://nxter.org or use alias: nxter
Newsletter signup URL if anybody wants to embed it: http://eepurl.com/M2KnL
ALSO I am seeking donors. Or should I dare to mention the Unclaimed NXT fund?
Any amount is appreciated. It will cover registration, hosting, later possibly a faucet for new signups, translation, articles.
NXT Newsletter account is this: 7849037285621103550
Do you want to contribute to the NXT Newsletter? Join the discussion here: https://bitcointalksearch.org/topic/m.4638482
All contributing is voluntary. Do it for NXT, and maybe for the LAK too. It's just gonna love authors who write long articles
> CfB - u da man.
/apenzl
Letter will be here: http://nxter.org or use alias: nxter
Newsletter signup URL if anybody wants to embed it: http://eepurl.com/M2KnL
ALSO I am seeking donors. Or should I dare to mention the Unclaimed NXT fund?
Any amount is appreciated. It will cover registration, hosting, later possibly a faucet for new signups, translation, articles.
NXT Newsletter account is this: 7849037285621103550
Do you want to contribute to the NXT Newsletter? Join the discussion here: https://bitcointalksearch.org/topic/m.4638482
All contributing is voluntary. Do it for NXT, and maybe for the LAK too. It's just gonna love authors who write long articles
> CfB - u da man.
/apenzl
is there an exchange API call to give back assetID based on asset name?
No.
is there an exchange API call to give back assetID based on asset name?
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?
What is not working now?
Link http://blog.ethereum.org/?p=39/slasher-a-punitive-proof-of-stake-algorithm
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?
What is not working now?
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
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
weekend sell of on bter?
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?
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. 
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?
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.
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.
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.
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?
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.
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.
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.
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?
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.
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.
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?
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?
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".
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.
Jump to: