Topic: NXT :: descendant of Bitcoin - Updated Information - page 628. (Read 2761629 times)
I'm still lolling. My dog thinks I'm stupid. And I'm hodling.
But for simple transactions?
That's where we have to work out "trade offs".
IMO having lots of forks is not a great idea (a fork of > 2 rarely happens in Bitcoin).
Remember the "average Joe" going into a 7-11 to purchase a "can of soda" probably isn't even "capable" of trying to do a "double spend" so is it any more likely to occur than if they "slipped the soda can into their pocket"?
Not sure why what trade-offs exactly you are talking about.
--------------------------
Btw:
For the can of soda aka shopping, we would need a protocol like this:
1) Joe creates a transaction with the parameters specified by the supermarket. (in fact some nice credit card looking object will do)
2) Joe sends the transaction data to the supermarket and get the can in exchange
3) The supermarket would be eager to send that transaction to the network ASAP
4) => supermarket will even run its own node to secure their transactions.
If the transaction was send to a fork node, it can be resend over and over again until the supermarket get its money.
Something wrong with that?
Would Nxt be slower or faster?
Depends on topology.
What if we reduce the network to just hallmarked nodes all with high speed internet? What is the fastest practical time to get current reliability (just among the hallmarked nodes)?
It only helps the "hallmarked nodes" in "talking to each other" - it doesn't change the time it takes your own node (if you are a retailer for example) to talk to them.
So sure you could have those nodes probably do things much faster "between themselves" but still the "outsider" can't catch up.
So... more nodes ?
It doesn't *change* the *latency* to have more nodes.
The latency is due to the physical hardware of the internet itself and some of the software (in particular things like the GCF) that sit at the fairly low levels above that.
Adding "more hops" can actually only make things *slower*.
then What's the solution ?
Would Nxt be slower or faster?
Put it this way: 1 x 1 minute confirmation takes 1 minute and 6 x 10 second confirmations takes 1 minute.
Both are most likely about the same level of security.
I proposed a simpler method, but CIYAM said it was impossible.
Do you think using current method (without the random factor) we can simply reduce the time between blocks to 50 seconds? 30 seconds? 10 seconds?
James
Do you think using current method (without the random factor) we can simply reduce the time between blocks to 50 seconds? 30 seconds? 10 seconds?
James
We can reduce. But if u set gap between blocks to 10 sec then u'll need 6 times more confirmations to get the same reliability.
What if we reduce the network to just hallmarked nodes all with high speed internet? What is the fastest practical time to get current reliability (just among the hallmarked nodes)?
James
It doesn't *change* the *latency* to have more nodes.
The latency is due to the physical hardware of the internet itself and some of the software (in particular things like the GCF) that sit at the fairly low levels above that.
Adding "more hops" can actually only make things *slower*.
The latency is due to the physical hardware of the internet itself and some of the software (in particular things like the GCF) that sit at the fairly low levels above that.
Adding "more hops" can actually only make things *slower*.
GCF is good for developing schemes that will work in interplanetary environment... Let's thank the China govt.
I proposed a simpler method, but CIYAM said it was impossible.
Do you think using current method (without the random factor) we can simply reduce the time between blocks to 50 seconds? 30 seconds? 10 seconds?
James
Do you think using current method (without the random factor) we can simply reduce the time between blocks to 50 seconds? 30 seconds? 10 seconds?
James
We can reduce. But if u set gap between blocks to 10 sec then u'll need 6 times more confirmations to get the same reliability.
Would Nxt be slower or faster?
So... more nodes ?
It doesn't *change* the *latency* to have more nodes.
The latency is due to the physical hardware of the internet itself and some of the software (in particular things like the GCF) that sit at the fairly low levels above that.
Adding "more hops" can actually only make things *slower*.
I proposed a simpler method, but CIYAM said it was impossible.
Do you think using current method (without the random factor) we can simply reduce the time between blocks to 50 seconds? 30 seconds? 10 seconds?
James
Do you think using current method (without the random factor) we can simply reduce the time between blocks to 50 seconds? 30 seconds? 10 seconds?
James
We can reduce. But if u set gap between blocks to 10 sec then u'll need 6 times more confirmations to get the same reliability.
So... more nodes ?
But for simple transactions?
That's where we have to work out "trade offs".
IMO having lots of forks is not a great idea (a fork of > 2 rarely happens in Bitcoin).
Remember the "average Joe" going into a 7-11 to purchase a "can of soda" probably isn't even "capable" of trying to do a "double spend" so is it any more likely to occur than if they "slipped the soda can into their pocket"?
I am on board with you, too.
Sorry, but Yoda-talk is not helping at all.
As I said: people are actively reaching out here. So move a bit, too, BCNext.
I can understand if CfB is contractually obliged not to tell anything, but BCNext is reading this, too.
And I would like to appeal to change your way of wanting to go ahead by sharing more information with the people who are developing here.
I don't need this info myself, so even do it via PM if need be, but change!
It's a simple matter of changing your mind, because the circumstances have changed.
Sorry, but Yoda-talk is not helping at all.
As I said: people are actively reaching out here. So move a bit, too, BCNext.
I can understand if CfB is contractually obliged not to tell anything, but BCNext is reading this, too.
And I would like to appeal to change your way of wanting to go ahead by sharing more information with the people who are developing here.
I don't need this info myself, so even do it via PM if need be, but change!
It's a simple matter of changing your mind, because the circumstances have changed.
Could you describe the nature of these changes?
I am still very satisfied with the development.
The nature would be giving answers to developers who are obviously stuck when trying to figure out if the current TF will be the TF we will be dealing with in April.
There is much unclear about this, so I see developers asking questions whether or not things will be implemented or if they will be working with the current set of "rules".
If you operate under the assumption that "full" TF will be implemented in April and then you get an ambiguous message that says "you have to develop it yourselves, maybe" that creates an atmosphere were no one is certain of what to do anymore.
If then people ask clarification and all they get back is "maybe" or "you need to dig deeper" that doesn't help. A simple "yes" or "no" isn't that hard.
If you also get the message that BCNext is "disappointed" that would top it for me. You can't pronounce judgment without providing the parameters on which that judgement is based. That's like telling someone he failed a test without also telling him the system of scoring. It just makes people feel bad and at the same time you don't hand them the tools to work at it or to decide the actual judgement isn't even valid in the first place.
So basically what I am asking is for BCNext to abandon his policy of vagueness and just give clear answers if qualified people ask them.
I ask this not from my expertise in computers, but from my expertise as a group worker and out of concern. Several people have already expressed extreme frustration. This is something to take seriously, especially because these are people who have proven to be committed and not lazy.
Edit: I would like to add that CfB may be contractually obliged to not share. I do not know this. I am describing what I am seeing here and hoping it will be taken to heart. As said: all this vagueness comes at a huge cost. I add that it isn't needed.
We can reduce. But if u set gap between blocks to 10 sec then u'll need 6 times more confirmations to get the same reliability.
I understand that, when it comes to finding consensus, we should have at least a large number of blocks (1440) to trust the NXTs in someone's account.
But for simple transactions?
I can see the issue but I cannot tell you the answer - if I knew the answer I would be building it 
perhaps between us we will find it.
perhaps between us we will find it.Unfortunately there is no "easy answer" - basically retailers will still have to take "risks" on blockchain confirmations the same as they do when accepting credit cards (that could be stolen) or even cash (that could be fake).
Things like "green addresses" are a another possibility but once again end up being "centralised" ideas.
Personally I think the 1000+ TPS "hype" is pretty much just that (if we are talking about properly "secured" txs).
CfB, is this the case? Was this part of your contract with BCNext?
I know that Cunicula proposed to use ur scheme but BCNext went another way and there was a reason for that.
I'd love to hear his reasoning. Another example of bad communication.
I've flogged this horse enough. We all know about the smoke and mirrors involved at Nxt's core. We will overcome it. But the COST is large, and BCNext has NO RIGHT to express frustration at this community's inability to read his paranoid mind.
Thank god for the wiki. Otherwise we'd be nowhere.
Someone add Nxt to http://en.wikipedia.org/wiki/Cryptocurrency#Notable_cryptocurrencies
Jump to: