Topic: NXT :: descendant of Bitcoin - Updated Information - page 1083. (Read 2761632 times)

+1

Equal portions. They can arrange it among themselves how to fund.

Almost.
Now we need to see if klee, bybitcoin and neer.g are all willing. If not, then pouncer is alternate.

To simplify, probably makes sense to divide total in 3 equal parts. Thats really close to marketing allocation and depending on infrastructure costs the tech committee can balance funds with infrastructure committee to make sure everything is funded properly

James

I agree. Although the things discussed here can be pretty nice for the future as of today we don’t have something that is finished and polished for (mass) adoption.  
This we have to do ourselves, hereby I am thinking about a usable client.
I am tend to say we have a fork here of people that are looking into the future and people that focus on NXT todays value.

Either way I am in long so I don’t worry to much, but I do understand people losing patience selling NXT to buy other coins, so be prepared for a little dip but don’t worry future is bright as you can see in this thread, a lot of devs talking about things…

and it is good for mass distribution isnt it.

If it isnt zeroknowlege proofed, then some knowledge is leaking. Not sure how much with your setup, but big bad agency will be able to start building correlations and before long small knowledge leakage becomes full path tree.

2 days have passed. Looks like we decided who will keep the unclaimed coins?

excellent progress!
when will be able to use it?

I wonder if I should write a C program and send him the subleq output.
Is anybody working on this?

Quick question about coin mixing for anonymity (too early for my brain):

1. You send NXT to coin mixer (special account, hardcoded in source code)
2. The NXT will get forwarded, in random fractions, throughout the following 1440 blocks to the receiver
3. NXT Amount varies maybe 5%

Does this make sense? Is this even possible?

At worst you can stop using this setup if its not good, so I dont see how it is any worse.

In order to be reliable it would need to verify the external blockchain to make sure payment was made. proper error handling is certainly expected. Not impossible to do by any means. Source code review will allow people to verify the error cases that are handled or not handled. THIS is what provides a lot more trust than blindly relying on centralized exchange.

The code that the node is running is also open source. It would be tested and so the only way I can think of that the node doesnt send the request to the service is if the server crashes. Thats a good catch! So we clearly need to have a mechanism to make sure that important tasks are denoted as such and the NXT hub servers will need to verify that all services that were supposed to have been done were done exactly once. I think this is similiar to the double spend problem, tricky but not impossible.

Maybe Evil Bob will do horrible things? So yes we need super smart guys to make sure Evil Bob cant do really horrible things. I personally would trust that a peer reviewed open source solution that takes into account the Evil Bobs of the world will be more trustworthy that trusting some random employee at some random company. But, hey that's me. Maybe I am becoming a cryptoanarchist?

James

I thought CfB was requesting an instruction set from us? Or am I completely misreading this?

Each HUB (Service provider) is a Gateway...they will all run separate servers....decentralized.

Is there a thread that is more in-depth than the following one when it comes to asset exchange API?

https://bitcointalksearch.org/topic/nxt-api-2-brainstorming-406839

Lets wait for a bit more to make sure no complaints. Then we need to hear from the treasurer nominees which ones will accept. Pouncer is the alternate

James

We are able to push forward with NXTlayers. As soon as CfB tells us which instruction set he will implement, we can get all layers defined. Even before that we can get all layers other than the one right on top of the lowest layer defined and once defined we can start implementing.

50000 NXT to get all the layers defined.
400000 NXT to implement all the layers

James

What if there is a glitch in the hub and the payment aren't received?

And what if the node doesn't send the request to it's service module?  There needs to be cryptographic proof that the node performed that action.

This isn't a trustless system.  

No one should trust such a system.

 "What good is complaining to bter?"

I can move to a different  gateway if it's not good.

So, what are the next steps? Do they get the NXT now?

Actually this article is about using zeroknowlege proofs to do contingent payments. Put an escrow process in the middle and combine two contingent payments and you get trustless exchange!

When I was working on the zerocoin plan, I noticed that implementing zerocoin into NXT had a LOT of overlap with getting trustless crypto exchange working. With just a little more work, we can get 10 times the value.

This is why I am funding 100000 NXT for crosschain solution

James

Yes! That's exactly what I thought looking at it.

I didn't realize that's what NxtChg was referring to when he was discussing SNARK (I really wasn't following the cross-chain talk until now).

1000TPS?