Topic: NXT :: descendant of Bitcoin - Updated Information - page 1005. (Read 2761642 times)

I can't recall keywords now, but AFAIK there is a way to validate encrypted transactions. U don't see who paid whom but u r able to check that coins r not created out of thin air. Such encrypted transactions require that at some step u reveal data of a particular transaction. Also u can't use multiplication of numbers (only 1 time is possible IIRC). Maybe it could be used for anonymization too? No need to "mix" coins, the goal is just to break the links between accounts.

I live up the road from Kim Dot Com and he's very approachable. Perhaps he could play a role.

Here is my idea for avoiding blockchain bloat while doing 1000TPS. I am surprised nobody mentioned this, so it is either because it is a really bad idea for some reason, or too obvious nobody bothered??

From my understanding, it will be possible to have regular snapshots of the entire state of the NXT blockchain so that you wont need to parse all the blocks from genesis.

Secondly, very little of this "entire state of NXT" data has a life beyond 1440 blocks.

So, my proposal is to generate a daily snapshot, peer reviewed by nodes, checksummed, fingerprinted, signatured, whatever we need to make sure it is a valid unmolested snapshot. We actually dont even need these snapshots, but while we are doing this, might as well avoid having to download the entire blockchain. Bandwidth savings alone makes it worthwhile.

OK, so one way or another, let us assume the node is current. Now the problem is keeping up with 1000TPS (lets make the overall network adaptive so we can handle bursts of 1000TPS, sustained 250 TPS) and that requires bandwidth, though with binary data, 250 TPS should be around what 100TPS will be now. So 100kbps would be enough to handle bursts of 1000TPS and sustained 250TPS

But where does all that data go?

Actually, I say just throw it away! Why can't we use a FIFO that stores the most recent 1441 blocks for all the blockchains (when we go parallel). Since we synced the the full blockchain with the last days checkpoint, then as long as we are properly updating the "entire state of NXT network" at any given block, we are able to forge a valid block.

Unless I totally missed some reason why we need to locally store more than the last 1441 blocks, this should work. We can then specify that any NXT VM (Turing scripts) will need to be designed to use only data from prior 1440 blocks. This I do not see as a big limitation as if it is really important the client issuing script can just get data it needs and put it into AM. So, the NXTcore would need to implement the FIFO, preferably based on a web.xml parameter. That would allow people who run NXT VM generating clients to have access to exactly the window of time they need.

I hope this puts useful forging back on the table for raspis. 100kbps to fully support 1000TPS (peak output) NXT network

James

Okay - well in that case why not make your "prototype" plugin check for the existence of a Bitcoin transaction instead (that has at least x confirmations)?

The "script" will have "state" so any "plugin calls" it makes would presumably have some sort of "return value" that could be checked and/or kept in the script's state.

Looks similar to Nxt Service Providers.

Is that really what we want? Centralization?

I thank the pool operators for trying to provide a service for the community, but I think forging should remain individual.  Granted, Nxt is resistant to up to 90% concentration attacks, but I don't think this is a path we want to follow for multiple reasons.  Sooner or later, someone will open a pool and run off with everyone's Nxt.  I'm not saying the current ops will do this, but it's bound to happen.

You don't get any more using a pool, you just get more consistent payouts.

I am not even quite sure what a NXTplugin *is* but if it does has anything to do with the Nxt VM and its "scripts" then an email plugin would only be a "proof of what NOT to do".

What I am looking for in the blockchain is that code was executed without error. For example, if the code that was executed is code that verified the existence of a transaction in the bitcoin blockchain, this mechanism can be used to step through the cross chain algos.

NXTsmtp is just for proof of concept that incorporates something everybody is familiar with. I want to verify the peer verifiability of hardcoded NXTplugin followed by external NXTplugin. I am not worried about NXTsmtp for anything other than proving that NXTplugins work and are peer verified. At first I couldnt understand how on earth a DAC could be implemented. When I started thinking about email plugin, it became not as hard.

If the source to SMTP server is reviewed that it does send the email (backed up with test results) and as part of the sending process it adds a hash value of email to the blockchain. I think that allows peer verification, please explain where I am wrong. I am certain I have made mistakes somewhere and I am still coming up to speed with this whole decentralized blockchain approach.

The problem is that I see all of the things I am posting about as connected. Like the elephant described by different people. All sounds very different, but it is all the same elephant. If I described the elephant in its entirety, it wouldnt fit in posts. I feel a great sense of urgency due to competitive pressures.

James

P.S. I usually dont post when I am sleeping or flying

Besides, there are many other problems. Most of these emails would end up in spam folders anyway

Sender Policy Framework

http://en.wikipedia.org/wiki/Sender_Policy_Framework

Please try to understand I am using email as a proof of concept for a NXTplugin. I have stated repeatedly that it is not intended for actual usage, but rather to work out the issues of having NXTplugins.

You might think that you could try to guarantee than an email has actually been sent if the "receiver" indicated that they had received it through another AM, however, just because they didn't receive it doesn't mean that it was sent - again - "there is simply NO WAY to do this - so please stop trying now" (you are wasting time just as much as you would trying to solve "the halting problem").

Understand that this is why you don't want to mix up stuff from "within the blockchain" to stuff that is "outside the blockchain" as only the former can ever "be proven by the blockchain".

Is that really what we want? Centralization?

Yes, to be clear, these are for finished product, in the case of QBTC, it's more of a maintenance fee.

exactly. it's like everyday there is something new. zerocoin, then turing complete language, then decentralized cross-chain exchanges, then plugins, then emails ... Why on earth would I want to use Nxt for emails? There are zillions of better email services, and Nxt already has  private messages.

I've been reading your posts with interest and trying to digest them.  Much of it sounds good, but is mostly over my head so it's hard to give good feedback.  My biggest concern is security right now especially after the recent scare.  New features often bring new security holes, so I'd rather not be in too much of a rush to beat the competition for every little thing.  Nxt already has a strong niche (zero inflation, proof-of-stake) and just needs steady, but not rushed, development to bring in the new features which may or may not be embraced by the market.

Has Dr. Evil been hired to continue to looking for exploits and weaknesses and consult?  I saw a couple posts requesting this, but it should be a priority.  He's proven himself by brute forcing something like 3% of Nxt accounts (including genesis) and discovering an x-spend attack.  If we have community funds available then I think we should try to keep him on board as long as we can.

Besides, there are many other problems. Most of these emails would end up in spam folders anyway

Why target % is so high in the last blocks?