Good technology appears simple to the end user... In reality what appears simple may not be...

This can be done, one approach is to design an integration to mobile money platforms and offer NEM as an add-on rather than an alternative...
This way you work with the Telco's not compete...

My humble opinion is you need something like a blockchain.info online wallet which can be accessed via SMS/USSD securely, a mobile money platform can hold the wallet-keys or a separate platform, I would think a telco agreeing to partner like this would run a NEM node along side its mobile money platform and take a stake.

There is also a lot of fraud around these systems (not technology) but spoof messaging which the Telco manages, people in these markets have very little money and if they don't trust you, they won't use you.

I know the concept of working with a telco (I am from one) will not sit well with some people but you won't get good enough security using these simpler protocols unless you can properly integrate with the network.

the speed of transaction processing is based on the availability of a processor, the time to get the transaction to it, the time to process and the time for the requestor to see the result.

I don't see how parallel block chains address any of these issues other than making reconciliation of accounts harder because transactions are spread across multiple chains...

EDIT: and I agree with BCNext, see earlier post, the faster you want the tx confirmed the higher the fee %age is a possible model but who pays the higher fee... the merchant wanting an instant confirmation or the buyer....?? both models exist

I disagree with the "big push away" I think there is a "big push to get it right".

From what I know the implementation of TF and Leased Forging is continuing, no one has said it hasn't, but no solution is ever perfect, there are always compromises and this thread is a good way for people to talk about what they see as consequences, if discussed they either are not material or they are and perhaps the solution can improve to address them.

In some cases like Instant Transactions, CFB started this process by asking for feedback on the proposed implementation before it was done...

I agree with Smaragda we have key things to complete like the AE, TF, Leased Forging and Instant Transactions + the Clients... This will allow NXT to evolve and gain some traction, more funky stuff can then be developed but there is no harm talking about it now as long as it doesn't distract us from delivering those core things.

There is a newsletter to help people understand current thinking, opinions, progress etc and I thought Apenzl always put in updates on key topics like AE, TF although I might be wrong.

You could make it simpler...

That hotdog will be 10 G's

If the smallest unit is 0.0001 then 1 G is 1000 milli Gs or a Grand

If course a 1000 G would then be a  1 Gee-Gee which could also be referred to as a Pony!

Sorry more computers and in particular more network bandwidth but not the stupid hardware growth that you see with bitcoin.

In my thinking there are two balances, - apologies if this is a bit long....

The Reserve Balance which is an amount of NXT you cannot withdraw and you can initiate instant transactions up to that level - this is a permanent reserve until cancelled.

The other balance is the Instant Balance which is updated as soon as an instant transaction is broadcast by a node i.e. 0 confirmations.
This reflects the liability the account has created with an instant transaction.
The node the transaction is broadcast through will have an realtime view of this because it will update the accounts instant balance before broadcasting the tx, all nodes seeing the TX will also update the instant balance for that account.
If the account tries to initiate more TX that would make Instant Balance > Reserve Balance this would create an error.

An attack vector such as you describe would rely on being able to send the TX through a node which had not yet updated its instant balance total for the account in question.

For instant transactions to work I would want to ensure that both accounts had to be connected to a node and both nodes had the same view of the instant transaction balance of the sending account. If the seller is logged into the buyer node then this is a possible edge case attack.

This means that the sellers account can confirm that there are sufficient reserved funds for the instant purchase because it also has a view of the buyers instant balance that it can verify with other nodes - this would be a possible client verification/check  during the purchasing process, the seller NRS node is passive in this process other than providing data to the sellers software client.

Even if the buyer switches nodes, the seller doesn't and the sellers node reconciles the instant balance of the sellers account using normal time line rules.... So unless the buyer can get the seller onto a node that doesn't know the buyers balance or initiate trades with lots of sellers which it knows are connected to nodes which won't get the instant balance update then an attack will fail ( I think)


Once the instant TX is confirmed the liability reduces and the instant balance can be reduced.

+12

Ok got you...
the 100 reserve I understand - this is the pre fund for instant TX
EDIT 2: the 24 hours is arbitrary and the reserve should be held permanently to cover instant TX liability up to that amount until the user cancels the instruction which cannot be done if they are any instant TX not fully confirmed.
EDIT: this is the maximum total liability they can create and they cannot withdraw the reserve balance.
I still don't understand the 1/10 if it were a limit per instant TX as further risk management, its stil arbitrary but I could understand it but I don't get it as a 24hr limit on the reserve - why is this?

1/x or definitely 10? - I just think users will think of an amount like 200, 500, 1000 nxt rather than 1/10 or 1/x, i should have expressed more clearly, I think the user should be able to specify the level of pocket money they need.... aka reserve balance

So the 1/10 reserve is arbitrary and with a different method like reserve balance the users could decide the level of reserve depending on how much 'pocket money' they would need.

Thanks, what do others think about this alternative method of 'pre-funding' instant transactions?

https://bitcointalk.org/index.php?topic=316104.msg5591145#msg5591145

Well you could use you MAC address as part of your secret phrase but I don't think thats what you mean

I recently changed accounts, took 1440 blocks to forge again, doesn't take long.

username / password only corresponds to match username+passwordhash on a system
most platforms focus on 8-10chars
if you know the username of someone you can brute force the 8-10
a 30+ semi-random-password takes a lot longer than 2 years

The information is in the thread on why this is not an issue for strong 30+ char passwords.
The clients will help users pick and store strong password.
Having only a strong password to protect your coins is true of all crypto's its just some clients hide this better.
Someone probably left that NXT in there as a joke or they are an idiot.

Anyone can run a cracker on anything - that doesn't mean it can be broken.
There is a variation called vanitygen to look for nice account numbers
Tries lots of passwords until it finds one that matches your parameters
I wanted a shorter account number which is the one in my signature so I wrote a script to find me one, 5 digits shorter than my original one.
People can easily write a cracker but will it work ? - read the posts on password length and entropy...
I read the other thread... its juvenile.

I'm sure someone has already calculated the hash for "Peanuts" which is account 11002691385236070570, put any NXT in that account, a bot will see the TX on the block chain and nick the NXT probably.

I've run 10m passwords through NRS to see if I can break it - didn't,  I did do it randomly to see if i could get a password collision.
I could have run a smarter cracker but I didn't see the point its not my job to find people who have used weak passwords.

Please help us me to understand - what is the reason for the 1/10 ratio? or is it completely arbitrary?

EDIT: Cfb - what about the reserve balance approach I posted in your other thread?

For next computation is not the issue but we cannot do much about data volumes... we can make the communication more efficient by compressing/turning it into binary, but once done then the more transactions you have the more data nodes need to exchange so N/W or network could become an issue. Its not an issue today we don't need nodes with huge pipes but in my experience the way you stop something like this being an issue or costing a lot to fix is to solve it when the system is small.

Also we talk about NXT (singular) and think about 1 node, there is value in thinking of it as a network and a sequence of nodes...

and me.... 

In my experience anything more than 10s is a problem.

To use your words 'Hell Yeah' this is the way I would try to do it... and it is about infrastructure if you consider this to be how NXT works as a whole, but its not about H/W or shouldn't be (other than N/W).

Yep - to log in to a node to make it forge NRS needs the secret.

But to validate an information request? or am I misunderstanding this use-case.

i wasn't thinking there were no cases where NRS needed the secret phrase.
but are there not some cases like this one where tokens would do and they are not being used?

PLEASE PLEASE

When you 'QUOTE'....

EDIT THE 'QUOTE' so it only shows what your reply is relevant too..

Please don't quote whole rivers of text.... dare i say 'this is lazy'  

It will make it a lot lot easier for all of us reading this thread to catch everything...

I'm sure people will forget from time to time but please try to do this.

Thanks