Topic: [NXT] NXTInfrastructure committee - page 3. (Read 6292 times)

Thank you so much!  That was/is a really big help!

Congratulations for collecting the additional 100.000 NXT!

wesleyh, you have a great client, you've understood all the pros and cons of prepareByte and I'm sure you will do it right.

I can't really say. I'm not into mining and your proposal is beyond me (because of that).

It doesn't sound like InfCom is the right committee to ask. Probably, the community fund or direct funding from stakeholders would be possible. In both cases, the NXT monster thread would probably be the right place to ask (which I think you did already).

@All: Correct me if I'm wrong.

Not really, as prepareBytes also validates the request, such as checking if the asset name is already taken or not, or asset issuance name, valid asset id, etc etc.. So I do prepareBytes, then validate the response by parsing it, and injecting my signature. Is that a good enough method for you?

Sorry, I guess it may not belong here (although it might.)  All I know is that I think this concept could help promote and get people interested in Nxt and that others have certainly voiced that they agree with me.  Should I forward this request elsewhere?

I've personally been interested in Nxt since late December.  However, I haven't paid much attention to all of the development and community growth in the past couple of months due to life interruptions and the fact that community discussion has grown at insane pace.  I can't keep up.

Hi rlh!

There is the NXTCommunity fund and the funds under management of the Marketing, TechDev and Infrastructure committees. Could you explain why you see a connection between this project and the NXT Infrastructure? Thanks!

Cheers,
Marcus

Hey guys.  Earlier today I posted a bounty for someone to create a mining pool that mines off of profitability, dumps the coins and then uses the proceeds to buy Nxt to proportionally redistribute to the miners.

See the proposal here.

Anyway, it was mentioned that I get ahold of the Nxt Infrastructure committee and ask for support of this bounty.  As such, would you please consider either donating to this bounty or setting up one that is managed by the committee.

I don't so much care to manage the bounty but I'm more than willing too.  Likewise, since you all are more trusted that I might be, I am willing to hand over the bounty funds to you guys and updating the bounty post.  Is this possible?  If you guys are interested please let me know.  I (and many others) feel that this could be really good for Nxt.

Exactly! That is what NXTcash will do, allow the "teleporting" to shadow acct
The client software can make all of this acct management transparent and easy to do, user error is actually the biggest vulnerability to anonymity

Thank you for effort so far, James.

I think anonymity is not required all the time. A person can create a shadow account apart from his regular account by funding a shadow account some NXT. This account is then be able to do all the transactions needed. Being shadow is an emergent property; there is nothing special about such accounts except that nobody knows which account funded them.

Normally people buying/selling fiat, goods etc. would need the regular account network.
In special cases, the shadow account network will be used for secret payments etc.

Only for transitioning regular and normal network, a person would need anonymity.

I agree.

Yes it is possible, but shadow accts are not linkable to the normal acct, since all specification of NXTmixer sending and receiving accts are inside encryption

However, for the truly paranoid, the client can divide any payment into 100NXT chunks per session. It will take longer, but then all the amounts are the same to all the shadow accts, which still dont have any links to the normal acct

So,Nxtmixer is like a Nxt collecting basin.
A want to transfer Nxt to B.
A just need to send nxt to mixer,and designate the B acc,then mixer will transfer them to B.
Right?
But,it may also find the relationship between A and B through the Nxt quantity of transaction.

I have been invited to post here about stuff,maybe it is applicable directly to inf-com maybe not.

For those not up to date on NXTmixer (not to be confused with NXTcash) https://bitcointalksearch.org/topic/m.5581086 is the start of a discussion with anonymint. He is understandably assuming NXTmixer was zerocoin integrated into NXT, that is NXTcash.

With the original NXTmixer proposal https://bitcointalksearch.org/topic/m.5581929 was where anonymint left off. I have continued to improve the NXTmixer design and I dont think anonymint was fully understanding my initial proposal. Still he was surprisingly optimistic about my proposal, especially considering his usual treatment of any anonymity system.

"Accidentally" (the subconscious has a funny way of doing what is needed) the output of step Z for NXTcash is an account where you effectively teleport NXT into a totally unconnected account. However, each time you use it, you need to be careful not to link this acct with your normal acct. useful for large onetime transactions, but not practical for everyday use.

NXTmixer has two parts. One is totally decentralized encryption path between all nodes to all other nodes. Payment can be sent simply by funding a throwaway acct and encrypting that acct's passphrase with the destination's onetime public key. While this is good from a decentralization standpoint, it is a lot more susceptible to knapsack analysis to correlate payment paths. Even though analysis might be able to deduce that acctA sent funds to acctB, NXTmixer's design does not divulge who is controlling those accts. If acctA and acctB are onetime throwaway accts, knowing a payment was sent isnt really useful to somebody trying to figure out who is paying whom. Remember that after receiving funds in a shadow acct, you can immediately (next session) send it to the mixer to remove any traces of source and fund another throwaway acct to store the deposit.

Using a centralized mixer for NXT makes it almost a perfect process as there are no txouts that leave trails forever into the past. If everybody sent 100NXT to a mixer acct and a bunch of 100NXT payments come out, there is no more than a statistical correlation that is possible. To deal with the centralization weakness I have improved the design to randomly select from 100+ servers to be the designated mixer for that period. If we can have a lot more periods per day, we can further reduce the centralization problem by splitting up the payments into smaller pieces. At some point the risk due to centralization is worth the benefit gained.

"Accidentally" nodecoin is sent to a large number of nodes all at the same time and all in pretty much the same amounts. The current infrastructure cant possibly handle 20,000 AM broadcasts per minute, maybe 20,000 per hour would even be a problem. However, a dedicated set of guardian servers would be able to handle this without much problems.

nodeminer reports the 20 active peers of each NXT node to a pool server. assuming enough nodes are participating this allows the pool server to recreate the exact topology of the NXT network, every block! This was an unexpected bonus and I havent figured out all the implications. Currently the pool server simply tallies up the number of times each node is an active peer and allocates nodecoins based on that. However, it would be possible to create a NXT connections graph and publish that in realtime. The changes are not going to happen very quickly, so there could be full snapshots and incrementals from recent snapshots.

What good is this? Well,for one, it should be possible to detect attack attempts or just generally misbehaving nodes. It could also allow for a much more robust implementation of high TPS processing by identifying the ideal receiving node based on exact topology. No single node would have to be the target of all the blocks transactions. All this is pretty complicated and I am not sure of what specific benefit this has, I just know that for any attempt of dynamically adapting network topology, we need to have this data. nodecoin provides this.

Back to NXTmixer. How does it work?
At the high level, we operate in a series of sessions. Each session is started by that sessions NXTmixing server publishing is public key. immediately after this, ALL nodes broadcast their public key and a set of mixer transactions and a point to point payment, encrypted to the NXTmixer.

Even if a node does not have any transactions, it still sends out the broadcast packet. This eliminates all time based attacks as all the nodes look the same! The point of each node having a public key for each session is that any other node can send it a point to point payment. All the nodes have to decrypt all the broadcast packets as that is the only way to know if a payment was received. I have not done timing tests, but any modern computer should be able to keep up with this as long as sessions arent once per minute.

now the mixer payment packet is where things get really interesting. Keep in mind that it is encrypted so only the designated NXTmixer server can decrypt it. Inside each packet is the designated payment acct and deposit acct.I call these the shadow acct. Any payments are cleared through a common NXT acct thus totally mixing source and all the cleared payments are sent by the mixing server at the end of the session.

By designating an acct to be a deposit acct one session and then the payment acct the next session, it is possible to receive and make payments from an account that you never even access at all. you never even publish the acct in plaintext. By specifying a NXTcash funded acct to be the payment acct, you can do the time consuming step Z once and then after that utilize those funds from your normal acct without any connection to it.

Back to nodecoin.
The problem with NXTmixer is the sheer number of transactions. Each session there would be one AM from every participating acct. This makes it cost prohibitive. Anonymity is nice,but few will pay thousands of NXT per month to have access to this. Now, what if we utilize the NXT topology we have from the nodeminer submissions? We would be able to propagate parallel broadcasts of all nodes to all other nodes with the most efficient path. We wont care about hiding which nodes we are communicating with, as everyone is talking to everyone. Unlike Tor usage which invariably raises red flags, everything with NXTmixer is on public internet. However everybody looks the same, so no information is transmitted.

The source of funds and destination of funds are only revealed inside the encryption. However, each client can monitor the blockchain to verify that payment was taken from their payment acct. This systems works so well that the sender wont know if the funds were received by the destination as the destination acct is unknown. To establish transparency on this, the destination would need to presend the deposit address to the sender. This does leak some information, but if a throwaway acct is used, then the next session, the destination acct can send a payment to itself from the throwaway deposit acct to the main shadow acct. Alternatively, there could be a convention that all deposits received would be acknowledged in one of the encrypted broadcast packets. This would then allow for fully automated minimal trust methods of splitting a payment into small pieces and sending through the mixer, waiting for destination to acknowledge before sending the next piece.

If the time per session is fast enough, this will work pretty seamlessly, though for a 1 million NXT payment you would have to be patient. The trust required is minimized to the size of the pieces the transaction is broken up into. By having servers in the guardian rotation across continents and organizations, it should provide the robustness required for use by a fully decentralized network

In order to maintain full anonymity, the client will have to enforce best practices so that the user does not make a mistake. The services of NXTmixer should be viewed as low level services only meant to be used by client software that understands the issues and manages all the shadow accts, payment streams, etc.

Anyway, these designs for all the different things I am working on are always percolating in my mind and until the code comes out I am not totally sure of all the details. Even after the first version, still many iterations to evolve to a final implementation. I have found this method to be particularly effective when solving "impossible" problems as it is not possible for me to see ahead of time exactly what is needed. I left out the multisig gateway in this discussion, but I do have some ideas on mixing non-NXT deposits, though people will probably say that will destroy NXT

Feedback is welcome. Also if anybody is brave enough to whitepaper'ize this, that would probably be a very useful thing. I am using Daniel Bernstein's http://nacl.cr.yp.to/index.html encryption library for public/private key,but the design is independent of specific public/private key implementation

James

jean-luc says it might be better to not use the prepareBytes API call, and implement the missing 50 lines of code in the client, so that you don't have to have SSL.

"if you need to implement this logic on the client side, you might as well construct the byte array yourself, and not trust the server to do it for you correctly"

https://bitcointalksearch.org/topic/m.5683336

jean-luc says SSL is required

Some parts are fully trustless, some parts require some trust at least at first. When everything is integrated into the NXTcore, then it can become fully trustless.

Regardless, it is much more anonymous to NOT transmit any data in plaintext. Why let anybody into the house with unlimited time to crack the safe??? Lock the door, pull the blinds. https is better than http

I have no expertise in what method makes sense technically, I just know that it is better to have https than to not have it, in some cases critically so

James

Thank you James for your consideration of this important security issue. There definitely is technical merit in using SSL to avoid plaintext transmissions within the Nxt network, particularly with certain Nxt applications.

Marcus03, You are correct that NXTmixer and NXTcash work trustless.  However, as I mentioned earlier the mere fact that a Nxt transaction succeeds does not equate to guaranteed security of network participants. SSL represents the middle road of network security. It is not wide open for anyone to inspect, record, analyze patterns like the plaintext (HTTP) transmissions method of communication is.

The danger lies in the patterns that can be inferred from the mere fact that data has been transmitted. Originating and destination IPs can be identified and if HTTP is used every transaction can be identified too.
Implementing SSL into the Nxt ecosystem provides an important margin of security for network participants.

you make a really good point, and one that I had not even considered that I wish I had have included into my original proposal.  Much like BCNext's brainwallet provides plausible deniability, SSL would work alongside that for the same purpose.

And I do believe this will be temporary - maybe just for a year or 2 until SPs come along and provide the same functionality but on a basis where they are in the business to make $.  Then the SP will do their own cert.  But I am just running these VPSs to support NXT, not for profit, at least not anytime soon do I expect to be able to offer any kind of SP.

Another reason I want a domain wildcard cert is to be able to provide it to the wiki admin.  They REALLY NEED a valid SSL cert for their wiki, for login/editing purposes of the editors.  Consider that ideally, TOR is likely to be used by many people and if using tor, you REALLY NEED to be using SSL for pretty much everything you can - tor basically presents a MITM that could do attacks if you dont SSL your connection.

The only way to make 1 cert work for every single node is for every node to be a host on a single domain.  Given that then it would be possible for the domain administrator to revoke a cert, thus causing DoS, then it would be possible for a single entity (admin of whatever domain) to revoke everything.  so this is really a bad ideaa, and this is why in my proposal I suggested that different VPS operators use different SSL certs than what I do.

The free alternative (and not really that bad of a method either) is for use VPS operators to issue our own CA cert and sign our host nodes with that.  But then the client software devs for the lite clients will have to include all of these CA certs into their software package.  This should be a good solution, just has the extra step of organizing and including the certs into the software packages.  (This step isnt required if we use publicly trusted CA certs to sign our server certs, which is what I had originally asked funds for.