Maybe this: 1LLe2He9k8r8WnAnuXJbAUedX8c2HCr8bQ 
Yes, thank u.
Money is still there, it's good.
Topic: NXT :: descendant of Bitcoin - Updated Information - page 1260. (Read 2761629 times)
Yes, thank u.
Money is still there, it's good.
So we can protect from any corruption on the way from core to client by adding new addresses.
Otherwise if something goes wrong, and a wrong address gets to the client, the new addresses won't save the user.
Otherwise if something goes wrong, and a wrong address gets to the client, the new addresses won't save the user.
Signature would be invalidated in case of corruption.
But in any other case, how could Big Brother possibly add your "more info" if all transaction in the past are fulfilled?
Imagine that weight of a real (weight = 100%) link between IN and OUT is 5% (that's how Big Brother sees it). U use this OUT to buy something from a website that is later seized by BB. Now he knows one of ur real IPs, this increases that link weight from 5% to 12%.
Even worse, some other guy reveals his real transactions, this automatically increases weights of all the other links involved into the same mixing session.
And the other thing: what's the issue with the 'joincoin approach'? I.e. if n senders sends 5Nxts then n receiver receives 5Nxts. So, nobody could differentiate who exactly transferred whom 5Nxt. They send collectively n*5 Nxts and they receive collectively n*5 Nxts.
"nobody could differentiate who exactly transferred whom 5Nxt" is correct, but actually some non-zero probability is enough to use approach described above to deanonymize u.
Why not zerocoin? Any unproven tech will need to be reviewed by cryptographic authority and we know that is not so easy.
I'll read Zerocoin whitepaper tomorrow and will think. Today is too late, time to drink milk and go to bed soon.
In my search for a crypto algo reviewer, I was referred to a crypto expert named Matt Green. He did get back to me yesterday and said he was currently advising Zerocoin but might have some time to review our code. I did mention to him that we were interested in implementing Zerocoin with Nxt POS and would like him to review our code if he could. Here is his blog, seems like a really nice guy; http://blog.cryptographyengineering.com/
Also, I've had a hard time getting crypto people to review the code, they would rather review a protocol design document instead of code.
zerocash is scheduled to be released in May as altcoin.
http://www.youtube.com/watch?v=Uh6erfE9HYE
Matthew Green's half hour presentation at Real World Crypto 2014
They massively improved on the alpha version. zerocash uses SHA256, merkle trees, etc. and seems to be ideal to implement onto NXT Matthew Green's half hour presentation at Real World Crypto 2014
When you remember the address, could you send them to Anon for safe keeping? 
The file with the link to online wallet (blockchain.info guid) is encrypted with the BTC address...
I think guys who sold me the bitcoins should have it in their wallet history.
Edit: I'll find it in browser history, don't worry.
Maybe this: 1LLe2He9k8r8WnAnuXJbAUedX8c2HCr8bQ
API 2 won't care about addresses. Transactions will be signed on client side.
But when you return addresses for transactions?
Like current getTransaction.
Old 64-bit unsigned number.
So we can protect from any corruption on the way from core to client by adding new addresses.
Otherwise if something goes wrong, and a wrong address gets to the client, the new addresses won't save the user.
When you remember the address, could you send them to Anon for safe keeping?
The file with the link to online wallet (blockchain.info guid) is encrypted with the BTC address...
I think guys who sold me the bitcoins should have it in their wallet history.
Edit: I'll find it in browser history, don't worry.
U have X incoming transactions and Y outgoing ones. If Xi + Xj + Xk == Ym + Yn then Big Brother can solve a Knapsack problem and keep tracking links between INs and OUTs using fuzzy logic. At some point in the future he may get more info and increase weights* of some links.
------
* - weights r like probabilities, they range from 0 to 1
Which means distributing a larger transaction over time doesn't help much in case the weights are inevitably 1 or 0.
But in any other case, how could Big Brother possibly add your "more info" if all transaction in the past are fulfilled?
And the other thing: what's the issue with the 'joincoin approach'? I.e. if n senders send 5Nxts then n receiver receive 5Nxts. So, nobody could differentiate who exactly transferred whom 5Nxt. They send collectively n*5 Nxts and they receive collectively n*5 Nxts.
So what is the plan to open an account for forging in clients with the nrs client going away?
Ah, ok. Let's do it after we launch open beta test of Asset Exchange.
Also, I've had a hard time getting crypto people to review the code, they would rather review a protocol design document instead of code.
Oops, I forgot about that 10 BTC. Could anyone remind me address where they r stored on?
When you remember the address, could you send them to Anon for safe keeping?
API 2 won't care about addresses. Transactions will be signed on client side.
But when you return addresses for transactions?
Like current getTransaction.
Old 64-bit unsigned number.
@CfB: what is the plan for opening accounts for forging in clients? API call in API v2?
I could do it if u guys cooperate and give me something like a specification for API v2. Brainstorming is over as I see.
My day only has 24 hours and a lot of it currently goes into NXT. I made comments in that thread, but never saw the need to create an API v2 in the first place. Extend the current API with what is being asked for instead.
Plan for v2 in a year. Get us going now in v1.
So what is the plan to open an account for forging in clients with the nrs client going away?
Also, I've had a hard time getting crypto people to review the code, they would rather review a protocol design document instead of code.
Oops, I forgot about that 10 BTC. Could anyone remind me address where they r stored on?
API 2 won't care about addresses. Transactions will be signed on client side.
But when you return addresses for transactions?
Like current getTransaction.
Why not zerocoin? Any unproven tech will need to be reviewed by cryptographic authority and we know that is not so easy.
I'll read Zerocoin whitepaper tomorrow and will think. Today is too late, time to drink milk and go to bed soon.
In my search for a crypto algo reviewer, I was referred to a crypto expert named Matt Green. He did get back to me yesterday and said he was currently advising Zerocoin but might have some time to review our code. I did mention to him that we were interested in implementing Zerocoin with Nxt POS and would like him to review our code if he could. Here is his blog, seems like a really nice guy; http://blog.cryptographyengineering.com/
Also, I've had a hard time getting crypto people to review the code, they would rather review a protocol design document instead of code.
With a divide and conquer approach, we might be able to get zerocoin functionality for NXT before zerocoin!
I'm not sure it's not a theft...
its definitely not theft. the idea of theft requires that someone else be deprived of property. copying code doesn't deprive the other person of his copy. i mean maybe its immoral but if so than not because its theft, it would have to be some new moral construct that doesnt have a name yet. something meaning "immoral copying". i vote that we call it flibber.
Or we could just ask them... or ask their permission...
+1
i mean why not be polite about it. no sense in flibbering all over someone elses work unnecessarily.
I like to flibber... mmmm
busy professors don't usually respond to emails from people they don't know
they have published integration instructions
it is open source
LACK of action is not an action opposing, it is just a lack of action.
they have published integration instructions
it is open source
LACK of action is not an action opposing, it is just a lack of action.
sounds reasonable. Maybe this is the right path then; and possibly, if we get started on it FIRST, and show the profs that we are serious, that they may even be willing to help then.
I have to agree. I imagine they must get a hell of a lot of mail -- starting work on an implementation of ZC and asking questions may be the signal they need for dialog to happen.
nxt got in to the Joe Rogans video ., while A. Atrouplous talked about alts
http://www.youtube.com/watch?v=1cexawnOlR8&feature=share skip to 1:52:33
http://www.youtube.com/watch?v=1cexawnOlR8&feature=share skip to 1:52:33
If you're doing API 2, it would be a perfect opportunity to switch to the new address format!
Old API will continue working with old account IDs and new will return new addresses.
Old API will continue working with old account IDs and new will return new addresses.
API 2 won't care about addresses. Transactions will be signed on client side.
Jump to: